# Custom Query (7485 matches)

## Results (22 - 24 of 7485)

Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|

#1419 | fixed | "GHC as a library" stalls when nobody is consuming it's output | simonmar | simonmar |

Description |
Reported by Mads Lindstrøm <mads_lindstroem@…> on glasgow-haskell-users: While trying to implement a GUI for GHCi, I have run into an annoying concurrency problems. I think "GHC as a library" is at fault, as it stalls (maybe some deadlock) when nobody is consuming it's output. This message is a literate Haskell program, which illustrates the problem. This test-program starts a thread which prints an 'A' on stderr every second. Then it wait three seconds (meanwhile the 'A's are printing), and runs, via "GHC as a library", the following Haskell code "[1..]". If I start the program as: ./IsGhcBlocking >/dev/null everything works fine and the 'A' keeps coming out on stderr. However, if I do: ./IsGhcBlocking | sleep 10 I only see three 'A's. I believe that is because the sleep-command, do not consume any input. The program was tested on Debian Etch running GHC 6.6. > module Main where > Compile with: ghc -threaded -package ghc-6.6 --make IsGhcBlocking.lhs > import qualified GHC as GHC > import qualified Outputable as GHC > import qualified Packages as GHC > import qualified DynFlags as GHC > import qualified ErrUtils as GHC > > import System.IO > import Control.Concurrent > -- the path of our GHC 6.6 installation > path :: FilePath > -- path = "c:\\ghc-6.6" > path = "/usr/lib/ghc-6.6/" > > main :: IO() > main = do let printAs = do threadDelay (10^6) > hPutStrLn stderr "A" > printAs > forkOS printAs -- forkIO gives the same result > threadDelay (10^6 * 3) > session <- initializeSession > GHC.runStmt session "[1..]" > return () > > initializeSession = > do session <- GHC.newSession GHC.Interactive (Just path) > > -- initialize the default packages > dflags0 <- GHC.getSessionDynFlags session > let myLogAction _ locSpec style errMsg = hPutStrLn stderr showMsg where > showMsg = GHC.showSDoc $ GHC.withPprStyle style $ GHC.mkLocMessage locSpec errMsg > dflags1 = dflags0 { GHC.log_action = myLogAction } > (dflags2, packageIds) <- GHC.initPackages dflags1 > GHC.setSessionDynFlags session dflags2{GHC.hscTarget=GHC.HscInterpreted} > GHC.setContext session [] [] > return session The stalling becomes a problem, when one wants to interrupt "GHC as a library"'s runStmt function. One could interrupt "GHC as a library" with Panic.interruptTargetThread (see http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/12289). However, as "GHC as a library" locks up (stalls, deadlocks) there is no way of executing Panic.interruptTargetThread. Some people may suggest that I should always consume the output from "GHC as a library". But that is easier said than done. Many GUI libraries (including WxHaskell, which I am using) only allows for one active thread at a time (see http://wxhaskell.sourceforge.net/faq.html). Thus my GUI cannot simultaneously tell "GHC as a library" to interrupt it's execution and read it's output. For thus wondering how I can run both a GUI and "GHC as a library", if WxHaskell is not happy about threading, the answer is that I run the GUI and "GHC as a library" in separate processes. |
|||

#9558 | invalid | "Illegal equational constraint" that might not be the users fault | rrnewton | |

Description |
If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? |
|||

#9559 | duplicate | "Illegal equational constraint" that might not be the users fault | rrnewton | |

Description |
If you try the latest cabal head and GHC together as of 2014.09.04, and then you try to install statistics, you'll see an error like the following, which does not occur in GHC 7.8.3: cabal-1.21 install -w ghc-7.9.20140904 Resolving dependencies... Configuring statistics-0.13.2.1... Building statistics-0.13.2.1... Preprocessing library statistics-0.13.2.1... [ 1 of 46] Compiling Statistics.Test.Internal ( Statistics/Test/Internal.hs, dist/build/Statistics/Test/Internal.o ) [ 2 of 46] Compiling Statistics.Test.Types ( Statistics/Test/Types.hs, dist/build/Statistics/Test/Types.o ) [ 3 of 46] Compiling Statistics.Internal ( Statistics/Internal.hs, dist/build/Statistics/Internal.o ) [ 4 of 46] Compiling Statistics.Transform ( Statistics/Transform.hs, dist/build/Statistics/Transform.o ) Statistics/Transform.hs:113:3: Illegal equational constraint Control.Monad.Primitive.PrimState m ~ s (Use GADTs or TypeFamilies to permit this) When checking that ‘bitReverse’ has the inferred type bitReverse :: forall (m :: * -> *) b. (Control.Monad.Primitive.PrimMonad m, Control.Monad.Primitive.PrimState m ~ s) => Int -> Int -> m b In an equation for ‘mfft’: (Indeed, adding the GADTs language pragma makes the type checker happy, as in the commit here: https://github.com/rrnewton/criterion/commit/3a2487176e92b6972560ab1abdfa09a2b3eb4a49 ) Hmm, well, the source code in this case did not explicitly add the "~ s" constraint, the inference cooked it up. Is this a GHC bug in 7.9 or in 7.8? |

**Note:**See TracQuery for help on using queries.