December 2006 - Libraries

Re: Control.Monad.Error documentation
by Andriy Palamarchuk 19 Dec '06

19 Dec '06

Neil, thank you for the response. ----- Original Message ---- From: Neil Mitchell <ndmitchell(a)gmail.com> > I just got this email message, in fact just _after_ the one saying the > deadline had expired. I guess you need to reset the deadline, and > there is probably a sensible reason no one replied in 2 weeks :) Sorry for the confusion - these are submissions for different modules. Guess the confusion was caused because they are in the same package and have tracker numbers, which differ only by 1 digit The first email was about Control.Monad.Identity documentation, tracker id 1039. I submitted this one 2 weeks ago. The second email is for Control.Monad.Error, tracker id 1059. Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Control.Monad.Identity documentation
by Andriy Palamarchuk 19 Dec '06

19 Dec '06

The deadline of the documentation proposal is up. There were no comments, so I assume everything is Ok. Can somebody commit the change? The patch is attached to the proposal: http://hackage.haskell.org/trac/ghc/ticket/1039 Thanks, Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

Control.Monad.Error documentation
by Andriy Palamarchuk 19 Dec '06

19 Dec '06

Documentation for the Error monad. Please take a minute to review it. This is one those parts of the library newbies have difficulties to understand. Hopefully good documentation will help them. Converted the module documentation to Haddock format. Per Jeff Newbern's gracious permission included relevant information, an example from his cool tutorial "All About Monads" http://www.nomaware.com/monads/. Added an example for ErrorT. Use String instead of [Char]. The source of the updated Error module and haddock output for it are attached to the proposal tracker entry: http://hackage.haskell.org/trac/ghc/ticket/1059 Deadline for the proposal - 2 weeks. A few questions: 1) What "| m -> e" part means in a declaration: class (Monad m) => MonadError e m | m -> e where throwError :: e -> m a catchError :: m a -> (e -> m a) -> m a 2) Can somebody explain what mapErrorT function is used for? Here is its definition and implementation: mapErrorT :: (m (Either e a) -> n (Either e' b)) -> ErrorT e m a -> ErrorT e' n b mapErrorT f m = ErrorT $ f (runErrorT m) 3) I noticed that some examples of a combined ErrorT IO monad use 'lift' function to lift IO operations into IO monad, others use 'liftIO'. As I understand 'liftIO' can lift operation through a few monad layers to an IO monad in a monad stack while 'lift' lifts operation to the next monad. If my understanding is correct then 'liftIO' seems a better choice for the example, because the monad stack can be extended later without breaking calls to the IO operations. 4) Is it Ok to say "Haddock for X" instead of "Haddock documentation for X" like in Java people say "Javadoc for X"? It is funnier if one remembers that haddock is a fish :-) Corrections, suggestions, comments, better examples? Thanks, Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Data.List documentation improvements
by Andriy Palamarchuk 18 Dec '06

18 Dec '06

I submitted a proposal ticket for this patch: http://hackage.haskell.org/trac/ghc/ticket/1034 The deadline is Wednesday, December 6th. Andriy ----- Original Message ---- From: Andriy Palamarchuk <apa3a(a)yahoo.com> To: libraries(a)haskell.org Sent: Friday, December 1, 2006 9:53:08 PM Subject: Data.List documentation improvements Goal of my changes it to make list functions more accessible to Haskell newcomers. "Extracting sublists" section seems to have less complete documentation than rest of the module. Added examples for all the functions. Added easier to understand summaries for composite functions. Comments, suggestions, better descriptions? Is it Ok to send the darcs patches as is or it is better to send only diffs without context? I'd like to keep patch in plain text, not compressed. Thanks, Andriy ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com

6 11

Higher level interface to System.Process
by dons＠cse.unsw.edu.au 18 Dec '06

18 Dec '06

wferi: > on my computer your code (with >> return ()-s inserted) works with at > most 135168=132*1024 bytes of input: > > One more byte, and cat blocks on writing to its pipe. No wonder, > nobody reads the other end, as our hPutStr to cat also blocks, as a > direct consequence. Moving the case beyond the forkIO-s resolves > this. Btw, why don't you close the other handles? Btw2 runCommand in > http://happs.org/HAppS/src/HAppS/Util/Common.hs takes a similar > approach with MVar-s; I wonder if they are really needed. Ok, I really want to push forwards the effort to add a nice popen to base. Here's my first effort at a minimal clean interface, that we might be proud to demonstrate in a tutorial ;) import System.Process.Run main = do edate <- readProcess "date" ["+%y-%m-%d"] [] case edate of Left err -> print err Right date -> putStr date The code for readProcess is in darcs, here: darcs get http://www.cse.unsw.edu.au/~dons/code/newpopen I'd like some comments on this approach. Suggestions on where to generalise this, and yet keep it clean and simple, and so on. Thanks, Don The module itself is attached: ----------------------------------------------------------------------------- -- | -- Module : System.Process.Run -- Copyright : (c) Don Stewart 2006 -- License : BSD-style (see the file libraries/base/LICENSE) -- -- Maintainer : dons(a)cse.unsw.edu.au -- Stability : experimental -- Portability : currently non-portable (Control.Concurrent) -- -- Convenient interface to external processes -- module System.Process.Run ( -- * Running processes readProcess ) where import System.Process import System.Exit import System.IO import Control.Monad import Control.Concurrent import qualified Control.Exception as C -- -- | readProcess forks an external process, reads its standard output, -- waits for the process to terminate, and returns either the output -- string, or an exitcode. -- readProcess :: FilePath -- ^ command to run -> [String] -- ^ any arguments -> String -- ^ standard input -> IO (Either ExitCode String) -- ^ either the stdout, or an exitcode readProcess cmd args input = C.handle (return . handler) $ do (inh,outh,errh,pid) <- runInteractiveProcess cmd args Nothing Nothing -- fork off a thread to start consuming the output output <- hGetContents outh outMVar <- newEmptyMVar forkIO $ C.evaluate (length output) >> putMVar outMVar () -- now write and flush any input when (not (null input)) $ hPutStr inh input hClose inh -- done with stdin hClose errh -- ignore stderr -- wait on the output takeMVar outMVar hClose outh -- wait on the process ex <- C.catch (waitForProcess pid) (\_ -> return ExitSuccess) return $ case ex of ExitSuccess -> Right output ExitFailure _ -> Left ex where handler (C.ExitException e) = Left e handler e = Left (ExitFailure 1)

2 1

Data.Generics and Abstract Data Types
by Samuel Bronson 17 Dec '06

17 Dec '06

Today, I was playing with Stefan O'Rear's genericserialize package when I noticed that Data.Map doesn't play well with Data.Generics. Specifically, here is its instance for Data: -- This instance preserves data abstraction at the cost of inefficiency. -- We omit reflection services for the sake of data abstraction. instance (Data k, Data a, Ord k) => Data (Map k a) where gfoldl f z map = z fromList `f` (toList map) toConstr _ = error "toConstr" gunfold _ _ = error "gunfold" dataTypeOf _ = mkNorepType "Data.Map.Map" dataCast2 f = gcast2 f The gfoldl and dataCast2 methods are okay, but I'm not sure about all the others. Now, I can understand why whoever wrote Data.Map doesn't want to expose the internals, but couldn't we at least have a nice way to deconstruct one and a nice way to build one,without having to write hard-coded Map code? I particularly don't like the fact that toConstr doesn't work on it. Multiply this times four to account for the fact that Data.Set, Data.IntMap, and Data.IntSet have the same problem. I also noticed that Data.ByteString.Word8 has a rather silly instance (it exposes the innards instead of doing something usefull), and that Data.Array has the same problem as Data.Map -- presumably the other IArray instances do too. I think the best way might be to add a few constructors to the DataRep and ConstrRep types, which I reproduce here: data DataRep = AlgRep [Constr] | IntRep | FloatRep | StringRep | NoRep data ConstrRep = AlgConstr ConIndex | IntConstr Integer | FloatConstr Double | StringConstr String (I must also marvel at how strangely named the StringRep/StringConstr constructors are -- they seem to be used exclusively for the Char type.) Please discuss! Oh, and by the way, I'd like my nuclear power plant painted red, thank you ;-).

1 0

fixing Foreign
by John Meacham 16 Dec '06

16 Dec '06

I was thinking that we should consider fixing some issues with the current Foreign library before haskell' when it comes to support for 64-bit (and non 32-bit in general) architectures. the specific changes I am thinking of are mandate IntPtr,WordPtr,IntMax,and WordMax as defined by the C99 types intptr_t, uintptr_t, intmax_t, and uintmax_t. (these are all supported by jhc and ghc right now) change the following type signatures bitSize :: Bits a => a -> Maybe Int (to handle Integer and similar types properly) plusPtr :: Ptr a -> IntPtr -> Ptr a minusPtr :: Ptr a -> Ptr b -> IntPtr add the following ptrToIntPtr :: Ptr a -> IntPtr intPtrToPtr :: IntPtr -> Ptr a ptrToWordPtr :: Ptr a -> WordPtr wordPtrToPtr :: WordPtr -> Ptr a Also, we should make sure whatever new IO interface for files we come up with is 64 bit safe when it comes to offsets inside of files. Int64,IntMax, or some new Offset type are all candidates. John -- John Meacham - ⑆repetae.net⑆john⑈

2 2

darcs patch: HsTime.h should be installed
by mukai＠jmuk.org 16 Dec '06

16 Dec '06

ghc encounters a compile error with flags `-package time' and `-O' because header files such as HsTime.h is not installed. Although these header files are described to be installed in .cabal file, ghc uses another mechanism to determine what files are installed. The following patch enables ghc to install header files. Thu Dec 14 00:13:46 JST 2006 mukai(a)jmuk.org * HsTime.h should be installed

1 0

problem with Graphics.HGL
by asilovy 15 Dec '06

15 Dec '06

Hello, I'm trying some stuffs with the Graphics.HGL library and have a question. I wonder if someone could help me with it. I'm trying to write some Win32 application using openWindowEx. I see it has a parameter to (eventually) define a timer. On the other hand, the maybeGetWindowEvent function is used to get "notified" of different events such as mouse button pressed, key pressed, resizing... I don't understand the special status of the timer. Why is it not an event like the others. It does'nt sound right to me. As I understand it, you have to wait for a timer tick rather than being informed by a timer event. For instance, I've written a small test program that uses the timer to draw some random "stars" on a window. Eventually, when the user presses the mouse button, the window is closed. But, as you can try, if you trigger a lot of events (by, for instance, moving the mouse a lot) BEFORE pressing the mouse button those events, although I don't treat them, will have to be processed with the delays of the timer before the mouse clic can be treated. And so, the window takes a long time to close. I'm I misunderstanding something ? And is there another way to treat the timer ? Thanks for your answer Alain {--------------------------------------------------------------------------------------- Draws randomly colored stars at random places Uses Events from : http://haskell.org/ghc/docs/latest/html/libraries/HGL/Graphics-HGL-Window.h… -} import Graphics.HGL import Hugs.Prelude import System.Random import Graphics.HGL.Win32.Types import Control.Monad import Data.Maybe main = runGraphics myWin myWin = do w <- openWindowEx "TestWindow" Nothing (400,400) DoubleBuffered (Just 100) let loop n = do x0 <- randomRIO (0, 39) y0 <- randomRIO (0, 39) couleur <- randomRIO (0, 0x00FFFFFF) let (x, y) = (x0 * 10, y0 * 10) c = if mod couleur 10 == 0 then couleur else 0 -- 1/10 will be colored drawInWindow w $ withRGB (toRGB (fromInt c)) $ ellipse (x, y) (x + 9, y + 9) e <- maybeGetWindowEvent w -- some Event ? when (isJust e) $ -- yes... case fromJust e of -- which ? Button _ _ _ -> closeWindow w -- mouse button _ -> return () -- something else -> nothing to do getWindowTick w -- wait and... loop (n + 1) -- loop loop 0 -------------------------------------------------------------------------------------- -- View this message in context: http://www.nabble.com/problem-with-Graphics.HGL-tf2829855.html#a7900522 Sent from the Haskell - Libraries mailing list archive at Nabble.com.

1 0

Re: a cabal/database lib experience
by Simon Marlow 15 Dec '06

15 Dec '06

Paul Moore wrote: > On 12/12/06, Ketil Malde <Ketil.Malde(a)bccs.uib.no> wrote: > >> I'm possibly using cabal in a simplistic way, but I generally do either >> >> ./Setup.lhs configure -p >> ./Setup.lhs build >> ./Setup.lhs install > > [...] > >> This is a lot of typing, and at least once I wrote a Makefile to >> automate it (oh, the irony of it!) >> Anyway, it would be nice if a 'cabal' command automated the whole >> sequence in one go, at least as an option. > > > I come from a Python background, and Python's distutils (which feels > very like cabal - or should that be the other way round?) tends to > have later commands include earlier ones. So, > > setup.py install > > automatically does "build" (there is no explicit configure step). Sounds entirely reasonable to me. Though configure takes a bunch of arguments; so if configure is run automatically it'll always be with the default settings. Maybe that's ok. Simon

3 4