October 2008 - Haskell-Cafe

OT: Haskell desktop wallpaper?
by Magnus Therning 11 Oct '08

11 Oct '08

This morning I got tired of my desktop wallpaper (one that ships with Debian's Gnome packages). Typing "haskell desktop wallpaper" yeilded a lot of links to wallpapers with Colleen Haskell, while she's a beautiful lady it wasn't exactly what I was hoping to find. Hence this email. Where can I find some nice wallpapers inspired by Haskell, or maybe even created by Haskell code? Oh yes, wallpapers related to XMonad would do, I suppose ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

10 13

External Sort and unsafeInterleaveIO
by Ben 11 Oct '08

11 Oct '08

hi folks -- a haskell newbie here, searching for comments and wisdom on my code. i had a project to try to implement "external sort" in haskell as a learning exercise. (external sort is sorting a list that is too large to fit in main memory, by sorting in chunks, spooling to disk, and then merging. more properly there probably should be multiple stages, but for simplicity i'm doing a one-stage external sort.) the trick is the number of files can quickly grow very large, so it is best to use one large file and seek inside it around. however as one can imagine the order-of-IO-operations becomes a bit tricky, if you're seeking file handles around underneath Data.ByteString.Lazy's nose. but late this night after not thinking about it for a while i had a brainstorm: rewrite hGetContents to keep the handle position in the right place! it's all about judicious use of unsafeInterleaveIO..... it seems to be rather fast, strangely faster than the usual "sort" at times. it also seems to have nice memory characteristics, though not perfect. it's hard to test because the normal "sort" function takes too much RAM on large lists, making my computer swap like mad. i'd appreciate any testing, comments and suggestions from the haskell gods out there. my thanks to the Data.ByteString.Lazy, Data.Binary, and Data.Edison people, who made this rather easy, once I grokked unsafeInterleaveIO. thanks and take care, B > module ExternalSort where Sort a list of Ords "offline." We're doing this to be able to sort things without taking up too much memory (for example sorting lists too large to fit in RAM.) Laziness is imperative, as is the order-of-operations. > import Control.Monad > import Data.List > import qualified Data.Binary as Bin > import qualified Data.ByteString.Lazy as B > import qualified Data.ByteString as P (hGetNonBlocking, null) > import Data.ByteString.Base (LazyByteString(LPS)) > import Foreign.Storable (sizeOf) > import System.IO (openFile, hClose, hSeek, hTell, hIsEOF, hWaitForInput, > Handle, IOMode(ReadMode, WriteMode), > SeekMode(AbsoluteSeek)) > import System.IO.Unsafe (unsafeInterleaveIO) > > import qualified Data.Edison.Seq.ListSeq as LS > import qualified Data.Edison.Coll.SplayHeap as Splay Conceptually, we sort a list in blocks, spool blocks to disk, then merge back. However for IO performance it is better to read off chunks of elements off the sorted blocks from disk instead of elements-at-a-time. It would be better if these were in KBytes instead of # of elements. > blocksize :: Int > blocksize = 10000 Turn a list into a list of chunks. > slice :: Int -> [a] -> [[a]] > slice _ [] = [] > slice size l = (take size l) : (slice size $ drop size l) Turn a list into a list of blocks, each of which is sorted. > blockify :: (Ord a) => Int -> [a] -> [[a]] > blockify bsize l = map sort $ slice bsize l Serialize a block, returning the (absolute) position of the start. > dumpBlock :: (Ord a, Bin.Binary a) => Handle -> [a] -> IO Integer > dumpBlock h b = do > start <- hTell h > B.hPut h $ Bin.encode b > return start The actual sorting function. We blockify the list, turning it into a list of sorted blocks, and spool to disk, keeping track of offsets. We then read back the blocks (lazily!), and merge them. > externalSort [] = do return [] > externalSort l = do > h <- openFile "ExternalSort.bin" WriteMode > idx <- mapM (\x -> dumpBlock h x) (blockify blocksize l) > hClose h > h <- openFile "ExternalSort.bin" ReadMode > blocks <- mapM (\x -> do {bs <- hGetContentsWithCursor h x; > return $ Bin.decode bs}) idx > return (kMerge $ blocks) Merging chunks. K-way merge (and in fact external sort in general) is detailed in Knuth, where he recommends tournament trees. The easiest thing is to probably use one of Okasaki's heaps. I'll use splay heaps, because I don't know any better. It would be better if I changed Ord for blocks to only check the first element. > kMerge :: (Ord a) => [[a]] -> [a] > kMerge [] = [] > kMerge l = > let h = Splay.fromSeq l in > kM (Splay.minElem h) (Splay.deleteMin h) > where > kM :: (Ord a) => [a] -> Splay.Heap [a] -> [a] > kM l h > | h == Splay.empty = l > | otherwise = > let next = Splay.minElem h > (f, b) = span (\x -> x <= head next) l > in > f ++ (kM next (if null b then Splay.deleteMin h > else (Splay.insert b $ Splay.deleteMin h))) > > kMergeSort :: (Ord a) => [a] -> [a] > kMergeSort l = kMerge $ blockify blocksize l This is a version of hGetContents which resets its handle position between reads, so is safe to use with interleaved handle seeking. > hGetContentsWithCursor :: Handle -> Integer -> IO B.ByteString > hGetContentsWithCursor = hGetContentsWithCursorN defaultChunkSize > > hGetContentsWithCursorN :: Int -> Handle -> Integer -> IO B.ByteString > hGetContentsWithCursorN k h start = (lazyRead start) >>= return . LPS > where > lazyRead start = unsafeInterleaveIO $ loop start > > loop start = do > hSeek h AbsoluteSeek start > ps <- P.hGetNonBlocking h k > --TODO: I think this should distinguish EOF from no data available > -- the otherlying POSIX call makes this distincion, returning either > -- 0 or EAGAIN > if P.null ps > then do eof <- hIsEOF h > if eof then return [] > else hWaitForInput h (-1) > >> (loop start) > else do > pos <- hTell h > pss <- lazyRead pos > return (ps : pss) > > defaultChunkSize :: Int > defaultChunkSize = 32 * k - overhead > where k = 1024 > overhead = 2 * sizeOf (undefined :: Int)

5 6

Re: [Haskell-cafe] Haskell in Artificial Intelligence
by Chryssochoidis Christos 11 Oct '08

11 Oct '08

On 11 Οκτ 2008, at 10:57 ΠΜ, Krasimir Angelov wrote: > Hi Christos > > We use Haskell for natural language processing. See here: > > http://www.cs.chalmers.se/~aarne/GF/ > > Best regards, > Krasimir > Thank you very much for your response Krasimir. Best regards, Christos > On Fri, Oct 10, 2008 at 8:45 PM, Christos Chryssochoidis > <c.chryssochoidis(a)gmail.com> wrote: >> Greetings, >> >> I'm interested in doing a survey about the use of Haskell in the >> field of >> Artificial Intelligence. I searched in Google, and found in the >> HaskellWiki, >> at www.haskell.org/haskellwiki/Haskell_in_industry, two >> organizations that >> use Haskell and do work related to AI. Besides that, I haven't >> found much >> else. Could somebody from the Haskell community give me some >> pointer to a >> project or system related to AI that uses Haskell? >> >> Thank you very much in advance. >> >> - CC >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>

1 0

Re: [Haskell-cafe] Interesting new user perspective
by Donn Cave 10 Oct '08

10 Oct '08

Quoth John Goerzen <jgoerzen(a)complete.org>: | Uh... yes. Opening and closing files, command-line parsing, etc -- | needed by almost every program. Aside from some very simple | stdin-to-stdout filters, it is difficult to imagine a program where | you don't need to open a file! That's how it seems to me, too, and moreover maybe the most generally recognizable API. With a GUI or a database, you're going to need to present a fair amount of background to just about everyone, but files, command lines etc. are common to nearly every programming language. If the virtues of Haskell can't be presented in this context, then maybe it isn't such a generally useful language that people ought to be worried about learning it. Donn Cave, donn(a)avvanta.com

1 0

ANNOUNCE: maccatcher-1.0.0
by Jason Dusek 10 Oct '08

10 Oct '08

This simple little package obtains a MAC address on *NIX and Windows. It is known to work on Linux, OS X and Windows XP. There is no C fanciness in this package -- it relies on shell commands. The MAC is cached after the first query, using an IORef (I am open to other ideas, but this seemed sufficient). -- _jsn |This simple little package...| http://hackage.haskell.org/cgi-bin/hackage-scripts/package/maccatcher-1.0.0

2 2

Problem with package consistency on Hackage
by Antoine Latter 10 Oct '08

10 Oct '08

Folks, I'm not sure who to email about this, but hopefully someone on the cafe knows: On the machine which builds the Hackage packages the 'binary' package is built against 'bytestring-0.9.1.2', however the package I just uploaded gets built against 'bytestring-0.9.1.3' which leades to typecheck failures (the ByteStrings I get from the 'binary' package are not the same as all the other ByteStrings). See: http://hackage.haskell.org/packages/archive/uuid/1.0.0/logs/failure/ghc-6.8 If I wait will Hackage eventually become consistent? How does this work? Thanks, Antoine

3 2

ANNOUNCE: darcs 2.1.0 (corrected!)
by Eric Kow 10 Oct '08

10 Oct '08

This is a correction to my previous announcement. I had misgrepped the ChangeLog. There are only 20 bug fixes and 7 new features since 2.0.2. Sorry! ====== Hi all, I am delighted to announce the release of darcs 2.1.0, available at http://darcs.net/darcs-2.1.0.tar.gz What has changed? ----------------- This version provides over 20 bug fixes and 7 new features since darcs 2.0.2. The most notable changes are: * Defaulting to darcs-2. The darcs initialize command now creates darcs-2 format repositories by default. This change will make the the improved conflict handling and merging semantics from darcs 2 available to more users. Note that no action is required on your part. Darcs will continue working with all pre-existing repositories. You can explicitly request an old-fashioned repository if needed. * Better HTTP support. Dmitry Kurochkin has refined our HTTP support and fixed several http-related bugs from darcs 2.0.2. There is also an experimental --http-pipelining feature you can enable on the command line (or in your defaults file) for faster downloading. Note: --http-pipelining is enabled by default for libwww, and also for libcurl 7.19.1 (not yet released at the time of this writing) * Repository correctness. David Roundy has resolved a longstanding 'pending patch' regression (originally reported on 2008-02). Needless to say the offending case has been moved to our regression testing suite See the attached ChangeLog for more details. What should I do? ----------------- Upgrade! Binary versions should be available shortly, either from your favourite package distributor or by third party contributors. Other than installing the new darcs, no action is required on your part to perform this upgrade. Darcs 2, including this particular version, is 100% compatible with your pre-existing repositories. If you have not done so already, you should consider using the hashed repository format in place of your current old-fashioned repositories. This format offers greater protection against accidental corruption, better support for case insensitive file systems. It also provides some very nice performance features, including lazy fetching of patches and a global cache (both optional). If darcs 1 compatibility is not a concern, you could also upgrade your repositories all the way to the darcs 2 format. In addition to the robustness and performance features above, this gives you the improved merging semantics and conflicts handling that give darcs 2 its name. More details about upgrading to darcs 2 here: http://wiki.darcs.net/index.html/DarcsTwo What comes next? ---------------- We will now be shifting to a time based release model, with the next darcs release planned for January 2009. For the next release of darcs, we will be focusing on optimising darcs's day to day performance issues. We want darcs to fetch repositories as fast as it possibly can over a network, and we especially want to rehabilitate known slow commands like darcs annotate. We believe that a few simple and practical changes can really improve the darcs experience for most users. Think you can help? We would love to hear from you. In fact, the first darcs hacking sprint (25-26 October) is fast approaching! We have three venues available: Brighton, Paris and Portland and everybody is invited to come hack. See http://wiki.darcs.net/index.html/Sprints for details. Thanks everybody, and enjoy! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

3 2

compiling ghc-6.8.3: unrecognized command line option "-fconfigure-option=" (SOLVED)
by Poor Yorick 10 Oct '08

10 Oct '08

For anyone who might experience the same problem... Intalling ghc-6.8.3, the following error occurred: make -C libraries all make[1]: Entering directory `/path/to/src/gh c-6.8.3/ghc-6.8.3/libraries' rm -f -f stamp/configure.library.*.base base/unbuildable ( cd base && setup/Setup configure \ --enable-library-profiling --enable-split-objs \ --prefix=/NONEXISTANT \ --bindir=/NONEXISTANT \ --libdir=/NONEXISTANT \ --libsubdir='$pkgid' \ --libexecdir=/NONEXISTANT \ --datadir=/NONEXISTANT \ --docdir=/NONEXISTANT \ --htmldir=/NONEXISTANT \ --interfacedir=/NONEXISTANT \ --with-compiler=../../compiler/stage1/ghc-inplace \ --with-hc-pkg=../../utils/ghc-pkg/ghc-pkg-inplace \ --with-hsc2hs=../../utils/hsc2hs/hsc2hs-inplace \ --with-ld=/path/to/bin/ld \ --haddock-options="--use-contents=../index.html \ --use-index=../doc-index.html" \ --configure-option='--prefix=/path/to/ghc-6.8.3' --configure-option='CC=gcc -m32' --configure-option='LDFLAGS=-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64 --configure-option=' --configure-option='CPPFLAGS=-I/path/to/include --configure-option=' \ --configure-option=--with-cc=gcc ) \ && touch stamp/configure.library.build-profiling-splitting.base || touch base/unbuildable Configuring base-3.0.2.0... configure: WARNING: Unrecognized options: --with-hc, --with-hc-pkg checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. config.log showed this: configure:2171: checking for C compiler default output file name configure:2193: gcc -I/path/to/include --configure-option= -Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64 --configure-option= conftest.c >&5 cc1: error: unrecognized command line option "-fconfigure-option=" cc1: error: unrecognized command line option "-fconfigure-option=" configure:2197: $? = 1 configure:2235: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Haskell base package" | #define PACKAGE_TARNAME "base" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "Haskell base package 1.0" | #define PACKAGE_BUGREPORT "libraries(a)haskell.org" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2242: error: C compiler cannot create executables See `config.log' for more details. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_env_CC_set=set ac_cv_env_CC_value='gcc -m32' ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value='-I/path/to/include --configure-option=' ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64 --configure-option=' ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_prog_ac_ct_CC=gcc ## ----------------- ## ## Output variables. ## ## ----------------- ## CC='gcc' CFLAGS='' CPP='' CPPFLAGS='-I/path/to/include --configure-option=' DEFS='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' EXEEXT='' GREP='' LDFLAGS='-Wl,-rpath,/path/to/lib -Wl,-rpath,/path/to/lib64 -Wl,--enable-new-dtags -L/path/to/lib -L/path/to/lib64 --configure-option=' LIBOBJS='' LIBS='' LTLIBOBJS='' OBJEXT='' PACKAGE_BUGREPORT='libraries(a)haskell.org' PACKAGE_NAME='Haskell base package' PACKAGE_STRING='Haskell base package 1.0' PACKAGE_TARNAME='base' PACKAGE_VERSION='1.0' PATH_SEPARATOR=':' SHELL='/bin/sh' ac_ct_CC='gcc' bindir='/NONEXISTANT' build_alias='' datadir='/NONEXISTANT' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host_alias='' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='/NONEXISTANT' libexecdir='/NONEXISTANT' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/path/to/ghc-6.8.3' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target_alias='' It turned out that trailing whitespace in the LDFLAGS and CPPFLAGS environment variables were causing these problems. see libraries/Makfile: # We rely on all the CONFIGURE_ARGS being quoted with '...', and there # being no 's inside the values. FLAGGED_CONFIGURE_ARGS = $(subst $(space)',\ $(space)--configure-option=',\ $(space)$(CONFIGURE_ARGS)) -- Yorick

5 4

re: [Haskell-cafe] Functional progarmming at JAOO
by Robert Pickering 10 Oct '08

10 Oct '08

Hi Simon, Thanks for link! I attended JAOO and there were some great talks on programminng langauges, I really enjoyed Guy Steele's introduction to Fortres and Eric Meijer's "Fundamentalist Functional Programming", as well as Anders Hejlsberg's talk, and there were also talks on Scala and F#. I've not been to that many confrences but I all the same I judged this to be a unusally high interester in programming languages for an industrial conference. I got a real fealing that people are much more read to look at "alterative" languages for their projects, I think this can only be good for haskell and the wider FP community in general. Thanks,Robert ---------------------------------------- From: Simon Peyton-Jones <simonpj(a)microsoft.com> Sent: 09 October 2008 20:55 To: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> Subject: [Haskell-cafe] Functional progarmming at JAOO Friends Anders Hejlsberg, the chief designer of C# and a very influential person at Microsoft, gave a keynote talk at JAOO Aarhus last week about "Where are programming languages going". Some of you may have mixed feelings about Microsoft but I thought you might still be interested in this talk because he gives a strong plug to functional programming (and F# in particular, although Haskell gets a mention). FP is one of the three major trends he identifies, the others being concurrency and dynamic languages. http://blip.tv/file/1317881 The FP section starts 22 mins in. Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Functional progarmming at JAOO
by Simon Peyton-Jones 10 Oct '08

10 Oct '08

Friends Anders Hejlsberg, the chief designer of C# and a very influential person at Microsoft, gave a keynote talk at JAOO Aarhus last week about "Where are programming languages going". Some of you may have mixed feelings about Microsoft but I thought you might still be interested in this talk because he gives a strong plug to functional programming (and F# in particular, although Haskell gets a mention). FP is one of the three major trends he identifies, the others being concurrency and dynamic languages. http://blip.tv/file/1317881 The FP section starts 22 mins in. Simon

1 0