- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Strictness leak
by Jeff Polakow 31 Oct '07

31 Oct '07

I forgot to send this reponse to haskell-cafe earlier... Hello, > You mean for the IO monad, right? > Sorry. I meant divergence is unavoidable for any strict Monad, such as IO. However, sequence will always compute over the entire list; if the resulting computation itself is lazy then the result can be inspected lazily. > take 10 $ execWriter $ sequence $ repeat $ tell ([3]::[Int]) > This is a good example. Note that the computation of sequence itself is infinite. snd $ runWriter $ sequence (repeat $ tell [3]) >>= return . take 10 will result in an infinite list, but fst $ runWriter $ sequence (repeat $ tell [3]) >>= return . take 10 will return a 10 element list. -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Re: [Haskell] Image manipulation
by Dan Piponi 30 Oct '07

30 Oct '07

Jerzy, There is a simple framework for performing filtering operations on images lazily: http://sigfpe.blogspot.com/2006/12/evaluating-cellular-automata-is.html (Scroll down to the 2D example in the comments.) 2D digital filters lend themselves nicely to a comonadic framework though you probably have to drop the comonads for operations other than convolution type things. And you're right, doing this lazily at the pixel level is expensive. However, if we replace pixels with 256x256 blocks, say, where the blocks themselves are strict but the images are lazily made up of blocks, then we have the potential for a nice and efficient image processing library that inherits its laziness directly from Haskell. On 10/30/07, jerzy.karczmarczuk(a)info.unicaen.fr <jerzy.karczmarczuk(a)info.unicaen.fr> wrote: > Dan Piponi adds to a short exchange: > > > jerzy.karczmarczuk: > >> [iso-8859-1] Bj�rn Wikstr�m writes: > >> > >> > Hi! I have lots and lots of images (jpegs) that I would like to manipulate > >> > and shrink (in size). They are around 5 Mb big, so I thought this would > >> > be a good Haskell project since it's a lazy evaluating language. > >> ... > >> I must say that I don't see much use of laziness here. > > > Laziness plays a big role in real world image processing. Typically, > > in applications like Apple's Shake, you build a dataflow > > representation of the image processing operations you wish to perform, > > and the final result is computed lazily so as to reduce the amount of > > computation. For example, if you blur an image, and then zoom in on > > the top left corner, then only the top left corner will be loaded up > > from the original image (assuming your image file format supports > > tiled access). You still work on tiles or scan-lines, rather than > > individual pixels, so the laziness has a 'coarse' granularity. > > > > But I'm not sure if this is what the original poster was talking about. > > I am neither... > Still, Dan, I think that there is quite a difference between incremental > processing of signals, and images, etc., and the *lazy evaluation* of > them. Of course, a stream is consumed as economically as it can, but > not less. If you filter an image (shrinking, so some low-pass MUST be > done), a pixel must be loaded with its neighbourhood, which means *some* > scan lines. > With a JPEG this means that a 8x8 block should be loaded also with its > vicinity. But would you suggest that individual pixel processors should > be lazy? It would be useless, and probably resulting in some penalties. > > So, the laziness of Haskell for me here is less than useful. > Noooow, the lazy *generation* of streams is another story... > Generating music (low level, i.e. sound patterns) through lazy algorithms > is quite interesting. > > Jerzy Karczmarczuk > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

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 30 Oct '07

30 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 30 Oct '07

30 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 30 Oct '07

30 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