- Glasgow-haskell-users

ghc 6.10.2 - when?
by Bulat Ziganshin 08 Jan '09

08 Jan '09

Hello glasgow-haskell-users, are you have any plans of releasing ghc 6.10.2 soon? i ask since there are plans to issue gtk2hs soon, it will be great to have cleaned up 6.10 behind it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

building ghc-6.10.1 against readline
by Reid Barton 08 Jan '09

08 Jan '09

Hello all, Here are quick and dirty instructions for building ghc-6.10.1 against readline instead of editline, for anyone who may be interested. 1. Unpack the ghc source and extralibs trees into ~/build/ghc-6.10.1 (Where you put your build tree obviously doesn't matter; I just specify it for clarity.) 2. Download this patch to ~/build: http://mauke.ath.cx/stuff/haskell/ghc-6.10.1-readline.diff 3. Apply the patch by running (from ~/build): patch -p0 < ghc-6.10.1-readline.diff 4. Download the readline package to ~/build/ghc-6.10.1/libraries: http://hackage.haskell.org/packages/archive/readline/1.0.1.0/readline-1.0.1… 5. Unpack it, and create a symlink (in ~/build/ghc-6.10.1/libraries): ln -s readline-1.0.1.0 readline 6. Now in ~/build/ghc-6.10.1, you can run ./configure, make, etc. Thanks to mauke on #haskell for the patch, which is also appended to this email for posterity. Regards, Reid ----------- ghc-6.10.1-readline.diff diff -ru ghc-6.10.1/compiler/ghc.cabal.in ghc-6.10.1-hax/compiler/ghc.cabal.in --- ghc-6.10.1/compiler/ghc.cabal.in 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghc.cabal.in 2008-11-10 04:17:42.000000000 +0100 @@ -72,7 +72,7 @@ Build-Depends: unix if flag(editline) - Build-Depends: editline + Build-Depends: readline CPP-Options: -DUSE_EDITLINE GHC-Options: -Wall -fno-warn-name-shadowing -fno-warn-orphans diff -ru ghc-6.10.1/compiler/ghci/InteractiveUI.hs ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs --- ghc-6.10.1/compiler/ghci/InteractiveUI.hs 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs 2008-11-10 04:28:39.000000000 +0100 @@ -66,7 +66,7 @@ #ifdef USE_EDITLINE import Control.Concurrent ( yield ) -- Used in readline loop -import System.Console.Editline.Readline as Readline +import System.Console.Readline as Readline #endif --import SystemExts @@ -327,7 +327,7 @@ Readline.initialize withGhcAppData - (\dir -> Readline.readHistory (dir </> "ghci_history")) + (\dir -> return True {- Readline.readHistory (dir </> "ghci_history") -}) (return True) Readline.setAttemptedCompletionFunction (Just completeWord) @@ -367,8 +367,8 @@ #ifdef USE_EDITLINE liftIO $ do - Readline.stifleHistory 100 - withGhcAppData (\dir -> Readline.writeHistory (dir </> "ghci_history")) + -- Readline.stifleHistory 100 + withGhcAppData (\dir -> return True {- Readline.writeHistory (dir </> "ghci_history") -}) (return True) Readline.resetTerminal Nothing #endif diff -ru ghc-6.10.1/libraries/Makefile ghc-6.10.1-hax/libraries/Makefile --- ghc-6.10.1/libraries/Makefile 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/libraries/Makefile 2008-11-10 04:12:01.000000000 +0100 @@ -46,7 +46,7 @@ ifeq "$(Windows)" "YES" SUBDIRS += $(wildcard Win32) endif -SUBDIRS += directory process pretty hpc template-haskell editline Cabal random haskell98 +SUBDIRS += directory process pretty hpc template-haskell readline Cabal random haskell98 # Set GhcBootLibs=YES from the command line to work with just the libraries # needed to bootstrap GHC.

1 0

Re: [reactive] Re: black hole detection and concurrency
by Conal Elliott 08 Jan '09

08 Jan '09

Indeed -- many thanks to Bertram, Sterling, Peter & others for the help! I think getting this bug fixed will solve Reactive's mysterious bugs and unblock its progress. - Conal On Sat, Jan 3, 2009 at 1:20 PM, Peter Verswyvelen <bugfact(a)gmail.com> wrote: > That is very good news! Let's hope it's a bug that is easy enough to > fix, since I guess the RTS is very tricky. > > Thanks for all this effort. It would explain a lot of strange behaviour. > > Cheers, > Peter Verswyvelen > CTO - Anygma.com > > > On Sat, Jan 3, 2009 at 4:48 PM, Bertram Felgenhauer > <bertram.felgenhauer(a)googlemail.com> wrote: > > Conal Elliott wrote: > >> Thanks very much for these ideas. Peter Verswyvelen suggested running > the > >> example repeatedly to see if it always runs correctly. He found, and I > >> verified, that the example runs fine with Bertram's last version of > unamb > >> below, *unless* it's compiled with -threaded and run with +RTS -N2. In > the > >> latter case, it locks up after a while. > > > > It seems that we've found an RTS bug. If a thread is started with > > exceptions blocked, then throwTo might never deliver its exception and > > block forever, as can be seen with the following test program, which > > locks up after a while (immediately with the non-threaded RTS) > > > > import Control.Exception > > import Control.Concurrent > > import Control.Monad > > > > test n = do > > t <- block $ forkIO yield > > yield > > putStr $ show n ++ ": kill\n" > > killThread t > > > > main = forM_ [1..] test > > > > Or, even more convincing: > > > > import Control.Exception > > import GHC.Conc > > > > main = do > > t1 <- block $ forkIO yield > > t2 <- forkIO $ killThread t1 > > yield > > yield > > threadStatus t1 >>= print > > threadStatus t2 >>= print > > > > prints (fairly reliably, it seems): > > > > ThreadFinished > > ThreadBlocked BlockedOnException > > > > (Trac is giving me errors right now. I'm planning to report this later.) > > > >> I also tried a version with brackAsync and found that it eventually > locks up > >> even under ghci. When compiled & run multi-threaded, it locks up almost > >> immediately. > > > >> -- This one locks up after a while even in ghci. When compiled > -threaded > >> -- and run +RTS -N2, it locks up almost immediately. > >> a `race` b = do > >> v <- newEmptyMVar > >> let t x = x >>= putMVar v > >> withThread (t a) $ withThread (t b) $ takeMVar v > >> where > >> withThread u v = brackAsync (forkIO u) killThread (const v) > > > > At the point the 'forkIO' is run, exceptions are blocked, making the > > thread basically immortal. Using > > > >> withThread u v = brackAsync (forkIO $ unblock u) killThread (const v) > > > > we get the same behaviour as with my 'race' - it works for a while, but > > locks up eventually. > > > > I believe that the actual lockup is similar to the test programs above > > in all cases - what's different is just the probability of triggering > > it. > > > > regards, > > > > Bertram > > _______________________________________________ > > 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 >

2 4

GADTs and functional dependencies in ghc 6.10.1
by Reid Barton 07 Jan '09

07 Jan '09

Hello all, I think (hope) this question is different from the ones about GADTs recently discussed on this list. The following program compiles under ghc 6.8.2 but not under ghc 6.10.1: > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, GADTs, KindSignatures, ScopedTypeVariables #-} > > class Foo a fa | a -> fa where > n :: a -> Int > > data Bar :: * -> * -> * where > Id :: Bar a a > > baz :: forall a fa b fb. (Foo a fa, Foo b fb) => Bar a b -> Int > baz Id = n (undefined :: a) ghc 6.10.1's error message: /tmp/fundep.hs:10:0: Couldn't match expected type `fb' against inferred type `fa' `fb' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:21 `fa' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:16 When using functional dependencies to combine Foo a fa, arising from a use of `n' at /tmp/fundep.hs:10:9-26 Foo a fb, arising from the type signature for `baz' at /tmp/fundep.hs:10:0-26 When generalising the type(s) for `baz' I find the message about the `Foo a fb' constraint quite confusing. Can anyone explain this error message to me? If I change the type of Id to Id :: Bar a b, then the program compiles. Regards, Reid

2 1

Re: [reactive] Re: black hole detection and concurrency
by Bertram Felgenhauer 06 Jan '09

06 Jan '09

Peter Verswyvelen wrote: > 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. Let's look at what happens when an asynchronous exception arrives. The current thread gets killed. It gets killed asynchronously; as far as the RTS knows, the exceptionit might happen inside a pure computation which may be accessible to other threads. This means that the RTS has to patch things up so that reentering the corresponding thunks continues the computation - because another thread might need the value later. It does that by traversing the stack and turning update frames into ap nodes on the heap, and linking the entered thunks to those using an indirection (again, see RaiseAsync.c for details). Now in fact, IO actions are indistinguishable from pure computations by the RTS, so this mechanism also makes IO actions resumable, in principle, if you can access the corresponding thunk somehow. Normally you can't - there is no reference to that thunk - but unsafePerformIO gives you that reference. So in the above example, the current thread gets killed. However, the IO action (suspended right before the 'unblock (race a b)') is still accessible through the unsafePerformIO thunk. When another thread enters that thunk, execution resumes at that point. It may also be the same thread if it caught the exception further down the stack and later enters the unsafePerformIO thunk again. I don't understand all the interactions here - I don't know why the code is racy in the parallel RTS. Bertram

6 6

unique identifiers as a separate library
by Sebastian Fischer 06 Jan '09

06 Jan '09

Hello, for a project I am using the libraries Unique, UniqSupply, and UniqFM from the package ghc. It seems odd to have a dependency on a whole compiler only in order to use its (highly efficient and, hence, preferred) implementation of unique identifiers. Would it be possible to put everything concerned with unique identifiers in GHC into a separate package on Hackage? This may also allow me to get a fix for <http://hackage.haskell.org/trac/ghc/ticket/2880 > without reinstalling GHC. Cheers, Sebastian

5 17

building HSQL MySQL on windows (Was: FFI imported function names)
by Daniil Elovkov 06 Jan '09

06 Jan '09

Ok, enough talking to myself :) If anybody ever wants to build hsql-mysql on windows and has the same problems as I had, here's how it should be done. The problem I had seemed to be that libmysql.dll uses stdcall, but names its functions without @<n> decoration. Thus, when linking a Haskell program against it, names with @<n> cannot be resolved. The solution is pretty much a hack. Somebody from the Ruby community used to run into the same problem, from the same situation -- namely building ruby mysql bindings. Here is the procedure one person suggests http://rubydotnetproxy.rubyforge.org/mysql_win.html It worked perfectly for me. Of course, with some cabal specifics, which is obviously not described in the above page. The solution was to create a def file listing the names which could not be resolved and creating a .a file based on the dll and this def file. 2008/12/24 Daniil Elovkov <daniil.elovkov(a)googlemail.com>: > Mm, actually I didn't change the calling convention ffi imports when I > thought I did. I tried to do it through defines... > > Well, by explicitly saying ccall I get the names without @<n> > decoration. And it all links well. But I get segault when I run the > code, which should mean that calling conventions didn't match. > > Actually I found some ramblings on the internet that there's something > wrong with libmysql.dll and libmysql.lib in this respect, but they > were from 2004. > > Thus the question: how do I link against a lib file in ghc? When I say > -lmysql on command line it strictly searches for dll and complains if > it's not found. Adding lib exlpicitly on the cmd line doesn't seem to > have any effect. > > Thanks > > > 2008/12/24 Daniil Elovkov <daniil.elovkov(a)googlemail.com>: >> 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 >> > > > > -- > Daniil Elovkov > -- Daniil Elovkov

2 1

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

pthread mutex error building 6.10 on NetBSD
by Donn Cave 04 Jan '09

04 Jan '09

I tried to build GHC 6.10.1 on NetBSD 4.0 this afternoon, and ran into an error, where cabal-bin calls the stage2 ghc in utils/installPackage. pthread_mutex_unlock() is called, evidently from fileLock(), with an invalid mutex. NetBSD's pthread implementation differs from Linux in its intolerance of such things. I have found errors where someone forgets that a mutex was never used and tries to unlock it. I guess you could do that all day long on Linux without noticing anything, but NetBSD aborts the program. In the present case, I don't see anything like that wrong in rts/FileLock.c, though. I'm stumped. So I'm checking, has anyone else built 6.10 on NetBSD? Donn

2 2

Preferred gcc for use with ghc
by Gregory Wright 03 Jan '09

03 Jan '09

Hi, What is the preferred gcc to use with ghc 6.10.1? I'm starting the long and doubtless slow process of putting together a more user friendly (and binary distributable) ghc distribution to be built using MacPorts. The guidance about gcc on the wiki is vague. Is there a best choice? Or at least some versions to be avoided? Best, Greg

3 2