[Haskell-cafe] Re: When is waitForProcess not necessary?
So I stared at the documentation in Control-Concurrent, learned about finally and MVar variables, and crossed the genes from the suggestions here to come up with runCommand :: String -> String -> IO (String,Bool) runCommand cmd input = do (inp,out,err,pid) <- runInteractiveCommand cmd let get h = do mvar <- newEmptyMVar let put xs = seq (length xs) (putMVar mvar xs) forkIO $ finally (hGetContents h >>= put) (put []) takeMVar mvar if null input then return () else hPutStr inp input output <- get out errmsg <- get err exit <- waitForProcess pid case exit of ExitSuccess -> return (output,True) ExitFailure _ -> do hPutStrLn stderr errmsg return (errmsg,False) which seems to work well; I haven't beat on it. I like the return type for my needs, e.g. I can write (out,ok) <- runCommand mark doc if ok then write out src else hPutStr stderr out So why don't the MVar examples in this thread bracket somehow, e.g. with finally as Control-Concurrent suggests: Note that we use finally from the Control.Exception module to make sure that the MVar is written to even if the thread dies or is killed for some reason. It seems to me that this could happen, with waitForProcess doing fine, yet the MVar never getting written. (I haven't written a test example to exercise this.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: When is waitForProcess not necessary?
On Fri, 2007-08-03 at 14:51 +, Dave Bayer wrote: > The Hackage/Cabal universe takes the perspective that one is a committed > Haskell user, and one wants the same diversity of tools enjoyed, say, in > the Perl universe. When one uses Haskell to write a tool whose use is > standalone and not Haskell-specific, there's a very good chance that > someone will come along and try to build it for a new platform, installing > and using GHC for the first time in order to do so. The barrier to entry is > easily doubled if one has to also figure out how to obtain libraries that > do not come automatically with GHC. Plenty of us have the moxie to install > a package like GHC for a single use, because we've heard that "hackers" can > do such things easily, but we don't really want to join each treehouse. The plan/goal is for ghc and hopefully other implementations to come with cabal-install so that when you try and build your random cabal package it'll be able to download, build and install all the deps (without necessarily requiring root). So in the end you should not have to figure out all the deps yourself, it's just that at the moment we're kind of in an intermediate phase. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: When is waitForProcess not necessary?
Bryan O'Sullivan serpentine.com> writes: > Pardon me while I veer off-topic, but you could also use Pandoc to do > this. No forking required. > http://sophos.berkeley.edu/macfarlane/pandoc/ What I'm doing is neither Haskell nor Markdown specific; I allow any HTML markup filter that plays nice with the direct HTML I also write (a restriction I could easily drop), and I cooperate with language-specific library doc generators such as Haddock. For all the fuss one reads about Haskell-not-as-fast-as-C, it's amusing how sluggish Markdown.pl is. Someone should write a small BSD'd Haskell version as example code for programming in Haskell. I may, although I can't see myself writing anything called "SmartyPants". I admire pandoc and I allow its use as an alternative to Markdown.pl, as an external command. I don't want to link it into my code because * It is GPL'd and I'm writing BSD'd code * It is a library that does not come with GHC. * It is twice the length of my code so far. The Hackage/Cabal universe takes the perspective that one is a committed Haskell user, and one wants the same diversity of tools enjoyed, say, in the Perl universe. When one uses Haskell to write a tool whose use is standalone and not Haskell-specific, there's a very good chance that someone will come along and try to build it for a new platform, installing and using GHC for the first time in order to do so. The barrier to entry is easily doubled if one has to also figure out how to obtain libraries that do not come automatically with GHC. Plenty of us have the moxie to install a package like GHC for a single use, because we've heard that "hackers" can do such things easily, but we don't really want to join each treehouse. I've installed versions of, say, Perl, Python, Ruby, even if there was a possibly lame installation already present. Still, their package systems generally left me fuming. I know my audience; we mathematicians can be smart and incredibly stupid at the same time. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe