- Libraries - Haskell.org

New ticket 1274 -- Add a MonadState instance for the Parsec monad
by Maxime Henrion 16 Apr '07

16 Apr '07

Hello all, I just submitted a ticket (#1274) to add a MonadState instance for the GenParser monad of Parsec. As said in the ticket, the only drawback I see to this is the added dependency on mtl. I don't believe this is a real issue though. Of course, comments are welcome. Cheers, Maxime

4 6

Proposal [Trac #1266]: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing
by Jeffrey Yasskin 15 Apr '07

15 Apr '07

See http://hackage.haskell.org/trac/ghc/ticket/1266 for the patch. The basic idea is that insMapNode should survive a duplicate node, and insMapEdge should survive (and insert) an edge whose endpoints weren't yet in the graph. This was impossible for the current type of insMapEdge, so I added a safeInsMapEdge instead. There's also a fairly small test suite in here, which people are welcome to suggest improvements to. I suggest a discussion period of two weeks, ending April 17, unless discussion is still active by then, in which case a week after it dies down. Thanks, Jeffrey Yasskin

1 1

ANN: Haskell Cryptographic Library 4.0.3
by Dominic Steinitz 13 Apr '07

13 Apr '07

I should like to announce the release of a new version of the Haskell Cryptographic Library based on the proposal at http://www.haskell.org/haskellwiki/Crypto_Library_Proposal. See http://www.haskell.org/crypto/ for more details. There is now no dependency on NewBinary. The downside is the library contains no support for ASN.1 which will be released in separate package. Dominic.

5 4

HEADS UP: Windows Vista users
by Simon Marlow 12 Apr '07

12 Apr '07

I've discovered a gotcha that happens when trying to use Cabal on Windows Vista. If you compile Setup.lhs to a binary (as I often do), with something like 'ghc --make Setup', and then try to run it, you'll get something like this: $ ./Setup configure Setup.exe: Permission denied This is due to a highly dubious security "feature" in Vista whereby it detects that you might be trying to run an installer-type program and refuses to execute the binary without elevated permissions. The idea is that ordinary users won't be confused when their installer fails partway through due to insufficient permissions. Unfortunately this works by matching on the name of the binary(!!!!), so names like "setup", "install" etc. are affected (there isn't a complete list, apparently). Other casualties are: * cabal-setup (compiles Setup.hs to setup.exe) * The GHC build system, which now uses Cabal * 'make install', which runs /usr/bin/install.exe More details in this MSDN thread: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1021146&SiteID=1 and this Cygwin thread: http://www.cygwin.com/ml/cygwin/2006-12/msg00518.html Fortunately you can turn off the behaviour: Start->Run->secpol.msc, then Security Settings -> Local Policies -> Security Options ! UAC: Detect application installations and prompt for elevation. It appears you need to reboot for the change to take effect. The right workaround is to add a manifest to the binary asking for no security elevation, apparently this is quite easy. We'll need to get GHC to do this for every binary it generates in the future. For now, I'll put a note in the building guide and FAQ, and make a ticket for GHC 6.6.2 to do the manifest thing. Cheers, Simon

1 0

What I learned from my first serious attempt low-level Haskell programming
by Stefan O'Rear 11 Apr '07

11 Apr '07

As a learning excersize, I re-wrote and re-optimized Data.Binary.Builder yesterday. 1. Intuition is NOT your friend. Most obvious pessimizations I made were actually wins, and vice versa. 2. Parameters are very expensive. Our type of functions that build (ignoring CPS for the time being) was MBA# -> Int# -> [ByteString], where the Int# is the current write pointer. Adding an extra Int# to cache the size of the array (rather than calling sMBA# each time) slowed the code down ~2x. Conversely, moving the write pointer into the byte array (storing it in bytes 0#, 1#, 2#, and 3#) sped the code by 4x. 3. MBA# is just as fast as Addr#, and garbage collected to boot. 4. You can't keep track of which version of the code is which, what is a regression, and what is an enhancement. Don't even try. Next time I try something like this I will make as much use of darcs as possible. 5. State# threads clog the optimizer quite effectively. Replacing st(n-1)# with realWorld# everywhere I could count on data dependencies to do the same job doubled performance. 6. The inliner is a bit too greedy. Removing the slow-path code from singleton doesn't help because popSingleton is only used once; but if I explicitly {-# NOINLINE popSingleton #-}, the code for singleton itself becomes much smaller, and inlinable (15% perf gain). Plus the new singleton doesn't allocate memory, so I can use even MORE realWorld#s. And probably a few more I forgot about because of #4. The code is online at http://members.cox.net/stefanor/hackedbuilder if anyone cares (but see #4). Some parting numbers: (Builder7 is my current version, Builder1 is the unmodified rossp/kolmodin builder) stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder7 Bench.hs ; time ./Bench 2 10000000 330000000 real 0m5.580s user 0m5.540s sys 0m0.032s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder7 -DUNROLL Bench.hs ; time ./Bench 2 10000000 330000000 real 0m2.948s user 0m2.908s sys 0m0.036s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder1 Bench.hs ; time ./Bench 2 10000000 330000000 real 0m55.708s user 0m54.695s sys 0m0.208s stefan@stefans:~/hackedbuilder$ ghc -v0 --make -O2 -fforce-recomp -DBUILDER=Builder1 -DUNROLL Bench.hs ; time ./Bench 2 10000000 330000000 real 0m25.888s user 0m25.546s sys 0m0.156s stefan@stefans:~/hackedbuilder$ gcc -O2 -march=pentium4 CBuilder.c -o CBuilder ; time ./CBuilder 10000000 real 0m0.861s user 0m0.860s sys 0m0.000s Stefam

7 12

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 08 Apr '07

08 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 06 Apr '07

06 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