November 2004 - Libraries

The Fudgets Library
by David Owen 01 Dec '04

01 Dec '04

Hello all, I've just joined the mailing list and I'm seeking some help. I am having trouble installing and using the Fudgets library. I am using SuSe Linux 9.0 and Fudgets version h13w May 2002. I have tried to install the library for use with both of the recommended Haskell compilers: HBC-0.9999.5b and GHC version 5.02.3 (these are the closest versions I could find to those recommended). I think I have added the necessary directories to my path such as HBC when using the HBC compiler, and also GHC and HMake when using the GHC compiler. When I attempt to compile a Fudgets program using ./hbcxmake Main I receive the message "Fail:Missing source file: Fudgets.hi (fsopenfile: not a plain file)". I am unable to compile at all with GHC as the 'Happy' parser generator it requires will not install. Should any of you know why I am unable to compile Fudgets programs I would be most grateful. And if someone is able to supply step-by-step idiot proof instructions for installing and compiling any Fudgets version (using either compiler) then that would be superb. Without the Fudgets library I am not sure how to go about building a GUI client/server application such as a web browser in Haskell. Any advice would be very much appreciated! best regards David Swansea, United Kingdom

2 1

The Fudgets Library
by David Owen 30 Nov '04

30 Nov '04

Hello all, I've just joined the mailing list and I'm seeking some help. I am having trouble installing and using the Fudgets library. I am using SuSe Linux 9.0 and Fudgets version h13w May 2002. I have tried to install the library for use with both of the recommended Haskell compilers: HBC-0.9999.5b and GHC version 5.02.3 (these are the closest versions I could find to those recommended). I think I have added the necessary directories to my path such as HBC when using the HBC compiler, and also GHC and HMake when using the GHC compiler. When I attempt to compile a Fudgets program using ./hbcxmake Main I receive the message "Fail:Missing source file: Fudgets.hi (fsopenfile: not a plain file)". I am unable to compile at all with GHC as the 'Happy' parser generator it requires will not install. Should any of you know why I am unable to compile Fudgets programs I would be most grateful. And if someone is able to supply step-by-step idiot proof instructions for installing and compiling any Fudgets version (using either compiler) then that would be superb. Without the Fudgets library I am not sure how to go about building a GUI client/server application such as a web browser in Haskell. Any advice would be very much appreciated! best regards David Swansea, United Kingdom

1 0

Re: Cabal package description sytax
by Ross Paterson 30 Nov '04

30 Nov '04

[Einar, I hope you don't mind me posting your reply on the list] On Tue, Nov 30, 2004 at 12:06:46AM +0200, Einar Karttunen wrote: > Ross Paterson <ross(a)soi.city.ac.uk> writes: > > True, simple will only get you so far, but the point is you can get quite > > a bit further for a small cost. (But if you only need the -I options > > for source files, not Setup.description, then cpp can put them in an > > extra-cc-opts field.) You could have a configure that calls fltk-config > > --libs and stashes the result -- a bit clunky, but fits the interface. > > Actually cpp cannot do that. If the -I options are not known when the > Setup.description is written (otherwise they could be directly > specified) there is usually no way of getting them with cpp. > > Generally you cannot #include any C headers because that would break > cabal (they usually come with extra baggage) and without any #includes, > there is very little information to use. #including a C header generated by configure is precisely what I was proposing to allow. That's what happens now with the fptools libraries. (Though they use installed package descriptions, which also happen to contain enough build information for Hugs.) I know that Cabal doesn't like the blank lines cpp generates, and I was proposing a change (which SimonM had already done on the fptools copy). > If you are thinking about including a generated file with cpp then it is > probably simpler to just append things to the Setup description with a > script. I cannot think of real scenarios when this would be helpful. Sven suggested some: name: PACKAGE_TARNAME version: PACKAGE_VERSION maintainer: PACKAGE_BUGREPORT Similarly extra include directories, libraries, etc. In some cases, part of the info will be always the same, but part is system-dependent, so you want to substitute, not just append. Also #if's are very useful.

1 0

Cabal package description sytax
by isaac jones 29 Nov '04

29 Nov '04

Hi Sven, > I'm having problems understanding the Cabal package description syntax > (I can't find a formal spec), There won't be a formal spec until we're closer to freezing it. > especially the use of quotes. Some field > values can be quoted, others can't, but I can't see any general > principle > here. The principal is that if there are fields that contain multiple values and unpredictable syntax, then you can use quotes. Maybe the only place that this is true is for file paths. You may note that the example in the proposal has a comma. > My problem in particular is that I want to use the values from > autoconf's AC_INIT (PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_BUGREPORT) > for > some package fields (name, version, maintainer), but the former have > double > quotes around them, while ghc-pkg either doesn't allow them (name, > version) > or includes the quotes into the value (maintainer). I'm a little unclear about what you're looking for wrt the interaction between autoconf, cabal, and ghc-pkg. > IMHO this should be > more consistent and unified, and a possible solution would be that > quotes > are handled like they are in shells, so "blah" and blah are the same. I think I like this idea for the cabal package description, and it would definitely be good to have consistency between the public parts of HC-pkg and cabal's package description. Unless anyone has objections to allowing quotes in all the fields, you should feel free to alter cabal's parser and send me a patch (it'll probably be a few days before I can do any serious cabal hacking). Since it's necessary for some fields, it'll probably simplify it if quotes are allowed everywhere. Opinions anyone? I'm not sure what this'll do when it dumps out a ghc-pkg description file, though, so some care should be taken (maybe that's what you're getting at above). peace, isaac

3 3

RE: Cabal package description sytax
by Simon Marlow 29 Nov '04

29 Nov '04

On 29 November 2004 06:50, isaac jones wrote: > On 27 November 2004 14:04, Sven Panne wrote: > >> especially the use of quotes. Some field >> values can be quoted, others can't, but I can't see any general >> principle here. > > The principal is that if there are fields that contain multiple values > and unpredictable syntax, then you can use quotes. Maybe the only > place that this is true is for file paths. You may note that the > example in the proposal has a comma. In the version of Cabal in libraries/Cabal, I changed the parser to allow quotes in more places. I did it in an adhoc way (just fixing problems as they arose), and I fully agree with Sven that we should be more consistent about it. I suggest: - a field of type String allows Haskell lexical syntax for strings in addition to the field-specific syntax. - a field of type [String] (including [FilePath] and [Opt]) allows the elements to be Haskell lexical syntax strings, again in addition to the field-specific syntax. - PackageIdentifiers are allowed to be quoted, and similarly for Licenses and the Bool field (exposed). That covers all of them, I think. > I think I like this idea for the cabal package description, and it > would definitely be good to have consistency between the public parts > of HC-pkg and cabal's package description. > > Unless anyone has objections to allowing quotes in all the fields, you > should feel free to alter cabal's parser and send me a patch (it'll > probably be a few days before I can do any serious cabal hacking). > Since it's necessary for some fields, it'll probably simplify it if > quotes are allowed everywhere. Opinions anyone? > > I'm not sure what this'll do when it dumps out a ghc-pkg description > file, though, so some care should be taken (maybe that's what you're > getting at above). For simplicity the dumped InstalledPackageInfo can use quotes everywhere. To refine this, we'd have to check for the presence of special characters, spaces etc. in the field values. Cheers, Simon

1 0

Cabal package description sytax
by Sven Panne 27 Nov '04

27 Nov '04

I'm having problems understanding the Cabal package description syntax (I can't find a formal spec), especially the use of quotes. Some field values can be quoted, others can't, but I can't see any general principle here. My problem in particular is that I want to use the values from autoconf's AC_INIT (PACKAGE_NAME, PACKAGE_VERSION, PACKAGE_BUGREPORT) for some package fields (name, version, maintainer), but the former have double quotes around them, while ghc-pkg either doesn't allow them (name, version) or includes the quotes into the value (maintainer). IMHO this should be more consistent and unified, and a possible solution would be that quotes are handled like they are in shells, so "blah" and blah are the same. Cheers, S.

1 0

re: Cabal interface changes proposal
by isaac jones 26 Nov '04

26 Nov '04

Hi all, I like the idea of adding a layer on top of the current cabal to add "shipments"... this would solve the problem of packages like gtk2hs and wxhaskell mentioned by Duncan Coutts, and allows us to keep the core cabal simple. Since it won't affect the core interface, I'll just push that on the stack and worry about it later. Krasimir suggested that a single cabal package should only have one executable, but I don't agree. I can see the reasons for keeping a one-to-one correspondence between a cabal package and a Haskell package, but I actually really like the way cabal treats executables right now. It's much simpler than libraries since it doesn't require a registration step or anything. It just needs to know where to find main and what to call the binary. As Duncan and Simon pointed out, multiple libraries is actually a more complicated story. So I would say that for now, let's keep the basic structure the same, a single library and multiple executables are allowed in a cabal package file, and hopefully we'll find time to implement "shipments" later so we can bundle together several libraries. I hope that won't hurt anyone too badly in the short term. I'll go ahead and perform the other changes mentioned. Sound OK? peace, isaac

3 2

RE: Cabal interface changes proposal
by Simon Marlow 26 Nov '04

26 Nov '04

On 26 November 2004 05:29, isaac jones wrote: > I like the idea of adding a layer on top of the current cabal to add > "shipments"... this would solve the problem of packages like gtk2hs > and wxhaskell mentioned by Duncan Coutts, and allows us to keep the > core cabal simple. Since it won't affect the core interface, I'll > just push that on the stack and worry about it later. > > Krasimir suggested that a single cabal package should only have one > executable, but I don't agree. I can see the reasons for keeping a > one-to-one correspondence between a cabal package and a Haskell > package, but I actually really like the way cabal treats executables > right now. It's much simpler than libraries since it doesn't require > a registration step or anything. It just needs to know where to find > main and what to call the binary. As Duncan and Simon pointed out, > multiple libraries is actually a more complicated story. Personally I think moving multiple executables up to the shipment layer would be conceptually simpler, but it's not that big a deal. You're the boss! > I'll go ahead and perform the other changes mentioned. Sound OK? Sure. Sorry I haven't pushed back my changes yet, still trying to hack GHC around with the new package story. It's a lot more involved than I thought, and I'm taking the opportunity to do some cleanup in GHC at the same time. Also I need to update Cabal to talk to GHC's new ghc-pkg tool, which uses the InstalledPackageInfo syntax for packages. Cheers, Simon

1 0

RE: printf
by Simon Marlow 25 Nov '04

25 Nov '04

On 23 November 2004 20:34, Lennart Augustsson wrote: > Being an old C programmer I'd like to suggest a library, Text.Printf, > for C printf() style formatting. > > For example > > do > printf "Hello, world\n" > printf "%s, cruel %s\n" "Goodbye" "world" > printf "pi is about %10.8f\n" (pi::Double) > > I have a Haskell 98 implementation of this function if people feel > that it would be useful. I'd like to pull this in, or something like it. IMHO, the lack of static type safety is outweighed by the shear convenience, and it's too small to provide as a separate library. It'd be nice to have hPrintf :: (PrintfType a) -> Handle -> String -> a too. Cheers, Simon

5 4

printf
by Lennart Augustsson 23 Nov '04

23 Nov '04

Being an old C programmer I'd like to suggest a library, Text.Printf, for C printf() style formatting. For example do printf "Hello, world\n" printf "%s, cruel %s\n" "Goodbye" "world" printf "pi is about %10.8f\n" (pi::Double) I have a Haskell 98 implementation of this function if people feel that it would be useful. -- Lennart

3 7