October 2007 - Haskell-Cafe

Hugs running on cygwin
by Galchin Vasili 30 Oct '07

30 Oct '07

Hello, When I was downloading and installing the cygwin tool set on my laptop, I noticed that Hugs doesn't appear to be in the toolset. What would it take to get Hugs running on top of cygwin? I guess the Hugs Makefile would have to be modified to correctly link in any of the cygwin "Unix" libraries. Regards, Bill Halchin

1 0

pi
by Jonathan Cast 30 Oct '07

30 Oct '07

I just noticed that pi doesn't have a default definition in the standard prelude, according to the Haddock docs. Why is this? jcc

19 58

PNG files
by Tim Newsham 29 Oct '07

29 Oct '07

I needed something small for writing out png files and didn't see anything, so I wrote my own. It's not really large or general enough yet to warrant a full package. It wouldn't require much work to support other variant formats, such as color. ---- Png.hs ---- {- A small library for creating monochrome PNG files. This file is placed into the public domain. Dependencies: Zlib. -} module Png (png) where import Data.Array import Data.Bits import Data.List import Data.Word import qualified Codec.Compression.Zlib as Z import qualified Data.ByteString.Lazy as B be8 :: Word8 -> B.ByteString be8 x = B.singleton x be32 :: Word32 -> B.ByteString be32 x = B.pack [fromIntegral (x `shiftR` sh) | sh <- [24,16,8,0]] pack :: String -> B.ByteString pack xs = B.pack $ map (fromIntegral.fromEnum) xs unpack :: B.ByteString -> String unpack xs = map (toEnum.fromIntegral) (B.unpack xs) hdr, iHDR, iDAT, iEND :: B.ByteString hdr = pack "\137\80\78\71\13\10\26\10" iHDR = pack "IHDR" iDAT = pack "IDAT" iEND = pack "IEND" chunk :: B.ByteString -> B.ByteString -> [B.ByteString] chunk tag xs = [be32 (fromIntegral $ B.length xs), dat, be32 (crc dat)] where dat = B.append tag xs -- | Return a monochrome PNG file from a two dimensional bitmap -- stored in a list of lines represented as a list of booleans. png :: [[Bool]] -> String png dat = unpack $ B.concat $ hdr : concat [ihdr, imgdat, iend] where height = fromIntegral $ length dat width = fromIntegral $ length (head dat) ihdr = chunk iHDR (B.concat [ be32 width, be32 height, be8 1, be8 0, be8 0, be8 0, be8 0]) imgdat = chunk iDAT (Z.compress imgbits) imgbits = B.concat $ map scanline dat iend = chunk iEND B.empty scanline :: [Bool] -> B.ByteString scanline dat = 0 `B.cons` bitpack dat bitpack' :: [Bool] -> Word8 -> Word8 -> B.ByteString bitpack' [] n b = if b /= 0x80 then B.singleton n else B.empty bitpack' (x:xs) n b = if b == 1 then v `B.cons` bitpack' xs 0 0x80 else bitpack' xs v (b `shiftR` 1) where v = if x then n else n .|. b bitpack :: [Bool] -> B.ByteString bitpack xs = bitpack' xs 0 0x80 crc :: B.ByteString -> Word32 crc xs = updateCrc 0xffffffff xs `xor` 0xffffffff updateCrc :: Word32 -> B.ByteString -> Word32 updateCrc = B.foldl' crcStep crcStep :: Word32 -> Word8 -> Word32 crcStep crc ch = (crcTab ! n) `xor` (crc `shiftR` 8) where n = fromIntegral (crc `xor` fromIntegral ch) crcTab :: Array Word8 Word32 crcTab = array (0,255) $ zip [0..255] $ flip map [0..255] (\n -> foldl' (\c k -> if c .&. 1 == 1 then 0xedb88320 `xor` (c `shiftR` 1) else c `shiftR` 1) n [0..7])

1 0

Newbie Question on Setting the GHC Search Path
by Benjamin L. Russell 29 Oct '07

29 Oct '07

Please pardon this intrusion for an elementary question on setting the GHC search path. I have installed GHC on my work Windows XP machine, and would like to be able to search for files in the following directory: D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC However, when I type the following command into the GHC interpreter: :cd "D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC" I get the following error message: *** Exception: "D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC": setCurrentDirectory: invalid argument (Invalid argument) Yet, for testing purposes, when I type the following command: :cd cygwin I do not get any error message. There seems to be a problem with the spaces in the filename. However, I would like to be able to use the "D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC" directory for GHC programming practice, because I keep my practice work for my other programming languages in the same super-super-directory. Does anybody know a way to specify "D:\From C Drive\Documents and Settings\DekuDekuplex\Programming Practice\Haskell\GHC" as a directory in the search path for GHC? Benjamin L. Russell

3 4

Re: [Haskell] Image manipulation
by Tim Chevalier 29 Oct '07

29 Oct '07

[redirecting to haskell-cafe] On 10/29/07, Brent Yorgey <byorgey(a)gmail.com> wrote: > Haskell is a wonderful language, so I hate to say this...but personally I > don't see the benefit of using Haskell here, unless the manipulations you > want to do are very complex. Some simple shell (or > perl/python/ruby/whatever) scripts to glue together some calls to convert > (or possibly other ImageMagick utilities) ought to do the job just fine. > If you're doing many image transformations, invoking an external program like convert will get expensive due to context-switching. So that's why something like the (not-yet-existent) bindings for ImageMagick-as-a-library might be useful. I agree that laziness probably isn't going to be helpful, but there may be interesting things to be done that are enabled by purity and higher-order-functions. I'm working on the ImageMagick bindings because I'm curious to find out. There are obvious things like being able to define compositions of transformations -- which is easy to do when you're calling library functions in-memory, and less so if you're using a separate executable -- but maybe there are more interesting applications too. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt "Thus spake the Master Programmer: When you have learned to snatch the error code from the trap frame, it will be time for you to leave."--J. Geoffrey

2 2

Tim Sweeney and multi-cores .... and Haskell
by Galchin Vasili 29 Oct '07

29 Oct '07

http://www.americanscientist.org/content/AMSCI/AMSCI/ArticleAltFormat/20071…

3 3

placing modules in the module hierarchy
by Dimitry Golubovsky 29 Oct '07

29 Oct '07

Hi, Long ago (back in 2001), there was a message in the Haskell mailing list, archived e. g. here: http://www.mail-archive.com/haskell@haskell.org/msg08187.html and what it refers to is here: http://www.cs.york.ac.uk/fp/libraries/layout.html which goes for "Graphics.UI. etc" I used this approach in my script to cabalize Fudgets: everything was placed below "Graphics.UI.Fudgets" (original Fudgets library used plain module space). I am currently working on another stuff related to Haskell GUI for web browser, and us the same approach: everything goes under Graphics.UI.<library name> So, I think, despite this creates longer paths in the hierarchy, the more specialized the stuff is, the deeper in the hierarchy it should be pushed. Slightly off topic, this is IMHO the same problem that we have in Linux packages/filesystem layout: every package containing binaries, places them into say /usr/bin. Then, if the two packages have a binary with the same name, this leads to conflict (HSSFFIG has a program named "splitter". Another package in Debian also had a binary with the same name. they conflicted. To resolve it' I'd have to rename my binary to say hsffig-splitter. Should every package be installed into its own subtree, such conflicts wouldn't arise). So, to my personal opinion (which is in agreement with the proposal mentioned) each package has to have its own tree not crossing with other packages' tree. So, I'd suggest for the Grapefruit library: whatever is specific to this library, goes under Graphics.UI.Grapefruit. Whatever may be commonly used elsewhere (say some useful data structures) might go under "Data". So, if FRP signals are usable outside the Grapefruit, they might go to Control. Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

Re: [Haskell] placing modules in the module hierarchy
by Isaac Dupree 29 Oct '07

29 Oct '07

Wolfgang Jeltsch wrote: > Since the Control.Grapefruit subtree would probably only consist of > Control.Grapefruit.Signal and submodules, I’d prefer to just use > Control.Signal and Control.Signal.*. But this would pose the problem that no > other FRP library could use Control.Signal without conflicting with > Grapefruit. One _ideal_ is to develop a consensus in the community for a FRP Signal library, one that is good enough that Grapefruit could use it. (If the library is inherently Grapefruit-specific, do use Control.Signal.Grapefruit or Control.Grapefruit.Signal.) Of course that ideal is not always possible, and best-library consensuses do change over the years -- but we've been doing it a lot anyway. Isaac

1 0

newbie optimization question
by Prabhakar Ragde 29 Oct '07

29 Oct '07

For the purposes of learning, I am trying to optimize some variation of the following code for computing all perfect numbers less than 10000. divisors i = [j | j<-[1..i-1], i `mod` j == 0] main = print [i | i<-[1..10000], i == sum (divisors i)] I know this is mathematically stupid, but the point is to do a moderate nested-loops computation. On my 2.33GHz dual-core MacBookPro, the obvious C program takes about .3 seconds, and a compiled OCaML program (tail recursion, no lists) about .33 seconds. The above takes about 4 seconds. I've tried using foldl', and doing explicit tail recursion with strict accumulators, but I can't get the running time below 3 seconds. Is it possible to come within striking distance of the other languages? Thanks. --PR

16 39

Quasiquotations part of GHC?
by Joel Reymont 29 Oct '07

29 Oct '07

Folks, Did quasiquotations ever make it into the GHC tree? They were implemented as a patch to 6.7. Thanks, Joel -- http://wagerlabs.com

1 0