July 2004 - Libraries

Use of cpp
by Adrian Hey 14 Jul '04

14 Jul '04

Hello, I've just modified some Haskell code from the AVL library to explicitly use ghc unboxed Ints in some routines. Unfortunately, I've broken portability by doing this and was considering some cpp magic to restore portability. But IIRC, the use of cpp is discouraged for Haskell library infrastructure. Is that so? If so, what should I use instead? Is cpphs the way to go? Thanks -- Adrian Hey

5 7

RE: System.Process
by Simon Marlow 08 Jul '04

08 Jul '04

On 07 July 2004 22:59, Peter Simons wrote: > I was wondering what the state of the System.Process module > described on > > http://haskell.org/hawiki/ExternalCommands > > is? > > I have tried to use the various POpen-like implementations > out there, but _none_ of them works with the most current > GHC. Is there any way to communicate with external programs > at the moment? Posix-only would be suffice at the moment. I posted code with POSIX & Windows versions recently: http://www.haskell.org//pipermail/libraries/2004-June/002265.html It's nearly finished, I hope to get it into GHC 6.4. You need to compile with -threaded in order to get a non-blocking waitForProcess. Cheers, Simon

2 1

Subprocesses (was: [ANNOUNCE] shell-haskell 1.0.0)
by Simon Marlow 08 Jul '04

08 Jul '04

Libraries people, There are currently two ways to create and communicate with external processes: - System.Cmd.system (very basic, doesn't give you access to the process's output but you can use shell primitives to redirect its input/output). - Posix.runProcess (can specify Handles for the process's input/output, but it doesn't create pipes so you can't actually communicate with the subprocess using these Handles.). - POpen.popen (can specify an input String, and gives you lazy output Strings. No interactive communication is possible.) Ok, *three* ways. System.Cmd.system, Posix.runProcess, POpen.popen, and shell-haskell. Er. *Four* ways. David Sankel's shell-haskell creates pipes for stdin/stdout/stderr, and lets you communicate interactively with the sub-process via Handles. It could do with a way to specify the environment and working directory of the sub-process (ala POpen and runProcess), but apart from that it seems to be the most flexible of the four. It could be simplified slightly by using one Handle rather than two for stdin/stdout. We should think about what functionality we want to provide in the core libraries. My preference would be to go for a full version with three pipes (like shell-haskell) and perhaps one or two more specialised versions covering common cases (I don't know what these should be, though). What do people think? Cheers, Simon -----Original Message----- From: haskell-admin(a)haskell.org [mailto:haskell-admin@haskell.org] On Behalf Of David Sankel Sent: 06 May 2003 03:06 To: haskell(a)haskell.org Subject: [ANNOUNCE] shell-haskell 1.0.0 =================== shell-haskell 1.0.0 =================== shell-haskell provides utilities to communicate with other process's via Haskell code. This library can be used for something as simple as getting the output of another program or as complex as interacting with an interpreter. see http://www.electronconsulting.com/shell-haskell for details. David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 10

RE: DData, again
by Simon Marlow 05 Jul '04

05 Jul '04

On 02 July 2004 21:28, Alastair Reid wrote: >> i would prefer that the library had an independent distribution, >> and can be easily downloaded and experimented with. > > Perhaps it would be a good candidate for the new packaging > infrastructure? > > btw Note that distributing it independently doesn't mean that it > can't live in the main cvs.haskell.org cvs repository. (The converse > doesn't appear to be true: if you want it to become part of the > standard distribs, it probably has to live in cvs.haskell.org just to > keep it easy for the distrib builders who tend to like to be able to > create branches, tag the repository when they make a release, etc.) As far as the main libraries repository goes, I'd like to split this into two stages: 1. Bring in Map, Set, IntMap, and IntSet. I think we're all agreed that these are the right thing. 2. Resolve the outstanding issues regarding overloaded sequences. I find Ross's arguments in favour of a Sequence class fairly persuasive, but I haven't heard many other comments on the subject. Cheers, Simon

1 0

DData
by Christian Maeder 02 Jul '04

02 Jul '04

Hi, may I warm up an old subject? I would appreciate if at least the Map and the Set module could be added to the base package, soon! DData.Set and the current Data.Set can be merged together (as Sven Panne mentioned earlier). Data.FiniteMap and Data.Map should co-exist for a while. The current Data.FiniteMap and Data.Set have various missing functions and instances. It would make sense to add Data.Bag also (but I don't use Bags currently) (I also don't care about Seq, Queue and Int-specializations.) The last proposal was made by JP Bernardy: http://users.skynet.be/jyp/DData/doc Daan wanted to look into it. My experiments (with large maps) wrt. performance (and memory consumption with and without optimization) of both Map and FiniteMap implementations revealed differences, but no crucial ones. "FiniteMap Int a" performs better than "Map Int a", but not as good as "IntMap a", but the differences are unimportant for us. (We would need a pure HashMap with O(1) lookup while extending the Map) Christian

4 3