On Thursday, April 5, 2012 at 1:53 AM, Sutherland, Julian wrote: > Hey Guys, > > I'm Julian, I am reaching the end of my second year as a JMC (Joint > Mathematics and Computer science) Student at Imperial College London > and I'd like to apply to GSOC for a project involving Haskell and I just > wanted to run my idea past the community.
[snip] > I found an example of such a bug, which I will test further before reporting > it. > It seems to be the opposite of the following bug: > http://hackage.haskell.org/trac/ghc/ticket/5594 > > i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a > program whose main is written in Haskell. > > For example, when running the code: > > main.hs: > module Main where > > import Foreign.C.Types > import System.IO > > foreign import ccall "inc" c_inc :: CInt -> CInt > > main :: IO () > main = do > putStr "Enter n: " > -- hFlush stdout > s <-getLine > putStrLn . show . c_inc . read $ s > > inc.c: > > int inc(int i) __attribute__ ((const)); > > int inc(int i) > { > return i + 1; > } > > Built with > Makefile: > all: > gcc -c -o inc.o inc.c > ghc --make -main-is Main main.hs inc.o -o test > rm *.hi *.o > > The output comes out as: > [julek@cryptid inc]$ ./test > 2 > Enter n: 3 > > But when the " hFlush stdout" line is commented back in, the output is: > [julek@cryptid inc]$ ./test > Enter n: 2 > 3 > > which is correct, but the extra line shouldn't be necessary. > > I am currently using ghc 7.4.1 which is the newest version, so this is a > current bug. I think this is a consequence of line buffering rather than a bug. If you write your own increment function in Haskell, you get the same behavior. If you `hSetBuffering stdout NoBuffering` before your `putStr` call, you should get the behavior you wanted. I've seen similar issues with programs written in many languages; it's just one of those gotchas to be aware of when dealing with console UI. As to the rest of your proposal, when you started out talking about calling Haskell from C or C++, I hoped you would focus on the pain of linking the final executable. This seems to me a more fundamental -- and addressable -- stumbling block than the richness of interaction with C++. As things stand, it is quite a hassle to use a Haskell library of any complexity called from C. Improved interaction with C++ could indeed be valuable, but, unless something has changed recently, work is still needed to improve the more basic C -> Haskell FFI story. Anthony _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe