December 2008 - Glasgow-haskell-users

black hole detection and concurrency
by Conal Elliott 06 Jan '09

06 Jan '09

I'm looking for information about black hole detection with ghc. I'm getting "<<loop>>" where I don't think there is an actual black hole. I get this message sometimes with the unamb package, which is implemented with unsafePerformIO, concurrency, and killThread, as described in http://conal.net/blog/posts/functional-concurrency-with-unambiguous-choice/… http://conal.net/blog/posts/smarter-termination-for-thread-racing/ . Suppose I have a definition 'v = unsafePerformIO ...', and v is used more than once. Evaluation (to whnf) of v is begun and the evaluation thread gets killed before evaluation is complete. Then the second use begins. Will the second evaluation be (incorrectly) flagged as a black hole? I haven't found a simple, reproducible example of incorrect black-hole reporting. My current examples are tied up with the Reactive library. I do have another strange symptom, which is "thread killed" message. I wonder if it's related to the <<loop>> message. Code below. Thanks, - Conal import Prelude hiding (catch) import System.IO.Unsafe import Control.Concurrent import Control.Exception -- *** Exception: thread killed main :: IO () main = print $ f (f True) where f v = (v `unamb` True) `seq` v -- | Unambiguous choice operator. Equivalent to the ambiguous choice -- operator, but with arguments restricted to be equal where not bottom, -- so that the choice doesn't matter. See also 'amb'. unamb :: a -> a -> a unamb a b = unsafePerformIO (evaluate a `race` evaluate b) -- | Race two actions against each other in separate threads, and pick -- whichever finishes first. See also 'amb'. race :: IO a -> IO a -> IO a race a b = do v <- newEmptyMVar let t x = x >>= putMVar v withThread (t a) $ withThread (t b) $ takeMVar v where withThread u v = bracket (forkIO u) killThread (const v)

6 13

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

Re: [reactive] Re: black hole detection and concurrency
by Conal Elliott 28 Dec '08

28 Dec '08

This is a neat trick indeed! I'd appreciate an explanation of killing one's own thread and then continuing (with a restart in this case). How does the post-kill resumption occur? That is, how does control pass to the tail-recursive call after the self-kill? - Conal 2008/12/28 Peter Verswyvelen <bugfact(a)gmail.com> > I fail to understand this part of the code: > case fromException e of > Just ThreadKilled -> do > myThreadId >>= killThread > unblock (race a b) > > So the current thread gets killed synchronously, then then the race > function is evaluated again? The latter I don't get. > > > > On Sun, Dec 28, 2008 at 3:03 AM, Bertram Felgenhauer < > bertram.felgenhauer(a)googlemail.com> wrote: > >> Sterling Clover wrote: >> > On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote: >> >> In the above code, there is a small window between catching the >> >> ThreadKilled exception and throwing it again though, where other >> >> exceptions may creep in. The only way I see of fixing that is to use >> >> 'block' and 'unblock' directly. >> > >> > That certainly seems to do the trick for the simple example at least. >> One >> > way to reason about it better would be, instead of folding everything >> into >> > the race function, to simply modify ghc's bracket function to give us >> the >> > behavior we'd prefer (speaking of which, I recall there's something in >> the >> > works for 6.12 or so to improve rethrowing of asynchronous exceptions?) >> > >> > brackAsync before after thing = >> > block (do >> > a <- before >> > r <- catch >> > (unblock (thing a)) >> > (\_ -> after a >> myThreadId >>= killThread >> >> > brackAsync before after thing ) >> > after a >> > return r >> > ) >> > where threadKilled ThreadKilled = Just () >> > threadKilled _ = Nothing >> >> This code turns any exception into ThreadKilled further down the stack. >> >> (\e -> do >> after a >> myThreadId >>= flip throwTo (e :: SomeException) >> ... >> >> might do the trick. >> >> My assumption was that anything but 'ThreadKilled' would be a >> real error. This isn't really true, I guess - thanks to throwTo, >> any exception could be asynchronous. >> >> If an exception is thrown, 'after a' is run again after the computation >> has resumed. >> >> That's why I did the cleanup within the 'catch'. >> >> But there's no reason why you couldn't do that as well: >> >> brackAsync before after thing = >> block $ do >> a <- before >> catch (unblock (thing a) >>= \r -> after a >> return r) $ >> \e -> do >> after a >> myThreadId >>= flip throwTo (e :: SomeException) >> brackAsync before after thing ) >> >> > This brackAsync just drops in to the previous code where bracket was and >> > appears to perform correctly. >> >> Right. 'race' should also unblock exceptions in the worker threads, >> >> withThread u v = brackAsync (forkIO (unblock u)) killThread (const v) >> >> but that's an independent change. >> >> > Further, if we place a trace after the >> > killThread, we se it gets executed once when the example is read (i.e. a >> > resumption) but it does not get executed if the (`seq` v) is removed >> from >> > the example So this gives me some hope that this is actually doing what >> > we'd like. I don't doubt it may have further kinks however. >> >> At least the GHC RTS has support for the hard part - unwinding the stack >> so that computations can be resumed seamlessly. >> >> I'm not sure which of the approaches I like better - it seems that we >> have a choice between turning async exceptions into sync ones or vice >> versa, and neither choice is strictly superior to the other. >> >> Enjoy, >> >> Bertram >> >> 'race' update: >> - Bugfix: Previously, only AsyncException-s would be caught. >> Use 'fromException' to select the ThreadKilled exception. >> - I tried using a custom 'SuspendException' type, but this resulted in >> 'test: SuspendException' messages on the console, while ThreadKilled >> is silently ignored... as documented: >> >> http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurre… >> (http://tinyurl.com/9t5pxs) >> - Tweak: Block exceptions while running 'cleanup' to avoid killing >> threads twice. >> - Trick: takeMVar is a blocking operation, so exceptions can be >> delivered while it's waiting - there's no need to use 'unblock' for >> this. In other words, unblock (takeMVar v) and takeMVar v are >> essentially equivalent for our purposes. >> >> race :: IO a -> IO a -> IO a >> race a b = block $ do >> v <- newEmptyMVar >> let t x = unblock (x >>= putMVar v) >> ta <- forkIO (t a) >> tb <- forkIO (t b) >> let cleanup = killThread ta >> killThread tb >> (do r <- takeMVar v; cleanup; return r) `catch` >> \e -> cleanup >> >> case fromException e of >> Just ThreadKilled -> do >> myThreadId >>= killThread >> unblock (race a b) >> _ -> throwIO e >> _______________________________________________ >> Reactive mailing list >> Reactive(a)haskell.org >> http://www.haskell.org/mailman/listinfo/reactive >> > > > _______________________________________________ > Reactive mailing list > Reactive(a)haskell.org > http://www.haskell.org/mailman/listinfo/reactive > >

1 0

FFI imported function names
by Daniil Elovkov 24 Dec '08

24 Dec '08

Hello How is decided whether the name of imported function gets the ending of the form @4 in ghc? I'm having this problem on Windows trying to use HSQL MySQL on windows. I compile HSQL Oracle backend and I get names without that. It's ok. With HSQL MySQL I get names with that stuff. It prevents me from further linking to dll. Supplying in the ghc command-line the "lib" file where names have those marks doesn't have any effect. The linker says that fname@NN cannot be resolved. Can I control that? The ffi calling convention doesn't (and shouldn't as I understand) affect this. The only difference is that in the case of mysql the header file itself where functions are described marks it STDCALL. Is that the reason? Also I changed ffi import line from "hsmysql.h func" to just "func", to no avail. ghc 6.8.2 I'm lost. Please help. -- Daniil Elovkov

1 1

Possible Haddock bug affecting GHC docs
by Krzysztof Skrzętnicki 22 Dec '08

22 Dec '08

Hello everyone Please visit these to pages: http://www.haskell.org/ghc/docs/6.8.3/html/libraries/haskell98/CTypes.html -- ver 0.9 http://www.haskell.org/ghc/docs/6.10.1/html/libraries/haskell98/CTypes.html -- ver 2.3.0 They show documentation produced by Haddock. The problem is: on the second page (for GHC 6.10.1) there is no information about exported module: > module CTypes (module Foreign.C.Types) where > import Foreign.C.Types It seems it has something to do with bug fixed by 2.3.0 version of Haddock: (see http://haskell.org/haddock/CHANGES.txt ) > Changed in version 2.3.0: > (...) > * Fix a bug that made hidden modules show up in the contents & index pages > (...) This is really annoying, especially that documentation on page doesn't contain links for source code. I think this should be fixed too. I also checked that information about exported modules appears when there is more thing to export like in Control.Concurrent. I didn't file a Haddock bug since I failed to make minimal example that reproduces the bug. A.hs: > module A (module B) where > > import B B.hs: > module B (one,two) where > > one :: Int > one = 1 > > two :: Int > two = 2 Turns out to generate good documentation. Perhaps there is something more to be done to actually trigger the bug. I attach my testing suite (A.hs, B.hs, Makefile, results). All best Christopher Skrzętnicki

2 1

Type families: module export of instance data constructor
by Ben Horsfall 22 Dec '08

22 Dec '08

I have a type family class Lang term where data Token term :: * : with instance Lang Term where newtype Token Term = T String : I can't work out how to export the type constructor T from the module, unless I make no explict exports from the module at all. Ben

2 3

Re: [Haskell-cafe] Can I build and install GHC 6.10.1 without previous installed ghc
by Don Stewart 21 Dec '08

21 Dec '08

chunye.wang: > Hi All, > > > I have our own Linux distribution installed in my server. > it is based on RedHat 9.0. Because it is the server, I can > not update it to any other linux distribution > > Here is my situation, I have no machine with any version of ghc > installed. Please use a basic linux binary. http://haskell.org/ghc/download_ghc_6_10_1.html#x86linux Such as "Linux (x86)" -- Don

1 0

Can't compile GHC 6.8.2
by Barney Stratford 21 Dec '08

21 Dec '08

I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the typechecker refuses to compile. The problem seems to be that the hi-boot files in compiler/typecheck contain some incorrect type signatures. I've fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As it stands, it says tcMatchesFun :: Name.Name -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) but it should say something like tcMatchesFun :: Name.Name -> Bool -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, so I tried saying Prelude.Bool instead. Now I get the complaint that Prelude.Bool isn't in scope. Has anyone else seen this issue? I've looked for answers in the docs and with Google, but no luck. I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed the Fink package for GHC 6.8.2 and adapted it slightly so it would bootstrap from my existing GHC, as the bootstrap code available for download relies on a later version of my OS. GHC 6.2 can't compile GHC 6.10, which is why I'm going for the earlier version. Cheers, Barney.

7 20

Graham Hutton's calculator example for win32
by Ahn, Ki Yung 21 Dec '08

21 Dec '08

In Graham Hutton's "Programming in Haskell" there is an interactive calculator example using ANSI code to implement the UI on the terminal. This example doesn't work on MS Windows XP or other MS OSes based on NT kernel, since their command line does not support ANSI very well. But, thanks to ansi-terminal on Hackage, I was able to extract minimal code from the package to make a win32 version of the calculator example in Hutton's book. calculatorWin32.lhs and Win32ANSI.hs is an implementation for win32. I extracted the win32 console API bindings for setting cursor positions from ansi-terminal project and put them in Win32ANSI.hs. I had to put this in a separate file because I had an issue with ghci. To run this, I had to compile the console API bindings with ghc first and then run ghci as follows C:\> ghc -c Win32ANSI.hs C:\> ghci calculatorWin32.lhs Without compiling the object code, ghci cannot find the proper link for win32 console API FFI bindings. C:\> ghci calculatorWin32.lhs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 3] Compiling Parsing ( Parsing.lhs, interpreted ) [2 of 3] Compiling Win32ANSI ( Win32ANSI.hs, interpreted ) During interactive linking, GHCi couldn't find the following symbol: GetConsoleScreenBufferInfo@8 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org Is this a bug or a natural behavior of ghci? This is strange to me since ghci finds the proper link for the functions in the other C libraries such as getch in conio.h. In addition, I am attaching a patched calculator.lhs which works for Unix/Linux on both GHC 6.8.x and GHC 6.10.1. The one currently on the book homepage only works for GHC 6.8.x but not GHC 6.10.1. This is due to the bug fix of hSetBuffering in GHC 6.10.1. To run these calculator example you will also need Parsing.lhs from the book hompage. http://www.cs.nott.ac.uk/~gmh/Parsing.lhs -- Ahn, Ki Yung

1 0

please test: cabal install now less eager to reinstall core packages
by Duncan Coutts 19 Dec '08

19 Dec '08

Claus, Simon, You'll recall the cabal-install problem you noticed recently where it decides it wants to re-install some core library like array or containers or whatever. I'd appreciate it if you could test the darcs version of cabal-install and see if it is behaving better now. It was choosing to re-install packages when the way it had chosen to configure the available version of the package (ie what exact dependencies it'd picked) did not exactly match those of the installed package. I've changed things so that it now picks the installed version when the additional constraints it adds (direct and indirect dependencies) do not conflict with the existing constraints. This means it'll pick the installed instance in many more cases and when it does not that there is a more legitimate reason. It still may have been possible to use the installed version if we had known that information much earlier and made different choices at an earlier stage. I've not yet added support for user supplied install constraints but I plan to shortly (eg --constraint='array installed'). Duncan

1 0