- Libraries - Haskell.org

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

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

package description files
by Ross Paterson 04 Jan '05

04 Jan '05

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.

1 0

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