- Libraries - Haskell.org

Cabal, installing it
by David Owen 09 Jan '05

09 Jan '05

Hello all, I have a question about installing the Cabal tool. After downloading and extracting it to a folder I seem to be unable to install it correctly. I moved into the cabal folder which contains a Makefile, and typed 'make'. A longish compilation/installion took place and so I hoped that all was well. However when including it as a package when compiling with GHC (6.2.2) it simply says: ghc-6.2.2: unknown package name: Cabal The command I used to compile was ghc -package Cabal Setup.lhs -o setup So it seems Cabal hasn't actually installed properly. I'm quite new to Linux (I'm using SuSE 9.0) so I hope that there might be a simple answer. I would like to install Cabal so that I can use Warrick Gray's new versions of the HTTP modules. Any answers will be gratefully received. Thanks Dave Owen

2 1

Cabal, installing it
by David Owen 09 Jan '05

09 Jan '05

Hello all, I have a question about installing the Cabal tool. After downloading and extracting it to a folder I seem to be unable to install it correctly. I moved into the cabal folder which contains a Makefile, and typed 'make'. A longish compilation/installion took place and so I hoped that all was well. However when including it as a package when compiling with GHC (6.2.2) it simply says: ghc-6.2.2: unknown package name: Cabal The command I used to compile was ghc -package Cabal Setup.lhs -o setup So it seems Cabal hasn't actually installed properly. I'm quite new to Linux (I'm using SuSE 9.0) so I hope that there might be a simple answer. I would like to install Cabal so that I can use Warrick Gray's new versions of the HTTP modules. Any answers will be gratefully received. Thanks Dave Owen

1 0

Re: cvs commit: fptools/libraries/Cabal/Distribution GetOpt.hs Setup.hs Simple.hs
by Sven Panne 09 Jan '05

09 Jan '05

In the cvs-libraries list Isaac Jones wrote: > ijones 2005/01/05 23:42:11 PST > > Modified files: > libraries/Cabal/Distribution Setup.hs Simple.hs > Added files: > libraries/Cabal/Distribution GetOpt.hs > Log: > fixed checking for unknown args > Long story: > > It seems that Marvin removed my beautiful and powerful "getOpt" > alterations to use the System.Console one, which I had already deemed > to be non-beautiful because of the errors it spews when faced with > arguments it doesn't understand. > > I think Marvin misunderstood the API docs that seem to suggest that > the "commands" that get passed back from getOpt are the non-matched > arguments. In fact, non-matched arguments get returned as errors > (ewwwww). [...] As the author of the "non-beautiful" GetOpt, :-) I would happily accept any backwards-compatible improvements/additions to that module. Any suggestions? What would help to implement Cabal? Cheers, S.

2 1

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

09 Jan '05

On 04 January 2005 19:11, Isaac Jones wrote: >> And I meant <package> rather than "package" :-) > > As Ross pointed out, one problem with that is finding the file itself. > It also sorta violates the "don't repeat yourself" principal of > keeping data in sync. Most of these objections are addressed by simply saying that the basename of <package>.hsproj is irrelevant. It doesn't have to be the same as the package name, but by convention it makes sense for it to do so when possible. For the purposes of Cabal, it can be ignored. Why not just say that the package description is contained in a single file with a .hspkg or .hsproj suffix in the same directory as Setup.lhs? That covers all the cases we need right now, and it's a simple rule to describe. Cheers, Simon

3 4

ANN: Codec 1.0
by Dominic Steinitz 09 Jan '05

09 Jan '05

Partly by way of experiment with darcs and Cabal and partly because I am restructuring the cryptographic library, I have set up a Codec package with some utilities in it, see http://www.haskell.org/Codec/index.html. Currently it contains only the module Codec.Utils. To get the package: darcs get http://www.haskell.org/Codec To build, you need the Cabal libraries installed: ghc -package Setup.lhs -o setup -package Cabal ./setup configure ./setup build ./setup install The latter needs to be done as root. base64 encoding / decoding should probably be included in Codec.Utils (I've seen copies of the same code all over the place) and if anyone has the time, they are very welcome to add it. I'd also welcome feedback on whether this is the right place in the hierarchy for such a package and modules. Finally, I don't want to tread on any toes and if anyone feels that this is their area then I would be happy to hand this over and submit it as a contribution. Dominic. PS I'd also like to thank the darcs and Cabal teams for their tools.

1 1

RE: Missing ftruncate
by Simon Marlow 06 Jan '05

06 Jan '05

Yes, I had in mind having openTempFile and withTempFile built on top of it. You're right that withTempFile doesn't currently create the file and hence is unsafe - it should create the file, and it should pass a Handle to the IO action. Cheers, Simon On 06 January 2005 13:49, Krasimir Angelov wrote: > withTempFile isn't safe. It will generate the same > name if it is executed two time consequently and the > temporary file isn't created in the mean time. I also > thought about something like withTempFile but there > are some use cases in which it is useless. > openTempFile is simpler and on top of it withTempFile > can be implemented safely. > > --- Simon Marlow <simonmar(a)microsoft.com> wrote: > >> On 04 January 2005 17:51, Krasimir Angelov wrote: >> >>> I also would like to have some functions for creation >>> of temporary files. My proposal is: >>> >>> openTempFile :: FilePath >>> -> String >>> -> IO (FilePath, Handle) >>> openBinaryTempFile :: ... >>> >>> The first argument is the directory where to create >>> the file and the second argument is the file name >>> template. The template is something like "foo.bar" >>> with this template the name of the created file will >>> be fooXXX.bar where XXX is some random number. The >>> function should create immediatelly the file in order >>> to prevent other processes to create a file with the >>> same name. The returned path is the complete path to >>> the created file and the handle is the handle to the >>> created file. >> >> See withTempFile in Distribution.Simple.Utils; in >> many cases it is >> better to use the 'with'-style to eliminate the >> possibility of >> forgetting to remove the temporary file later. >> Sometimes the 'with' >> style isn't appropriate, but in those cases you >> should keep a list of >> temporary files and remove them with a top-level >> exception handler (like >> GHC does). >> >> Cheers, >> Simon >> > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage less. > http://info.mail.yahoo.com/mail_250

1 0

RE: Missing ftruncate
by Simon Marlow 06 Jan '05

06 Jan '05

On 04 January 2005 17:51, Krasimir Angelov wrote: > I also would like to have some functions for creation > of temporary files. My proposal is: > > openTempFile :: FilePath > -> String > -> IO (FilePath, Handle) > openBinaryTempFile :: ... > > The first argument is the directory where to create > the file and the second argument is the file name > template. The template is something like "foo.bar" > with this template the name of the created file will > be fooXXX.bar where XXX is some random number. The > function should create immediatelly the file in order > to prevent other processes to create a file with the > same name. The returned path is the complete path to > the created file and the handle is the handle to the > created file. See withTempFile in Distribution.Simple.Utils; in many cases it is better to use the 'with'-style to eliminate the possibility of forgetting to remove the temporary file later. Sometimes the 'with' style isn't appropriate, but in those cases you should keep a list of temporary files and remove them with a top-level exception handler (like GHC does). Cheers, Simon

2 1

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

06 Jan '05

I didn't know you'd tripped over this. Try with -fno-generics. If that solves it I'll explain why. Simon | -----Original Message----- | From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 05 January 2005 18:11 | To: Simon Marlow | Cc: Isaac Jones; Simon Peyton-Jones; libraries(a)haskell.org | Subject: Re: package description files | | On Wed, Jan 05, 2005 at 04:22:50PM -0000, Simon Marlow wrote: | > We're planning to ship GHC 6.4 "very soon", [...] | | But not before compiling large data definitions is a bit faster?

2 1

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