[Haskell-cafe] Re: When is waitForProcess not necessary?

[Dave Bayer]

Bryan O'Sullivan bos at 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

[Haskell-cafe] Re: When is waitForProcess not necessary?

[Dave Bayer]

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