- Glasgow-haskell-users

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

Re: [Haskell] Haskell profiler
by Tim Chevalier 01 Jan '09

01 Jan '09

On 12/29/08, Srinivas Nedunuri <nedunuri(a)cs.utexas.edu> wrote: > Could someone tell me what the expected accuracy of the Haskell profiler is? > I get quite widely varying results for the amount of time spent on a given > function across different runs (eg one random example, from 1.5% to 10%). I > even upped the size of the dataset in an attempt to increase the accuracy. [redirecting to ghc-users] I assume you mean the GHC profiler. It's normal when profiling any programs, Haskell or not, for timing numbers to vary. Memory allocation counts, however, should be stable across different runs. > Also a related q: why doesnt't the time spent in putStr show up? > You would have to rebuild your GHC libraries with the -auto-all flag in order to get cost centres attached to library functions (but this may defeat some optimizations). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "It's okay to be mean to the evil people who make life unbelievable, but try to be nice to me." -- Nerissa Nields

1 0

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