April 2007 - Libraries

problem with unix package
by Frederik Eaton 23 Apr '07

23 Apr '07

Hello, I am having trouble loading the unix package. I am not sure what I am doing wrong. I have just installed it from hackage. As you can see below, the error message complains about an unknown symbol 'lstat', which is not in libc. [1]$ ghci -package unix ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. ghc-6.6: /home/frederik/lib/unix-2.0/ghc-6.6/HSunix-2.0.o: unknown symbol `lstat' Loading package unix-2.0 ... linking ... ghc-6.6: unable to load package `unix-2.0' [1]$ nm -D /lib/libc-2.5.so | grep -w lstat [1]$ This is an unstable Debian installation. When I try the same on a system with ghc 6.4.2 and unix-1.0, there is no problem. That system has libc 2.3.6, which also lacks an 'lstat' symbol. Thank you for your help. Frederik

5 16

filepath broken with Cabal 1.1.6
by Neil Mitchell 22 Apr '07

22 Apr '07

Hi, For users of Cabal 1.1.6, the currently checked in filepath Setup.hs script won't work - it gives: >runghc Setup.hs configure Setup.hs:17:30: Couldn't match expected type `UserHooks' against inferred type `Maybe UserHooks' Expected type: Hook a Inferred type: PackageDescription -> LocalBuildInfo -> Maybe UserHooks -> BuildFlags -> IO () In the second argument of `($)', namely `buildHook defaultUserHooks' In the `buildHook' field of a record Can this be fixed? I know the Setup.hs only really serves GHC's purposes, and I think its Ian's work. I also think its possibly the same for other packages? It would be a shame if we make everyone upgrade to have a libary which we've not put in base so they can upgrade it separately... Thanks Neil

2 2

Integrating Cabal, Haddock, HsColour
by Roberto Zunino 21 Apr '07

21 Apr '07

I've just extended Cabal so to generate docs with links to highlighted sources. Now ./Setup configure ./Setup haddock --link-to-hscolour ./Setup hscolour --css my_own_stylesheet.css generates HTML as this one: (run on Cabal itself) http://www.di.unipi.it/~zunino/tmp/dist/doc/html/Cabal/Distribution-Program… Click on the "Source" links on the right. You will be sent to the exact line. The whole Cabal docs+sources are online. Colours have been chosen to match my emacs configuration :-P . This relies on a couple of minor tweaks to Haddock and HsColour which I darcs-sent this morning to the authors. Comments are welcome. - Is this worth including in the next Cabal version? - Are the options above good choices? - Is the directory tree OK? Currently Haddock creates (under dist/doc/html) lib/Module.html lib/Module-SubMod.html lib/exe1/... lib/exe2/... while ./Setup hscolour adds (also under dist/doc/html) lib/src/Module.html lib/src/Module-Submod.html lib/src/hscolour.css lib/exe1/src/... lib/exe2/src/... (lib is the package name, exeN are the targets of the other stanzas in the .cabal file) This is so that Haddock can use relative links to sources. - Currently, you can run ./Setup haddock and ./Setup hscolour in any order, and they work. You can run haddock without hscolour, and vice versa. Links will be broken only if you pass --link-to-hscolour and do not run hscolour. Should I instead merge these subcommands so to have a single ./Setup haddock --hscolour running everything? Zun.

2 1

anyone interested in developing a Language.C library?
by Duncan Coutts 21 Apr '07

21 Apr '07

Hi all, If anyone is interested in developing a Language.C library, I've just completed a full C parser which we're using in c2hs. It covers all of C99 and all of the GNU C extensions that I have found used in practise, including the __attribute__ annotations. It can successfully parse the whole Linux kernel and all of the C files in all the system packages on my Gentoo installation. It's implemented as an alex lexer and a happy parser. The happy grammar has one shift/reduce conflict for the dangling if/then/else issue (which could be hidden by using precedence but it's clearer not to). So if someone is interested in developing a more widely usable Language.C library, I think this would be a good place to start. There's plenty to do however: * The c2hs C AST is ok but probably not enough for a general purpose library. * The parser currently uses some other c2hs infrastructure which would need disentangling to pull the parser out (mostly identifiers and unique name supply management). * It does not record everything into the parse tree, eg __attribute__s are parsed but ignored. * It does no semantic analysis after parsing (though other bits of c2hs to a very little) * In at least one place the parser is deliberately too liberal (to avoid ambiguities) which would require simple extra checks after parsing to detect. * The lexical syntax has not been checked against the spec fully, it is probably over-liberal in some cases. * I've not done much performance work, the lexer has not been seriously tuned, it still lexes via a String. Having said that, the performance is not at all bad, on a 3Ghz box it does ~20k lines/sec. * The parser error messages are terrible (it might be interesting to try porting from happy to frown for this purpose) There's probably more stuff, but that's what I can think of right now. So if anyone is interested then let me know, I can give some pointers (hopefully the useful kind, not the void * kind). You can get the code from the c2hs darcs repo: darcs get --partial http://darcs.haskell.org/c2hs/ The C parser bits are under c2hs/c/ Duncan Licensing: It's not 100% clear. At the moment it's marked as GPL, but it's derived from several sources so we need to be careful about that. Personally I'm happy to use LGPL. It derives from c2hs obviously, which is GPL, though we could enquire about re-licencing, especially since there is very little of c2hs stuff used in it any more. It also derives partly from James A. Roskind's C grammar (in particular the grammar of declarations). His copyright license is fairly liberal but this need double-checking. It also derives from the C99 spec and I read the comments in the gcc C parser as a guide to GNU C's extensions to the C grammar (no code or comments were copied however). Testing: I tested it thus far by writing a little gcc wrapper script, so you can build any ordinary bit of C software using this wrapper and it'll call gcc with the same args but it'll also try and parse the input file. It reports into a log file. I've not tried the gcc C parser testsuite. This approach is probably good for other tests like trying to see if parsing and pretty printing can round-trip correctly; if not identical token streams (since parsing drops redundant brackets etc) checking if gcc produces identical .S/.o files. Something that c2hs needs is to calculate sizes of types and structure member offsets correctly. This is also something that could be tested in this style, by comparing on thousands of example .c files with what gcc thinks.

4 4

Automated tests for the libraries?
by Jeffrey Yasskin 19 Apr '07

19 Apr '07

Looking through the libraries, I see a lot of commented out imports of QuickCheck and prop_foo definitions, but no way to run them all without a lot of manual editing of files. There are also a few tests in testsuite/tests/libraries/Data/, but they don't even build with ghc-6.6 because of an import of the hidden module Distribution.Compat.FilePath. It seems like this would make it hard to ensure that things work on more than a few platforms. Is there some automated test suite for the libraries that I'm just missing? Is there a plan for developing one? If not, I'll start a wiki page for ideas and try to get a rudimentary one put together. Jeffrey

6 13

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

14 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 12 Apr '07

12 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