January 2005 - Libraries

RE: package description files
by Simon Marlow 05 Jan '05

05 Jan '05

On 05 January 2005 15:54, Isaac Jones wrote: > "Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > >> All this work on Cabal is great! > > Thanks :) > >> Can I just emit one plea, namely that we don't forget to write a >> separate, comprehensible, standalone document describing Cabal and >> how to use it. > > I'm most definitely planning to do this, certainly before the first > stable release. We're planning to ship GHC 6.4 "very soon", so it would be good if the version of Cabal that comes with GHC 6.4 is more or less a stable release. What things do you still have in the pipeline? Cheers, Simon

4 4

package descriptions
by ross＠soi.city.ac.uk 05 Jan '05

05 Jan '05

I'd like to propose a refactoring of the package description, as follows: (1) The unprocessed source tree of every package would contain a package description, consisting a single stanza: name: unique name of the package (compulsory) version: package version number (compulsory) license: identifier for a common license (compulsory) license-file: name of a file containing the license copyright: copyright holder (compulsory) author: original author of the package maintainer: current maintainer of the package (if different) stability: stability level homepage: URL of the package homepage package-url: (same as homepage?) description: free-text description of the package category: from a list to be specified tested-with: list of compilers and versions (?) build-depends: list of packages needed to build this one exposed-modules: list of modules added by this package executables: list of programs added by this package (2) Packages using the simple build infrastructure would optionally provide an additional file of build parameters for that infrastructure, consisting of a basic stanza and zero or more executable stanzas: build-package: Boolean: is package buildable? (default: True) <buildinfo> (for library, if any) executable: name of a program from executables main-is: relative filename for the main module <buildinfo> (for the executable) where <buildinfo> consists of: other-modules: list of additional modules hs-source-dir: name of root directory of the module hierarchy extensions: list of Haskell extensions used by every module options-ghc: additional options for GHC options-hugs: additional options for Hugs options-nhc: additional options for NHC c-sources: list of C source files cc-options: options for the C compiler includes: header files describing foreign imports include-dirs: directories to search for header files ld-options: options for the linker extra-libs: extra libraries to link with extra-lib-dirs: directories to search for libraries frameworks: list of Darwin/MacOS X frameworks to link to (The options fields are inconsistent -- we can sort that out later.) This file need not be present until after the pre-conf step; in some cases it will be generated from a template by that step.

2 1

RE: package description files
by Simon Peyton-Jones 05 Jan '05

05 Jan '05

All this work on Cabal is great! Can I just emit one plea, namely that we don't forget to write a separate, comprehensible, standalone document describing Cabal and how to use it. The "proposal" document is an excellent starting point but (a) the design has changed a bit, (b) the proposal discussed design choices that are now fixed, (c) we could probably do with "how-to" chapters for Angela Author and perhaps other personae. The Haddock for the source code isn't enough! So far as getting Cabal used, documenting it is extremely important. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Isaac Jones | Sent: 04 January 2005 19:11 | To: Simon Marlow | Cc: libraries(a)haskell.org; Ross Paterson | Subject: Re: package description files | | "Simon Marlow" <simonmar(a)microsoft.com> writes: | | > On 04 January 2005 15:39, Ross Paterson wrote: | > | >> On Tue, Jan 04, 2005 at 03:31:44PM -0000, Simon Marlow wrote: | >>> On 04 January 2005 10:36, Ross Paterson wrote: | >>> | >>>> I'd like to second Krasimir's suggestion that package description | >>>> files be called Package.description (or package.description), which | >>>> seems obviously more appropriate than Setup.description. In | >>>> addition, these files will be used by other tools as well as Cabal | >>>> setup scripts.

2 1

RE: ANN: hs-fltk - a binding to the FLTK GUI toolkit
by Simon Marlow 05 Jan '05

05 Jan '05

On 20 December 2004 13:02, Einar Karttunen wrote: > "Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: >> This doesn't sound right to me. It may be an unintended consequence >> of the new package story. Simon M is on holiday, but I'll discuss >> it with him as soon as poss. > > Creating a simple test case was nontrivial but this should work: > http://www.cs.helsinki.fi/u/ekarttun/haskell/FiiT.tar.gz I can't reproduce any problems with this test case - what exactly goes wrong for you? It compiles fine, and I can compile a module that imports something from module Fii that was re-exported from a hidden module. I had to modify the package description slightly to track recent changes to Cabal in GHC. Cheers, Simon

1 0

RE: package descriptions
by Simon Marlow 05 Jan '05

05 Jan '05

Looks ok. A couple of things worry me slightly (I think these were problems before, but your description has highlighted them): - if the package and executables can have different hs-source-dirs and yet share modules, how does this work? Is it sensible? - since the package and each executable can specify different extensions and options, this means in principle we have to compile each module multiple times - it's not safe to re-use the compiled version in the package and executables unless the compiler options are identical. That means not just options-ghc, but also cc-options, includes, and include-dirs. Cheers, Simon On 05 January 2005 11:02, ross(a)soi.city.ac.uk wrote: > I'd like to propose a refactoring of the package description, as > follows: > > (1) The unprocessed source tree of every package would contain a > package description, consisting a single stanza: > > name: unique name of the package (compulsory) > version: package version number (compulsory) > license: identifier for a common license (compulsory) > license-file: name of a file containing the license > copyright: copyright holder (compulsory) > author: original author of the package > maintainer: current maintainer of the package (if different) > stability: stability level > homepage: URL of the package homepage > package-url: (same as homepage?) > description: free-text description of the package > category: from a list to be specified > tested-with: list of compilers and versions (?) > build-depends: list of packages needed to build this one > exposed-modules: list of modules added by this package > executables: list of programs added by this package > > (2) Packages using the simple build infrastructure would optionally > provide an additional file of build parameters for that > infrastructure, consisting of a basic stanza and zero or more > executable stanzas: > > build-package: Boolean: is package buildable? (default: True) > <buildinfo> (for library, if any) > > executable: name of a program from executables > main-is: relative filename for the main module > <buildinfo> (for the executable) > > where <buildinfo> consists of: > > other-modules: list of additional modules > hs-source-dir: name of root directory of the module hierarchy > extensions: list of Haskell extensions used by every module > options-ghc: additional options for GHC > options-hugs: additional options for Hugs > options-nhc: additional options for NHC > c-sources: list of C source files > cc-options: options for the C compiler > includes: header files describing foreign imports > include-dirs: directories to search for header files > ld-options: options for the linker > extra-libs: extra libraries to link with > extra-lib-dirs: directories to search for libraries > frameworks: list of Darwin/MacOS X frameworks to link to > > (The options fields are inconsistent -- we can sort that out > later.) > > This file need not be present until after the pre-conf step; in > some cases it will be generated from a template by that step. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

2 1

RE: Renaming of HUnit
by Simon Marlow 05 Jan '05

05 Jan '05

Debug.QuickCheck has been renamed to Test.QuickCheck (the old Debug.QuickCheck modules are kept for backwards compatibility). Cheers, Simon On 05 January 2005 08:38, Bayley, Alistair wrote: > A minor quible (and it may be a bit late now...) > > I see Brian refer to Test.Hunit. Wouldn't it be more sensible to > place it in Debug.Hunit, so it resides with Debug.QuickCheck in the > library namespace? Users scanning the libraries for testing tools > shouldn't have to look in many places. > > Or maybe QuickCheck could be re-exported to Test.QuickCheck. > > Alistair. > > >> -----Original Message----- >> From: Brian Smith [mailto:brianlsmith@gmail.com] >> >> .... >> >> Alternatively, could you supply a module "HUnit" inside package >> "HUnit-1.0" that simply exports everything from Test.HUnit, with >> everything marked deprecated and with a pointer to use Test.HUnit >> instead? > > ----------------------------------------- > ***************************************************************** > Confidentiality Note: The information contained in this message, > and any attachments, may contain confidential and/or privileged > material. It is intended solely for the person(s) or entity to > which it is addressed. Any review, retransmission, dissemination, > or taking of any action in reliance upon this information by persons > or entities other than the intended recipient(s) is prohibited. If > you received this in error, please contact the sender and delete the > material from any computer. > ***************************************************************** > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Renaming of HUnit
by Bayley, Alistair 05 Jan '05

05 Jan '05

A minor quible (and it may be a bit late now...) I see Brian refer to Test.Hunit. Wouldn't it be more sensible to place it in Debug.Hunit, so it resides with Debug.QuickCheck in the library namespace? Users scanning the libraries for testing tools shouldn't have to look in many places. Or maybe QuickCheck could be re-exported to Test.QuickCheck. Alistair. > -----Original Message----- > From: Brian Smith [mailto:brianlsmith@gmail.com] > > .... > > Alternatively, could you supply a module "HUnit" inside package > "HUnit-1.0" that simply exports everything from Test.HUnit, with > everything marked deprecated and with a pointer to use Test.HUnit > instead? ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

RE: package description files
by Simon Marlow 04 Jan '05

04 Jan '05

On 04 January 2005 15:39, Ross Paterson wrote: > On Tue, Jan 04, 2005 at 03:31:44PM -0000, Simon Marlow wrote: >> On 04 January 2005 10:36, Ross Paterson wrote: >> >>> I'd like to second Krasimir's suggestion that package description >>> files be called Package.description (or package.description), which >>> seems obviously more appropriate than Setup.description. In >>> addition, these files will be used by other tools as well as Cabal >>> setup scripts. >> >> Actually I'm slightly in favour of <package>.{hspkg,hsproj}. The >> point of a file suffix is to give some useful information about the >> contents of the file, and preferably to uniquely identify its format; >> .description is just too vague (although I don't know of any other >> uses for the .description suffix). > > Fine, but I meant "package" rather than <package>, And I meant <package> rather than "package" :-) > as there's only one in a directory, and a fixed name will make it > easier to find (especially as you don't know the name of the package > until you read it). It's not a big deal. I think the <package>.hsproj form makes things easier in Visual Studio, but I can't remember the details right now. At the moment in VS when we create a new package, we create <package>.hsproj, but we can load up Package.description just fine so it's probably not a fundamental restriction. Cheers, Simon

2 1

RE: Missing ftruncate
by Simon Marlow 04 Jan '05

04 Jan '05

On 20 December 2004 22:01, John Goerzen wrote: > There appears to be no interface in Haskell to ftruncate(2). (Or, for > that matter, the less-useful truncate(2)). There are System.Posix.setFileSize and System.Posix.setFdSize, which are direct interfaces to truncate(2) and ftruncate(2) respectively. However, perhaps you want something more portable. I seem to recall there was a proposal to add hSetFileSize at one point... ah yes: http://www.haskell.org/pipermail/haskell/2002-January/008677.html unfortunately we never followed up on that promise :-) Looks like it shouldn't be too hard - on Windows there's no truncate(), but there is SetEndOfFile() instead. Cheers, Simon

3 2

RE: package description files
by Simon Marlow 04 Jan '05

04 Jan '05

On 04 January 2005 10:36, Ross Paterson wrote: > I'd like to second Krasimir's suggestion that package description > files be called Package.description (or package.description), which > seems obviously more appropriate than Setup.description. In > addition, these files will be used by other tools as well as Cabal > setup scripts. Actually I'm slightly in favour of <package>.{hspkg,hsproj}. The point of a file suffix is to give some useful information about the contents of the file, and preferably to uniquely identify its format; .description is just too vague (although I don't know of any other uses for the .description suffix). Cheers, Simon

2 1