- Libraries - Haskell.org

Default prefix for Cabal on Windows
by Brian Smith 15 Jun '05

15 Jun '05

Hi all, The documentation states in Section 3.1 that the default value of "prefix" is "/usr/local" on Unix. However, it doesn't specify what the prefix is on Windows. I found that the default value for prefix is: C:\Program Files\<package-name>\<compiler-name>-<compiler-version>. For example, version 1.0 of a package named "Foo" compiled with GHC 6.5 would have a default prefix of: C:\Program Files\Foo\ghc-6.5 I think that a better default value of prefix on Windows would be: C:\Program Files\<package-name>-<package-version> e.g.: C:\Program Files\Foo-1.0 In particular, I think it is undesirable to have the name and version of the compiler embedded in the default prefixes. Regardless of whether or not it is changed, this would be another good thing to put into the documentation. Regards, Brian

1 0

RE: irrelevant package
by Simon Marlow 14 Jun '05

14 Jun '05

On 13 June 2005 14:34, Serge D. Mechveliani wrote: > I am testing packages in ghc-6.4. > I set > docon.cabal, > > which declares dependence on `data': build-depends: data > The attempt to build docon by > > cd $doconSource > runhaskell Setup.hs configure --ghc --prefix=$doconSource/inst > runhaskell Setup.hs build > > produces > > configuring ... > compiling ... > ... > DPrelude.hs:1:0: > Module `DPrelude' is a member of package dumatel-1.2.6.4. > To compile this module, please use -ignore-package > dumatel-1.2.6.4. > > These does exist a package dumatel-1.2.6.4, and both the above > packages have DPrelude among the module names. > But why does Cabal look into irrelevant package? The dependence is > set: only `data'. This is "fixed" in newer versions of Cabal. However, you are heading for problems here. When you install a package P that includes a module M, you prevent the user from having any modules called M unless they say '-hide-package P' (see previous discussions on this subject). For this reason, we strongly recommend using hierarchical module names. At the moment, Cabal "exposes" all the packages it imports. Perhaps we should have an option to install an unexposed package, to allow installation of packages that contain non-hierarchical module names. Isaac - what do you think? Cheers, Simon

2 1

Re: [Haskell-cafe] Notes and questions from a first-time Cabal user.
by ross＠soi.city.ac.uk 14 Jun '05

14 Jun '05

[moving to libraries] On Mon, Jun 13, 2005 at 05:28:43PM -0500, Brian Smith wrote: > * If I use "Executable: check-ocl2," then under Windows the > executable's name really becomes "check-ocl2.exe." This is desireable > behavior. But, this causes "Setup.hs copy" and "Setup.hs install" to > fail because it tries to copy a file named "check-ocl2" (without the > ".exe"), which obviously doesn't exist. That's a bug in copy/nstall. > * The tutorial documentation should explain how to use tools like alex > and happy. As far as I could tell, the way to do this is to add > "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to > each executable/library stanza. But, I am not sure why this is > necessary, as it seems like it should be able to find them > automatically (i.e. without having to list them in the Other-Modules: > field) The .y and .x shouldn't be part of the module name. It's all much the same as for .hs. The Other-Modules field could be inferred from Main-Is or Exposed-Modules, but it isn't. > * Is there some way to tell Cabal to generate all intermediate files > into a directory that is different than the source directory? I > usually keep all my sources in a "src" directory, and then generate > all .hi, .o, and .hs files from Happy and Alex into a "build" > directory alongside it. This way, my "src" directory only contains > stuff that belongs in my version control repository, and "make clean" > was simply "rm -Rf build." Cabal puts the generated files in dist/build, along with copies (or cpp's) of the source files. > * If I run "runghc ./Setup.hs" I get this message: > No command given (try --help). > This is confusing because it isn't clear that it is a cabal error > message and not a runghc error message. That is, it isn't clear > whether to run "runghc --help" or "runghc Setup.hs --help," and both > commands are valid. The message should be improved, or "--help" should > be the default command. Those error messages ought to be prefixed with the program name (and should go to stderr too). > * Chapter 2 needs to be updated to replace "Hs-Source-Dir" with > "Hs-Source-Dirs," since Hs-Source-Dir is deprecated. The CVS version of the docs are updated; the web version describes GHC 6.4. > * Chapter 2 of the documentation states that identifiers can contain > underscores. However, Cabal gives "*** Exception: Line 1: Parse of > field 'name' failed" if I use "Name: ocl2_haskell" whereas "Name: > ocl2haskell" works fine. > > * Chapter 2 of the documentation states that identifiers must start > with a letter. However, "Name: 2" is parsed without complaint. Yes, the docs are wrong: a package name is actually one or more alphanumeric words separated by hyphens (though to avoid ambiguity each word should contain at least one letter), while identifiers are as in Haskell. > * Chapter 2 of the documentation states that idenfiers must start with > a letter. However, "letter" is not defined. Presumably the intention > is to restrict identifiers to English letters only? Haskell 98 defines a letter, but it doesn't say how to interpret a text file containing non-ASCII bytes. > * I originally put my "Build-depends: base" in an "Executable:" > stanza. This seems reasonable because presumably different executables > (and libraries) could have different dependencies, and it is > advantageous to keep track of dependencies on a fine-grained basis. > Yet, Cabal requires the Build-depends to be in the main stanza. Why is > this? Couldn't Cabal combine all the Build-Depends it finds into the > one that it puts into the final package specification? It is confusing that the first stanza contains both fields describing the whole package and fields describing a library. But Build-depends is a package-level thing (it's not in 2.1.2) because Cabal takes the package as the unit of distribution, building, etc. If you want to build this pachage, these are the other packages you need to have installed first. There has been some talk of a coarser level of structure in the indefinite future. > * Chapter 2 of the documentation states that I should be able to use > syntax like "foo > 1.2" in Build-depends, but I could not get "HUnit > > 1.1" or "HUnit >= 1.1" to work; they fail with parser errors. Hmm, the parser can't cope with white space after the relational operator -- another bug.

3 2

RE: What Cabal stuff is permanent?
by Simon Marlow 13 Jun '05

13 Jun '05

On 08 June 2005 16:38, John Goerzen wrote: > On 2005-06-07, Isaac Jones <ijones(a)syntaxpolice.org> wrote: >> include-dirs gets put into ghc's package.conf file, correct? But >> then > > While we're at it, it seems that GHC 6.4 no longer has a library-dirs > option, Not sure what you mean here - ghc-pkg's package format (aka InstalledPackageInfo) definitely *does* have a library-dirs field. > and that extra-lib-dirs is *not* installed into the GHC > package file. I think that it should be. What do you think? Indeed, that looks like a bug. I'm testing the fix now. Cheers, Simon

2 1

Haskell Matrix Library
by Keean Schupke 09 Jun '05

09 Jun '05

Hi, I have a simple matrix library (styled after MatLab's use of matrices), and was wondering if any of the standard libraries include matrix functionality. The library as stands is not suitable for general use - but it could be adapted. I guess the questions are: - is there already a matrix library in the standard libraries? - is anyone interested in a matrix library? - would people want a library like MatLab where matrices are instances of Num/Fractional/Floating and can be used in normal math equations... - operations like cos/sin/log can be applied to a matrix (and apply to each element like in MatLab)... What do people think? Keean

1 0

RE: What Cabal stuff is permanent?
by Simon Marlow 08 Jun '05

08 Jun '05

On 07 June 2005 14:29, Duncan Coutts wrote: > On Tue, 2005-06-07 at 08:15 -0500, John Goerzen wrote: >> On Tue, Jun 07, 2005 at 02:06:34PM +0100, Duncan Coutts wrote: >>>> of this library" through Cabal. >>> >>> I suspect that any C .h files you need at build time will also be >>> needed by programs which use the library that you are building, >>> since GHC can inline FFI calls across modules in which case the >>> client module needs the .h files when compiling too. And so they >>> should be installed along with your library (assuming it is a >>> library and not a program you're building) and their location >>> mentioned in the .cabal file. >> >> Hmm. I have had several cases where I haven't included these .h >> files, and things still seem to have worked OK. I do that in >> MissingPy, for instance. I know that WASH has a .h file that it has >> not traditionally installed. > > You're probably just lucky that GHC decided not to inline the FFI > call. :-) (and/or the client module was not being compiled -fvia-C) > > You can get the definitive answer as to whether you're on thin ice > from one of the GHC devs. Yes, you're on thin ice. You should assume that any header files required to compile the current module (via C) will be required to compile any module that depends on it. However, if you attach includes to foreign import declarations, like this: foreign import ccall "foo.h bar" bar :: ... then GHC will currently not inline bar in another module. This is a missing feature, and we might fix it at some point. If you use Cabal's "includes" directive, or GHC's -#include option, rather than naming header files in the foreign declaration, then your foreign calls can and will cross module boundaries. You could work around it by not compiling certain modules with -O, or perhaps something funky like {-# OPTIONS_GHC -funfolding-creation-threashold=0 #-} might work (please let us know if it does!). I don't think Cabal currently has support for installing .h files, I guess that's something we need to look into (Isaac?). Cheers, Simon

3 4

RE: What Cabal stuff is permanent?
by Simon Marlow 08 Jun '05

08 Jun '05

On 07 June 2005 16:54, Isaac Jones wrote: > John Goerzen <jgoerzen(a)complete.org> writes: > >> On Tue, Jun 07, 2005 at 04:04:12PM +0100, Simon Marlow wrote: >>> However, if you attach includes to foreign import declarations, >>> like this: >>> >>> foreign import ccall "foo.h bar" bar :: ... >>> >>> then GHC will currently not inline bar in another module. This is a >>> missing feature, and we might fix it at some point. >> >> Ah ha. That is the only style I've ever used, and is also what WASH >> uses. So I guess I get out of jail free. >> >>> I don't think Cabal currently has support for installing .h files, I >>> guess that's something we need to look into (Isaac?). >> >> Sounds like it. > > How would this look? Let's say that include-dirs=./includes or > something relative to the top of the source tree while building. This > is so that ghc can find the "includes" while building. > > include-dirs gets put into ghc's package.conf file, correct? But then > will the installed package need an absolute path for include-dirs? Or > can it be relative to ghc's library directory or the package root? If > the later, it sounds like no big deal, just create the directory and > put anything from the "includes" field into it while installing. > > But then sometimes the include dirs might be an absolute path, maybe? > To indicate a .h file that this package is build-depending on? In > which case, we might assume that the include files in there are not a > part of the package, so we don't try to install them, but they are a > dependency and they should be installed on the target system already. > > If ghc's package.conf file doesn't allow relative paths, then we have > to do something a little tricky when generating the package.conf file, > which is make up the location that the includes will go. > > Sounds a little harry, but doable. Does anyone have better ideas? That does sound a little harry, you're right (sorry :-). I suggest adding a couple of new fields to .cabal. eg: local-include-dirs: includes install-includes: includes/myheader.h The purpose of local-include-dirs is that it adds -I flags to the ghc command line for building (only). The purpose of install-includes is: - it lists header files to install - they get installed in location specified by the --includedir option to ./setup configure, or otherwise a defaulit -- perhaps /usr/include/<package>, or maybe $libdir? C code that needs to include these headers can be compiled with "ghc -package P" and get the right -I option automatically. - the package.conf we generate for GHC will contain $includedir in include-dirs, iff install-includes is non-empty. Sound reasonable? Cheers, Simon

1 0

What Cabal stuff is permanent?
by John Goerzen 07 Jun '05

07 Jun '05

I have been using the info at http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html as my guide to Cabal. I recently added an include-dirs line to my .cabal file, only to find that ghc-pkg would fail to register this package. It appears that include-dirs was placed into the ghc-pkg file, and of course, the relative path doesn't exist at install time and isn't even relevant there. The problem is: the Cabal docs don't say which fields are "permanent" and registered in the package and which aren't. There are many cases where it is not desirable to have fields be "permanent", and this is one such case. I'm not sure how to specify "just search for .h files here at build time of this library" through Cabal. Ideas? -- John

2 3

RE: Inconsistent strictness of Data.Generics.toConstr
by Simon Peyton-Jones 06 Jun '05

06 Jun '05

Yes, surely toConstr should have consistent behaviour on tuples and other single-constructor types. I'm inclined to agree that it should be strict in all cases, and I'll fix Data.Generics.Instances to make it so. Unless someone yells otherwise. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Nils Anders | Danielsson | Sent: 02 June 2005 15:43 | To: libraries(a)haskell.org | Subject: Inconsistent strictness of Data.Generics.toConstr | | Data.Generics.toConstr is non-strict at the unit type (), but the | version derived (under GHC 6.4) for isomorphic types, such as One | below, is strict. | | data One = One deriving (Typeable, Data) | | > toConstr (undefined :: ()) | () | > toConstr (undefined :: One) | *** Exception: Prelude.undefined | | Furthermore toConstr is non-strict for a bunch of other types, see | Data.Generics.Instances. To me it seems reasonable that toConstr | should be strict, since bottom is not a constructor. | | (I'm not just nit-picking, a bug in one of my programs was caused by | me thinking toConstr was strict. The bug was of course easily fixed by | adding a seq, but I'd prefer consistent behaviour of toConstr.) | | -- | /NAD | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

Inconsistent strictness of Data.Generics.toConstr
by Nils Anders Danielsson 02 Jun '05

02 Jun '05

Data.Generics.toConstr is non-strict at the unit type (), but the version derived (under GHC 6.4) for isomorphic types, such as One below, is strict. data One = One deriving (Typeable, Data) > toConstr (undefined :: ()) () > toConstr (undefined :: One) *** Exception: Prelude.undefined Furthermore toConstr is non-strict for a bunch of other types, see Data.Generics.Instances. To me it seems reasonable that toConstr should be strict, since bottom is not a constructor. (I'm not just nit-picking, a bug in one of my programs was caused by me thinking toConstr was strict. The bug was of course easily fixed by adding a seq, but I'd prefer consistent behaviour of toConstr.) -- /NAD

1 0