Re: [Haskell-cafe] Screen scraping with an interactive process: Buffering problems?
On Nov 7, 2007 4:44 PM, David Benbennick [EMAIL PROTECTED] wrote: And once you do hGetContents, you have read all the data that will ever exist on that handle, so there's nothing to read from it later on. I completely misunderstood how hGetContents works. This now makes sense. I first thought hGetContents would return everything you could read from the stream right now as a string. From reading the the haddock documentation for System.IO.hGetContents, I failed to understand that the string it returns will contain characters that haven't even been written to the (interactive) stream by the time of the call to hGetContents. I'm not sure if the hGetContents documentation could easily be made to make that fact more salient, but I'd be willing to submit a patch, if other people have been confused. Assuming that each call to ACL2 produces exactly one of either Proof succeeded or attempt has failed, you can get a list of results like this (where aclOutput :: String is the result of hGetContents): let results = map (\l - if l == Proof succeeded then True else False) $ filter (\l - elem l [Proof succeeded, attempt has failed]) $ lines aclOutput Then results :: [Bool], and results !! n is True if the nth call succeeded. Just make sure not to inspect results !! n until after making the nth call to ACL2, or it will block. I used a minor modification of this approach (Proof succeeded is not on a line by itself), and it worked famously. Thanks for the help, David! -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Screen scraping with an interactive process: Buffering problems?
On Nov 6, 2007 10:15 PM, David Benbennick [EMAIL PROTECTED] wrote: What about using hGetContents to just read ALL of the input, as a lazy string? Then you look through that string for success or failure. In other words, readACL2Answer pout = do s - hGetContents pout parse s here Ironically, this was my first problem. First of all, I don't think I want the semi-closed state -- I want to be able to read and write freely later on (I may be misunderstanding semi-closed, however). Second, when I used this approach, after the hGetContents call I did the regexp matching, and the program hung during matching. -- Denis ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Screen scraping with an interactive process: Buffering problems?
On Nov 7, 2007 5:12 AM, Denis Bueno [EMAIL PROTECTED] wrote: Ironically, this was my first problem. First of all, I don't think I want the semi-closed state -- I want to be able to read and write freely later on (I may be misunderstanding semi-closed, however). I don't think that makes sense. First of all, pout is only the stdout of the program, so you can only read from it, not write to it. And once you do hGetContents, you have read all the data that will ever exist on that handle, so there's nothing to read from it later on. Second, when I used this approach, after the hGetContents call I did the regexp matching, and the program hung during matching. That's not surprising. You first match for Proof succeeded. So if the proof failed, the matcher will go past the attempt has failed message, looking for a later succeeded. Which means it will block waiting for more output from your subprocess, which will never produce more output until you give it another request. Assuming that each call to ACL2 produces exactly one of either Proof succeeded or attempt has failed, you can get a list of results like this (where aclOutput :: String is the result of hGetContents): let results = map (\l - if l == Proof succeeded then True else False) $ filter (\l - elem l [Proof succeeded, attempt has failed]) $ lines aclOutput Then results :: [Bool], and results !! n is True if the nth call succeeded. Just make sure not to inspect results !! n until after making the nth call to ACL2, or it will block. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Screen scraping with an interactive process: Buffering problems?
What about using hGetContents to just read ALL of the input, as a lazy string? Then you look through that string for success or failure. In other words, readACL2Answer pout = do s - hGetContents pout parse s here ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
