April 2007 - Libraries

openTempFile only defined on GHC
by Neil Mitchell 10 Apr '07

10 Apr '07

Hi, >From the System.IO export list: #ifdef __GLASGOW_HASKELL__ openTempFile, openBinaryTempFile, #endif So we have a standardised module with a standardised interface which is totally broken on all but one compiler. Can this please be either: 1) Implemented for all compilers 2) Removed, and then potentially re-added by the proper libraries submission process I hope the new libraries submission process will stop things like this being added in future, without appropriate thought. Thanks Neil

5 10

Proposal [Trac #1212]: add IPv6 support to network library
by Bryan O'Sullivan 07 Apr '07

07 Apr '07

Here's the Trac ticket: http://hackage.haskell.org/trac/ghc/ticket/1212 This proposal adds two standard protocol-independent functions to Network.BSD to allow the networking code to work with both IPv6 and IPv4 addresses and protocols. getAddrInfo is the equivalent of getaddrinfo from RFC 2553. getNameInfo is the equivalent of getnameinfo from RFC 2553. These functions rely on a few new types: AddrInfo AddrInfoFlags NameInfoFlags Several global values provide mnemonics for query hints and flags. Both of these functions are available on all modern operating systems. They unify name and service lookup for IPv4 and IPv6. The code has been autoconfiscated so that it will not be compiled if IPv6 support is not available. I have not touched existing code in any way, save to add and extend the smallest possible number of types and functions so that IPv6 addresses can be accommodated. I would suggest a consideration period of one week, since my changes are non-intrusive in nature. Regards, <b

5 22

Proposal: reduce base from the top
by Simon Marlow 05 Apr '07

05 Apr '07

This is an attempt to propose a set of changes that we could reasonably make in the GHC 6.8 timeframe, that would significantly reduce the size of base and give us more flexibility to independently develop packages. This is not an attempt to solve all the issues we have in one go, but a practical incremental step towards the goal. I'm not trying to make base compiler-independent for example; that's a worthy goal, but it's not clear (at least to me) how to get there yet. What I'm doing here is disentangling the dependencies from the top down. We started on this path before GHC 6.6 (see http://hackage.haskell.org/trac/ghc/ticket/710) this proposal will clarify some the details of the next stage. There may be dependencies I've missed, but as far as I'm aware all of the following is possible without any significant rewriting of code. These reoganisations will allow more reuse: for example, more libraries will be able to make direct use of the unix/Win32 packages rather than being limited to the primitives available in the base package, so cleanups will be possible after the reoganisation. There are several things I'm not completely sure about, and some naming issues to resolve, so please take a look and comment if you can. I'll make one request regarding comments: please don't suggest renaming modules at this point. There are various modules whose names I'm aware are contentious, but I think it would be a distraction to discuss those as part of this proposal; let's do it separately. Here goes: System.Time --> new package old-time (dep. on unix/Win32) System.Locale --> new package old-locale System.Posix.Signals --> unix (System.Cmd depends on it, but moves to new package process) System.Directory --> new package directory (dep. on filepath, unix/Win32) System.Directory.Internals goes away, use filepath instead Data.Array.* --> new package array (maybe; I'm slightly dubious here) (dep. on concurrent for Data.Array.Diff) Data.Generics.* --> generics (maybe; Data class is defined for everything and is derivable) Data.ByteString.* --> fps (dep. on base, generics, array) Control.Concurrent.*, System.Timeout --> new package concurrent (needed by Data.Unique, where to move it?) Control.Parallel.* --> new package parallel System.Process, System.Cmd --> new package process (dep. on concurrent) Control.Applicative Data.Foldable, Data.Traversable Data.Map, Data.IntMap, Data.Set, Data.IntSet Data.Sequence, Data.Tree Data.HashTable Data.Graph ---> new package collections? containers? or split further? (dep. on array, generics, concurrent) System.Console.GetOpt ---> new package getopt? consoleutils? Text.PrettyPrint.* ---> new package pretty System.Random ---> new package random (modify to use time, not old-time) Other modules we could move: Text.Printf, Data.Unique, Data.Monoid, System.CPUTime. Topological sort of core packages with dependencies --------------------------------------------------- base unix/Win32 (base) generics (base) concurrent (base) parallel (base) filepath (base) Cabal (base) readline (base) regex-base (base) regex-posix (base, regex-base) regex-compat (base, regex-base, regex-posix) parsec (base) stm (base) template-haskell (base) pretty (base) (could drop from core-packages) getopt (base) (could drop from core-packages) old-locale (base) old-time (base, unix/Win32) array (base, generics, concurrent) fps (base, generics, array) process (base, unix/Win32, concurrent) directory (base, unix/Win32, filepath) time (base, unix/Win32) random (base, unix/Win32, time) haskell98 (old-time, old-locale, random, directory, process) containers (base, array, generics, concurrent)

10 14

darcs patch: Fix precedence passing for patterns in L... (and 1 more)
by Stefan O'Rear 05 Apr '07

05 Apr '07

Testing = typechecked Mon Apr 2 08:26:34 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Fix precedence passing for patterns in LamE (fixes \((:) x xs) -> x misprinting) Mon Apr 2 08:28:54 PDT 2007 Stefan O'Rear <stefanor(a)cox.net> * Pretty-print an empty list of fundeps without '|' (should fix #1260)

2 1

System.Posix.User.getAllUserEntries bugfix
by Pixel 03 Apr '07

03 Apr '07

it seems setpwent is never called, and so getAllUserEntries can only be used once. Here is a suggested fix: (if i should be posting this somewhere else (a bug system...), please tell me)

1 0

Re: [Haskell] ANNOUNCE: new FGL version (April 2007)
by Andrew Wagner 03 Apr '07

03 Apr '07

Martin, Thanks for your work on this very interesting library. For the record, I was able to build it here on an x86 architecture under ghc 6.6, but only with -fglasgow-exts, and one other minor tweak. If anyone wants details, let me know. Andrew On 4/2/07, Martin Erwig <erwig(a)eecs.oregonstate.edu> wrote: > FGL - A Functional Graph Library, Version: April 2007 > ===================================================== > > A new release of the Functional Graph Library for Haskell > is available at: > > http://eecs.oregonstate.edu/~erwig/fgl/haskell/ > > This release fixes some bugs in the implementation of > several basic inspection functions. > > > -- > Martin > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

proposal: add 'unsafeCoerce'
by Malcolm Wallace 02 Apr '07

02 Apr '07

Currently, all implementations provide either the 'unsafeCoerce' or 'unsafeCoerce#' functions, but they live in implementation-specific locations. This proposal is to adopt the Haskell'98-compatible name 'unsafeCoerce', and to add it to the standard base library package. Suggested location: Data.Function.Unsafe? http://hackage.haskell.org/trac/ghc/ticket/994 Regards, Malcolm

17 45

System.Process bugs on Unix
by John Goerzen 02 Apr '07

02 Apr '07

I have another concern about System.Process. I have this code: (recordfn, recordh) <- openTempFile macdir "new-" ... (c1, macroh, c2, xmacroph) <- runInteractiveProcess "xmacrorec2" ["-k", "0xffff"] Nothing Nothing ... grepph <- runProcess "egrep" ["-v", "^(ButtonRelease|ButtonPress|MotionNotify)"] Nothing Nothing (Just macroh) (Just recordh) Nothing Now, egrep is dying with: grep: (standard input): Resource temporarily unavailable And strace shows that, sure enough, read(0,...) in grep is getting EAGAIN. Sounds like somebody forgot to take the fd out of non-blocking mode. This renders runProcess pretty well useless, IMHO. -- John

3 7

Dubious behavior in TH pretty printer
by Stefan O'Rear 02 Apr '07

02 Apr '07

The Template Haskell pretty-printer handles infix/prefix distinction improperly, causing text generated using it to be unparsable. Example: stefan@stefans:~/daanpp$ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7.20070323, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr Loading package template-haskell ... linking ... done. GHC.Num.+ 2 2 I am trying to use the Template Haskell AST system for internal representation of terms in a derivation library that can output Haskell or feed directly into a splice. This "bug", unfixed, would force me to fork the TH pretty printer. What would people think of a patch changing the behavor to "Always produce parsable output"? (Yes, I'm offering to implement it.) Stefan

3 4

Adding System.FilePath
by Neil Mitchell 01 Apr '07

01 Apr '07

Hi, When it comes to adding System.FilePath, we seem to have reached a concensus of indecision, so I am going to attempt to set out the various options, and see if we can pick one. 1) Do not let programmers type "import System.FilePath", i.e. do not include the module No one seems to be advocating this. 2) Let programmers type "import System.FilePath" and have it work in Cabal Setup.hs files, and in all Cabal built programs without requiring the user specify that they are using the filepath package. This is what everyone wants. Within this there are two approaches being advocated: a) Add to base. b) Add as a library which we demand all Haskell compilers ship, and tweak Cabal to automatically use this library at all times. Option a involves absolutely no additional work for me - the patch has been posted to this mailing list. Option b involves Cabal hacking, establishing new procedures, coming up with a definition of libraries which are always available etc. It is likely that option b will be required once (if ever) base is split up. I certainly don't have time to do option b. So can I propose we add filepath, with this agreement that once (someone else) gets around to doing option b, we can split it out afterwards? The particular argument for upgrading the filepath library I think is not important - I never intend to do more filepath hacking. Someone might add one or two functions, but thats about the most I can invision. It's not a particularly pleasant job, its ugly - the only reason I started this was because the alternative is having everything broken on Windows - something I do care about. Thanks Neil

15 73