December 2004 - Libraries

ANN: hs-fltk - a binding to the FLTK GUI toolkit
by Einar Karttunen 19 Dec '04

19 Dec '04

Hello I am pleased to announce a Haskell binding to the FLTK (http://www.fltk.org) GUI toolkit available from http://www.cs.helsinki.fi/u/ekarttun/hs-fltk/ Hs-fltk is focused on creating a simple API for building GUIs in Haskell and manages to keep the binary size down. Currently it is tested on Linux, but FLTK is available on Win32 too... - Einar Karttunen

2 3

Data.Bits
by Iavor S. Diatchki 15 Dec '04

15 Dec '04

Hello, I have been mucking around with bits and hardware recently, and found the following two functions quite useful. Perhpas we should add them (or something similar) to Data.Bits? -- Manipulating bit arrays -- Warning: this actually uses lazyness :-) -- | Get an element from a bit vector. -- 0: least significant element (right-most in math notation) array .!. index = let x = fromIntegral (array `shiftR` (bitSize x * index)) in x -- | Join two sequences of bits together. -- Here we use 'fromIntegral' to simply resize bit-vectors. -- If it does something fancier, the amout we 'shiftL' may be wrong. -- As long as one sticks to the "usual" types this is not a problem. b1 `nextTo` b2 = (fromIntegral b1 `shiftL` bitSize b2) .|. fromIntegral b2 Examples: > showBin ((-1::Word16) `nextTo` (10::Word8) :: Word32) "00000000111111111111111100001010" > showBin (((-1::Word16) `nextTo` (10::Word8) :: Word32) .!. 0 :: Word16) "1111111100001010" > showBin (((-1::Word16) `nextTo` (10::Word8) :: Word32) .!. 1 :: Word8) "11111111" Usually I don't need to specify nearly as many type annotations simply because it is obvious from the context what size quantities are needed. -Iavor

1 0

Distribution.PreProcess
by Ross Paterson 10 Dec '04

10 Dec '04

A couple of remarks about the current design: Currently the output of preprocessing is left in the same directory as the source. For Hugs, it would be more convenient to preprocess a source tree to make a new tree, especially if cpp turns Foo.hs into Foo.hs. The restriction to extensions delimited with '.' rules out things like *_hsc_make.c (portable output of hsc2hs). It might be preferable not to unlit .lhs files, as all implementations can handle them, and the originals are better for human readers (such as Hugs users curious about their libraries). There's no real need to unlit .ly files either, though some other preprocessors will need it. (And should unlit be treated as just another preprocessor?) As I understand it, preprocessing with cpp is only needed for Hugs, as the compilers have -cpp flags, and will do it properly themselves. For Hugs, cpp will need a -D__HUGS__ option, plus extra options that are often system-dependent (and will also be needed by the compilers). This harks back to the need to separate system-dependent build parameters from the package description, and provide hooks to generate and use them.

2 2

RE: broken links
by Simon Marlow 10 Dec '04

10 Dec '04

On 09 December 2004 19:09, Ross Paterson wrote: > On Thu, Dec 09, 2004 at 05:29:45PM -0000, Simon Marlow wrote: >> Thanks. Data.Array.Base is a "hidden" module - we don't expose its >> documentation, but unfortunately Haddock sometimes still generates >> links to it, when it can't find anywhere better to link to. This is >> a bug, but unfortunately it's a pretty deep bug - Haddock would need >> to be able to link to modules outside the imported scope of the >> current module, which it currently can't do. >> >> Fortunately there's often a workaround in the form of rearranging the >> imports of a module to expose the correct linking destinations to >> Haddock. I'll do a sweep over the docs before we release GHC 6.4 and >> make sure we don't have any dangling links of this kind. > > It's often instances from other modules that are the culprits, and > they're quite hard to fix. Yes, that's true. I've been thinking of a solution along these lines: Haddock processes the modules in two phases. The first phase resolves all the names and determines the "definitive" documentation for each entity. The second phase makes all the links point to the definitive documentation, with certain exceptions: if the entity is also documented in the local module, then point there instead. Perhaps there are other exceptions. We might need a way to indicate "definitive", or maybe just the module(s) furthest up the dependency tree would do. Cheers, Simon

1 0

RE: broken links
by Simon Marlow 10 Dec '04

10 Dec '04

On 09 December 2004 21:57, John Tromp wrote: > Simon Marlow wrote: > >> Thanks. Data.Array.Base is a "hidden" module - we don't expose its >> documentation, but unfortunately Haddock sometimes still generates >> links to it, when it can't find anywhere better to link to. This is >> a bug, but unfortunately it's a pretty deep bug - Haddock would need >> to be able to link to modules outside the imported scope of the >> current module, which it currently can't do. >> >> Fortunately there's often a workaround in the form of rearranging the >> imports of a module to expose the correct linking destinations to >> Haddock. I'll do a sweep over the docs before we release GHC 6.4 and >> make sure we don't have any dangling links of this kind. > > Does Haddock create the webpages on demand or as a batchjob? A batch job. > In the latter case one could run a script that goes over the webpages > and reports on all broken links, which can then be fixed either > manually or perhaps within the same script. I imagine that every > class, type and function is documented somewhere. At least that was > the case for all the broken links I ran into... Yes we could do this, but I'd prefer to fix the problem in Haddock itself. A script can't reliably determine the right place to link to - there might be multiple IArrays, for example. Cheers, Simon

1 0

Cabal package description sytax
by Isaac Jones 09 Dec '04

09 Dec '04

Hi Ross, I'm definitely happy to add more optional fields to the package description file. I knew that the need for such would come up. But the interface to cabal is the required description file fields and the required Setup arguments. How do you maintain that interface if you're generating the required fields of the description file with the Setup program itself? (I'm assuming that you are having Setup configure call the ./configure script or something?) The idea behind making the cabal description file so easy to parse is that other tools can get information like the package name and version from the cabal description file, rather than the description file sucking it in from someplace else. I believe this is what the Debian package generation tools do, for instance. Where do the PACKAGE_NAME, etc. values come from, BTW? A hope with the cabal was to be able to have a Setup.description file at the top level of something like a tarball. Layered tools like Hackage know where it is and how to parse it. If you don't have it in the source tarball, but rather generate it during build time, that breaks this model. The simple build infrastructure is not meant to build everything, though it would be nice if it could build most things without the help of Make and friends. The key is the interface to cabal which allows for layered tools like Hackage and the Debian package generator to come about. You can always use Haskell itself in the Setup file to find the list of modules or what-have-you and call the functions exposed by the simple build infrastructure. That's why the Setup program is a full-blown Haskell program. peace, isaac

4 5

RE: broken links
by Simon Marlow 09 Dec '04

09 Dec '04

On 09 December 2004 14:46, John Tromp wrote: > Many library doc links with ".Base." in the path are broken, > e.g. the IArray links on > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Array.MA rray.html > that point to the nonexisting > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Array.Ba se.html Thanks. Data.Array.Base is a "hidden" module - we don't expose its documentation, but unfortunately Haddock sometimes still generates links to it, when it can't find anywhere better to link to. This is a bug, but unfortunately it's a pretty deep bug - Haddock would need to be able to link to modules outside the imported scope of the current module, which it currently can't do. Fortunately there's often a workaround in the form of rearranging the imports of a module to expose the correct linking destinations to Haddock. I'll do a sweep over the docs before we release GHC 6.4 and make sure we don't have any dangling links of this kind. Cheers, Simon

3 2

broken links
by John Tromp 09 Dec '04

09 Dec '04

Many library doc links with ".Base." in the path are broken, e.g. the IArray links on http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Array.MArra… that point to the nonexisting http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.Array.Base.… regards, -John

1 0

SOAP?
by John Goerzen 09 Dec '04

09 Dec '04

Hi, I noticed this page http://www.nws.noaa.gov/forecasts/xml/, which provides US weather data over a SOAP feed. I'm wondering if anyone has done any work on a SOAP client (or server) in Haskell? Thanks, John

3 2

RE: Regexp substitution in fptools?
by Simon Marlow 09 Dec '04

09 Dec '04

On 08 December 2004 19:16, John Goerzen wrote: > I have the following code in my MissingH tree. I think it would make > a good addition to Text.Regex in fptools. Is this the right place to > ask? Added, thanks! Simon

1 0