December 2004 - Libraries

Hierarchical module namespace extension not sufficiently flexible
by Duncan Coutts 07 Mar '05

07 Mar '05

All, So here's the problem: we have a binding to a large foreign library (GTK) which we are trying to fit nicely into hierarchical module name space. It would live under Graphics.UI.Gtk Graphics.UI.Gtk.Button Graphics.UI.Gtk.Frame ... etc Now there are over 100 modules directly under Graphics.UI.Gtk and you don't want to have to import each one of them separately. Of course you will not use all of them in one module but you might reasonably use 20+ of them. So it'd be nice to be able to say: > import Graphics.UI.Gtk or > import qualified Graphics.UI.Gtk as Gtk But now we have a problem. These import directives import a flat namespace, or a flat namespace qualified by a single module alias (ie Gtk in the second example). But the Gtk modules are deliberatly designed to have hierarchical names. You cannot simply combine them all together into a flat namespace without falling back to the trick of prefixing each function name with the module name. So while we would like to be able for users to do this: > import Graphics.UI.Gtk > > ... Button.setLabel ... They will instead have to say: > import Graphics.UI.Gtk > > ... buttonSetLabel ... Which is one of the things that the hierarchical module namespace extension was trying to get rid of! All the other language bindings for Gtk (apart from C) use the former import and useage style. It doesn't make us look good! :-) So my question is: have I overlooked something or is this really not possible at the moment. And secondly, if it is currently not possible is there a 'nice' extension that would allow this sort of thing. (Where nice probably means Haskell98 compatible / 'doesn't' break existing programs) How about: > module Graphics.UI.Gtk ( > > module qualified Graphics.UI.Gtk.Button as Button > ... > ) where > > import Graphics.UI.Gtk.Button or equivalently(?): > module Graphics.UI.Gtk ( > > module qualified Button > ... > ) where > > import Graphics.UI.Gtk.Button as Button Duncan Ps there's a oddity I found where if you say: > module Foo ( > module Bar > ) > > import qualified Bar then module Foo exports precisely nothing. But there's no error or warning.

6 8

Renaming of HUnit
by Brian Smith 04 Jan '05

04 Jan '05

I am happy to see that in GHC 6.3 that HUnit is included with GHC using "-package HUnit-1.0." However, the name "HUnit-1.0" is very confusing because it is different from the previous "HUnit 1.0." In particular, the HUnit package is now "Test.HUnit" and not just "HUnit." Therefore, I think it would be better to name the package something other than "HUnit-1.0," perhaps "HUnit-1.1." Otherwise, it seems like people could be confused by the fact that the existing documentation about HUnit on the Internet for HUnit 1.0 does not match the code for this "new" HUnit 1.0. Naming the package "HUnit-1.1" would allow somebody to create a "HUnit-1.0" package that is compatible with the "HUnit 1.0" that is documented on the HUnit Sourceforge website [1]. Or, somebody could create a "HUnit-1.1" package for GHC 6.2.2 that is equivalent to the Cabal package. Note that I have already created a HUnit-1.0 package for GHC 6.2.2 that uses the source code from the Sourceforge site. 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? Basically, I am just trying to ensure that my code that uses HUnit will compile with both GHC 6.2.2 and GHC 6.3/GHC 6.4, without using the preprocessor. Thanks, Brian [1] http://hunit.sourceforge.net/HUnit-1.0/Guide.html

2 1

ANN: MissingH 0.8.0 ("Festive Lambda")
by John Goerzen 23 Dec '04

23 Dec '04

MissingH 0.8.0 -- the "Festive Lambda" release New feature summary: * Virtualized I/O system Use familiar functions to work on not just Handles but all sorts of other types, including in-memory buffers. (HVIO module) * Virtualized filesystem Extends the virtual I/O concept to the filesystem, supporting entire virtual filesystems, and operations such as renames, stat(), etc. on them. (HVFS module) * Network server infrastructure Makes it easy to write a network server in Haskell. Functional interface permits easy adding of things such as multithreading, logging, etc. Functions to do these things are provided. Patterned loosely after Python's SocketServer system. (SocketServer module) * Full, pure-Haskell FTP server Provides a full FTP server over a real or virtual (HVFS) filesystem. It's a SocketServer server, so you get multithreading for free. Supports passive eand port modes. See below for an example: * Many path/file manipulation functions imported from Volker's HsShellScript. * Existing MissingH.IO functions updated to be HVIO compatible. MissingH 0.8.0 is available from: gopher://gopher.quux.org/1/devel/missingh or http://gopher.quux.org:70/devel/missingh ------------------------------------------------------------ Here is an example of a fully self-contained FTP server that serves up the local filesystem in read-only mode: import MissingH.Network.FTP.Server import MissingH.Network.SocketServer import MissingH.Logging.Logger import MissingH.IO.HVFS import MissingH.IO.HVFS.Combinators main = do updateGlobalLogger "" (setLevel DEBUG) updateGlobalLogger "MissingH.Network.FTP.Server" (setLevel DEBUG) let opts = (simpleTCPOptions 12345) {reuse = True} serveTCPforever opts $ threadedHandler $ loggingHandler "" INFO $ handleHandler $ anonFtpHandler (HVFSReadOnly SystemFS)

1 0

RE: cabal hooks interface (was: Cabal package description sytax)
by Simon Marlow 23 Dec '04

23 Dec '04

On 09 December 2004 23:56, ross(a)soi.city.ac.uk wrote: > On Wed, Dec 08, 2004 at 10:42:26PM -0800, Isaac Jones wrote: >> What about this interface for user-supplied command hooks. [...] >> >> For each of the pre-functions, a Maybe PackageDescription is >> returned. If Nothing, then it gets the description from the file or >> the default description you passed in. If (Just p), then it uses >> the description returned by the pre-functions. > > I'm not sure what's going on here. It seems only preConf needs to > return anything, and that shouldn't be the whole PackageDescription > (since you want part of that static), just the build information. > >> I don't particularly like the idea of: {{system "runhaskell" >> ["postinst.hs"]}} because it seems like a less elegant IO ExitCode. >> runhaskell doesn't exist, and it relies on more moving parts. > > Sure it exists -- I read about it in the spec. Ross's solution lets you put the postinst code in the setup script itself, or optionally in an external script if you prefer. This seems more flexible to me. Also, there doesn't seem much point in doing "runhaskell postinst.hs", you might as well just run "./postinst.hs" or "./postinst". Cheers, Simon

4 7

Fixed-Point Arithmetic?
by Ashley Yakeley 21 Dec '04

21 Dec '04

Have there been any proposals (or, indeed, does anyone have any private libraries) for fixed-point arithmetic? I can imagine uses for these 64-bit types: * unsigned, with all bits after the decimal point i.e. 0 <= x < 1 * unsigned, with 32 bits before the decimal point and 32 after * signed, with 32 bits before the decimal point and 32 after -- Ashley Yakeley, Seattle WA

1 0

Announcing: CGI and StreamProcessor module
by Peter Simons 21 Dec '04

21 Dec '04

Hi, I've made two small modules available for download in the hope that they will be useful: http://cryp.to/formdata/ An alternative implementation to Network.CGI which comes with full support for file uploads and a slightly different API. http://cryp.to/streamproc/ A continuation-based stream processor implemented as an Arrow. Comments and/or patches are welcome! Peter

1 0

Missing ftruncate
by John Goerzen 20 Dec '04

20 Dec '04

Hi, There appears to be no interface in Haskell to ftruncate(2). (Or, for that matter, the less-useful truncate(2)). For those that don't know, ftruncate(2) is frequently used to remove data at the end of an open file when that data is no longer needed. According to my Linux ftruncate(2) manpage: int truncate(const char *path, off_t length); int ftruncate(int fd, off_t length); ... CONFORMING TO 4.4BSD, SVr4 (these function calls first appeared in BSD 4.2). POSIX 1003.1-1996 has ftruncate. POSIX 1003.1-2001 also has truncate, as an XSI extension. I found this in fptools' libraries/base/System/Posix/Internals.hs: -- It isn't clear whether ftruncate is POSIX or not (I've read several -- manpages and they seem to conflict), so we truncate using open/2. fileTruncate :: FilePath -> IO () There are several problems with this: 1. System.Posix.Internals doesn't appear to be an exposed, documented API 2. There is no way to specify a length 3. There is no interface to ftruncate(). 4. If the manpages do conflict, a read of the standard should clarify it. In any case, ftruncate() appears to have been around for a LONG time. Would it be possible to provide a Haskell interface to ftruncate() at least? (truncate() can always be implemented in terms of it.) Thanks, John

1 0

Missing ftruncate
by John Goerzen 20 Dec '04

20 Dec '04

Hi, There appears to be no interface in Haskell to ftruncate(2). (Or, for that matter, the less-useful truncate(2)). For those that don't know, ftruncate(2) is frequently used to remove data at the end of an open file when that data is no longer needed. According to my Linux ftruncate(2) manpage: int truncate(const char *path, off_t length); int ftruncate(int fd, off_t length); ... CONFORMING TO 4.4BSD, SVr4 (these function calls first appeared in BSD 4.2). POSIX 1003.1-1996 has ftruncate. POSIX 1003.1-2001 also has truncate, as an XSI extension. I found this in fptools' libraries/base/System/Posix/Internals.hs: -- It isn't clear whether ftruncate is POSIX or not (I've read several -- manpages and they seem to conflict), so we truncate using open/2. fileTruncate :: FilePath -> IO () There are several problems with this: 1. System.Posix.Internals doesn't appear to be an exposed, documented API 2. There is no way to specify a length 3. There is no interface to ftruncate(). 4. If the manpages do conflict, a read of the standard should clarify it. In any case, ftruncate() appears to have been around for a LONG time. Would it be possible to provide a Haskell interface to ftruncate() at least? (truncate() can always be implemented in terms of it.) Thanks,

1 0

RE: ANN: hs-fltk - a binding to the FLTK GUI toolkit
by Simon Peyton-Jones 20 Dec '04

20 Dec '04

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. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Einar | Karttunen | Sent: 19 December 2004 19:11 | To: Sven Panne | Cc: Haskell Libraries ML | Subject: Re: ANN: hs-fltk - a binding to the FLTK GUI toolkit | | Sven Panne <Sven.Panne(a)aedion.de> writes: | > Hmmm, it doesn't work with the GHC from HEAD: | | This seems to be due to revision 1.20 of | http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/iface/Loa dIface.lhs, | and my cvs ghc was older than that. | | This changed things so that one cannot export the contents of a hidden module, e.g. | | module Exposed (module Private) where | import Private | | If this is the intended behavior things can be made to work by changing | the all the modules to be exposed in Setup.description.in. | | - Einar Karttunen | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

2 1

Cabal suggestions
by Ross Paterson 20 Dec '04

20 Dec '04

* How about replacing the modules field with hidden-modules, to avoid repetition? * setup install and register have --user and --system flags, which seem to offer a choice at that point, but one has to have anticipated this choice when supplying the --prefix flag to configure. How about a --user-prefix flag to configure (with a sensible default) to say where user packages are installed? * It would be useful to have alternatives in dependencies, e.g. HGL could depend on X11 | Win32. * The compilerBinaryName for Hugs should be "ffihugs" (which compiles FFI stubs). * moveSources seems misnamed, because it copies rather than moving, and operates on the relult of building as well as sources. * Could singleStanza ignore comments like splitStanzas does? * How about using a new data type for parse results instead of Either? That would remove the dependency on mtl, which will help with bootstrapping. I know there is Distribution.Compat.Error, but that defines a Monad instance for Either, so it one uses that there'll be trouble later if some program includes both Cabal and mtl.

2 2