- Libraries - Haskell.org

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

a cabal/database lib experience (was: [Haskell-cafe] Trivial database access in Haskell)
by Claus Reinke 14 Dec '06

14 Dec '06

>> if you're using Haskell at all, you *are* the Haskell community. > [..lots of "I searched, I found, I tried, I got this error, I thought, > I tried this workaround, I got to this point, now I'm stuck here..] I just wanted to comment that I find this kind of "experience report" very helpful, especially if someone does not give up at the first hurdle, and goes through the trouble of writing up all the frustrating steps and thoughts rather than summarizing ("it didn't work"/"I got it to work after some fiddling") - thanks! The problem with mindsets is that minds get set in them, and not only do people outside find it very difficult to "get in", but the people inside find it very difficult to understand what it is like "outside". While you are looking for documentation of the supposedly easy first steps to get you started on your more detailed investigation, so you have just provided the rest of the community with some documentation of what its works currently look like. That situation seems to be slightly embarrassing (if only because we are tempted to think that we have no time for the traditional README and INSTALL files - after all, all darcs/cabal stuff is self-explanatory, isn't it, and has been discussed to death somewhere, hasn't it, and the library does the obvious thing, doesn't it, and isn't quite ready for prime time yet anyway, at which time it is going to be carved in stone and documented thoroughly by a team of Pulitzer-price-winning authors?-) Seriously, and as Simon PJ has been fond of reminding us: the user is always right, so I very much hope that those of us involved with the projects mentioned in your report will take note and do something about it (for easy reference I repeat it at the end of this message;-). Some suggestions, gleaned from your experience (perhaps you could comment on whether they'd have been of any use?): cabal: - the separation into interpreter/compiler and resource as Setup does not set up the right mindset in users. for instance, you can "runhaskell Setup.hs --help" as for most unixy tools, but who'd think of that in this situation, and how much does it help? + add a dedicated command "cabal", which does nothing more than "runhaskell Setup", but is more memorable and suggestive + when anything goes wrong, also mention "cabal --help" in the error message + in "cabal --help", explicitly and prominently mention the typical usage cycle (configure/build/install); also point to cabal home page, with more documentation, bug reports, newest version and known problem info, downloads, .. - the three step separation into configure/build/install is traditional and has good justifications, but is unhelpful for the most typical use case (I need a library for a part of my work, it isn't installed by default, it doesn't have an installer, so I have to do this cabal thing to get on with my work). if someone types "cabal install" as the first command, cabal might engage in a simple dialogue: "would you like to configure then build then install <program/library name> with default options [yes/no]?" y <cabal configure output> "please check configuration defaults [ok, continue/no, change]" n "thank you - no files were built or installed. please run 'cabal --help' and 'cabal configure --help' for details on how to change the configuration defaults" - cabal/darcs/haddock are no replacement for minimal help texts: cabal should require the existence of a README (darcs should complain if there is a *.cabal, but no README..). that might be too specific a request for darcs, but perhaps the useful, but increasingly lengthy resource http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program might start with a motivational section 0 on "the intended user experience" ?-) the database libraries: - the cabal/README points above seem to apply, according to the experience report below, so getting started is more difficult than it needs to be - comparative evaluation/individual feature sets appear to be difficult, according to earlier email - sample code for "trivial queries" (aka, I know about databases, but I need to see the way this particular library handles things, so that I can figure out whether it is the right one for me) is not obvious to find - distributions are bare-boned: > - following the HDBC link on the Haskell Wiki leads to a huge list of > tar.gz files, with no indication of which one I might want :-( > > Option 2, Takusen, leads to a file listing, but no downloadable package. > > Option 3, HSQL, leads to a page which doesn't mention Oracle support > (even though the Wiki page does) so I'm put off trying further... - installing database libraries is not the main activity, it just gets in the way of running SQL queries from Haskell, and may well be the first experience with getting/building/installing 3rd party libs for Haskell - other languages and their bindings are tempting if potential users get stuck I hope this summary/rephrasing of Paul's report is helpful. what do users and implementors think (cc-ed to libraries list)? Claus > OK, thanks for the gentle push. After a bit of digging, I decided that > the takusen link looked like a darcs repository, and I downloaded > darcs and got takusen. I installed GHC 6.6 in a spare VM (no PC round > I can install stuff on just now, I'll do this properly later). On the > assumption that the takusen.cabal file means I should look at Cabal, I > had a dig and found the incantation "runhaskell setup.hs". > > I got the error: > > F:\takusen>runhaskell setup.hs > > setup.hs:11:7: > Could not find module `Distribution.Compat.FilePath': > it is hidden (in package Cabal-1.1.6) > > I assume this relates to the note in setup.hs "For ghc-6.6 you will > need to first install Cabal-1.1.6.1", but as I got GHC from a Windows > binary install, I'm not sure where to go from here. I found the Cabal > webpage and downloaded 1.1.6.1. Trying to install it, I got the > following: > > F:\cabal-1.1.6.1>runhaskell Setup.lhs install > Setup.lhs: error reading ./.setup-config; run "setup configure" command? > > > F:\cabal-1.1.6.1>runhaskell Setup.lhs configure > Configuring Cabal-1.1.6.1... > configure: Dependency base-any: using base-2.0 > configure: Using install prefix: C:\Program Files > configure: Binaries installed in: C:\Program Files\Haskell\bin > configure: Libraries installed in: C:\Program > Files\Haskell\Cabal-1.1.6.1\ghc-6.6 > configure: Private binaries installed in: C:\Program Files\Cabal-1.1.6.1 > configure: Data files installed in: C:\Program Files\Common Files\Cabal-1.1.6.1 > configure: Using compiler: c:\ghc\ghc-6.6\bin\ghc.exe > configure: Compiler flavor: GHC > configure: Compiler version: 6.6 > configure: Using package tool: c:\ghc\ghc-6.6\bin\ghc-pkg.exe > configure: Using ar found on system at: c:\ghc\ghc-6.6\bin\ar.exe > configure: No haddock found > configure: No pfesetup found > configure: No ranlib found > configure: Using runghc found on system at: c:\ghc\ghc-6.6\bin\runghc.exe > configure: No runhugs found > configure: No happy found > configure: No alex found > configure: Using hsc2hs: c:\ghc\ghc-6.6\bin\hsc2hs.exe > configure: No c2hs found > configure: No cpphs found > configure: No greencard found > > F:\cabal-1.1.6.1>runhaskell Setup.lhs install > Installing: C:\Program Files\Haskell\Cabal-1.1.6.1\ghc-6.6 & > C:\Program Files\Haskell\bin Cabal-1.1.6.1... > Setup.lhs: Error: Could not find module: Distribution.Compiler with any suffix: > ["hi"] > > OK, that's as far as I can go. Remember, what I *want* to do is to run > some SQL against my database to get some data into a Haskell program. > I'm not up to debugging a Cabal install. (At this point, if I was > doing this for "real work", I'd be off to the Python website like a > shot...) > > Can anyone help? I promise, I will document what I end up with! > > Paul. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

6 8

Re[2]: [Haskell-cafe] Re: a cabal/database lib experience
by Bulat Ziganshin 13 Dec '06

13 Dec '06

Hello Paul, Tuesday, December 12, 2006, 4:48:55 PM, you wrote: >> ./Setup.lhs configure -p >> ./Setup.lhs build >> ./Setup.lhs install > 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, i suggest you to write simple script that automates this. i've attached makefile which i include with all my libs that does this - you need to run only "make install". i propose to all library developers to include such makefile with their libs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Request for improvements
by Chris Kuklewicz 13 Dec '06

13 Dec '06

I have written a thin but useful layer on top of parts of Control.Concurrent and Control.Exception to aid in forking new threads. I think I have written it correctly and understand the guarantees (when running under GHC 6.4 or 6.6). It is useful when * you need to be able to check whether a thread has finished running * you need to be able to wait until a thread has finished running * when you want to run within the scope of 'block' * you need to run in another thread with ** an exception handler (catch) ** a finally clause ** bracket commands But it may need improving, especially if I have missed a subtle blocking or race condition. And suggestions on improved names are welcome. The code is on the wiki at http://haskell.org/haskellwiki/WrapConc -- Chris

1 0

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

12 Dec '06

It's not yet checked in. Any takers? Andriy ----- Original Message ---- From: Andriy Palamarchuk <apa3a(a)yahoo.com> To: libraries(a)haskell.org Sent: Wednesday, December 6, 2006 9:17:31 PM Subject: Re: Data.List documentation improvements The deadline for this update is up. Can somebody commit the changes for me? Here is the ticket with the patch: http://hackage.haskell.org/trac/ghc/ticket/1034 Andriy ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

2 1