- Glasgow-haskell-users

Thread-backed handles: thread blocked indefinitely in an MVar operation
by Dimitry Golubovsky 22 Jun '10

22 Jun '10

Hi, I am experimenting with the new feature in GHC such as custom Handles. I use GHC 6.12.2, base 4.2.0.1 I have pasted the code in question as http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26413#a26413 I am trying to create a Handle using a thread as data producer. In my example is is a union of directories, and the Handle contents is newline-separated list of full paths of all files in the union. This list is produced by a thread which reads contents of all directories in the union, turns them into absolute filenames, and sends to the channel. The method of BufferedIO responsible for filling in the Handle's buffer reads data from the channel and places it in the buffer. The problem is, after the contents of the Handle (via hGetContents) has been consumed, the program crashes with the following message: <program name>: thread blocked indefinitely in an MVar operation that is, the BlockedIndefinitelyOnMVar exception has occurred. What is done wrong in my code? The dirClose method seems to be called (its output shows up), however with or without the call to killThread, the exception occurs anyway. Thanks for any ideas. -- Dimitry Golubovsky Anywhere on the Web

2 1

simple rewrite rule example
by Jan Christiansen 22 Jun '10

22 Jun '10

Hi, I'd like to learn how to use ghc rewrite rules. I simply want to replace a function called f by a function called g. I do not unterstand why the rule f->g does not fire. Cheers, Jan module Main where {-# RULES "f->g" forall x. f x = g x #-} main :: IO () main = print (f 1) {-# NOINLINE f #-} f :: a -> Bool f _ = False g :: a -> Bool g _ = True

2 1

getting Core Haskell from GHC API with cross-module inlinings
by Roman Beslik 22 Jun '10

22 Jun '10

Hi. The following code compiles "A.hs" with GHC API: {{{ import GHC import Outputable import DynFlags ( defaultDynFlags ) libdir = "/usr/lib/ghc-6.12.1" targetFile = "A.hs" main = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- fmap (\dflags -> dflags {optLevel = 2}) getSessionDynFlags setSessionDynFlags dflags c <- compileToCoreSimplified targetFile print (showSDoc (ppr c)) }}} A.hs: {{{ import Data.Maybe main = print (show (maybe False (\_ -> True) (Just False))) }}} When "A.hs" is compiled with GHC API, output contains a reference to 'maybe'. When "A.hs" is compiled with "ghc -O2 -ddump-simpl", 'maybe' is inlined and simplified. Why do outputs differ? -- Best regards, Roman Beslik.

2 4

Re: Modules and their explicit export lists (are an annoyance)
by Antoine Latter 21 Jun '10

21 Jun '10

Hi Christian, I encourage you to email the lists or the library maintainer before forking - ther might be ways to solve your problem in a different way or to get the functionality you On Jun 21, 2010 4:20 PM, "Christian Höner zu Siederdissen" < choener(a)tbi.univie.ac.at> wrote: Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> [19.06.2010 20:39]: > Hi everybody, > > I'd like some input on other peoples' thoughts on this. Recently, I > played around with a library that uses an explicit export list. While > there are reasons for havi... > But the more important thing is, that it makes extending module > functionality a pain (eg. if a c... > Btw. there are libraries, where an explicit export list is used, that > export the right amount of... > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/ma... _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 1

Re: Modules and their explicit export lists (are an annoyance)
by Christian Höner zu Siederdissen 21 Jun '10

21 Jun '10

Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen <choener(a)tbi.univie.ac.at> [19.06.2010 20:39]: > Hi everybody, > > I'd like some input on other peoples' thoughts on this. Recently, I > played around with a library that uses an explicit export list. While > there are reasons for having one: > > - efficiencey (inlining in the module) > - encapsulation > > in practice, it seems to me that they are more annoying than useful. For > once, it would think that ghc should produce efficient good across > modules with -O / -O2 anyway. > But the more important thing is, that it makes extending module > functionality a pain (eg. if a constructor is not exported using (..)). > > So, should I really fork a library just to be able to add a function? > > > > Btw. there are libraries, where an explicit export list is used, that > export the right amount of information. For example, in 'vector' enough > is exported to allow you to extend unboxed vectors. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Modules and their explicit export lists (are an annoyance)
by Christian Höner zu Siederdissen 20 Jun '10

20 Jun '10

Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors.

7 7

Re: Modules and their explicit export lists (are an annoyance)
by Antoine Latter 19 Jun '10

19 Jun '10

Hi Christian, Is there a specific library you're having trouble with? One reason library authors can prefer explicit export lists is that they can hide implementation details, which can then make it easier to change in the future without breaking the users of the library. Antoine Cc'ing the haskell-cafe On Jun 19, 2010 1:39 PM, "Christian Höner zu Siederdissen" < choener(a)tbi.univie.ac.at> wrote: Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ANNOUNCE: GHC 6.12.3 Release Candidate 1
by Ian Lynagh 17 Jun '10

17 Jun '10

Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

9 13

Re: How easy is it to build a GHC cross compiler targeting Windows?
by Simon Marlow 16 Jun '10

16 Jun '10

On 16/06/2010 15:38, MH wrote: > I have installed SUSE-10.2 with all mingw packages in my Virtualbox and > ready to start working. Would it be possible to provide a quick step by > step overview of what should be done? I've never done anything of that > sort and have no idea where to start. You would start with perl boot ./configure --build=i386-unknown-linux --host=i386-unknown-mingw32 --target=i386-unknown-mingw32 --with-gcc=something and then see what breaks. We probably don't distinguish between the host platform gcc and the cross-compiler gcc in the build system, that will probably cause difficulties. Cheers, Simon

1 0

What does interruptibility mean exactly?
by Bas van Dijk 16 Jun '10

16 Jun '10

Hello, I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked? newEmptyMVar >>= \mv -> block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: "Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..." Do I need to interpret this as: 1) 'putMVar' is always interruptible because it's an operation that has the ability to block. For example when applied to a full MVar. or: 2) 'putMVar' is only interruptible when it actually blocks and not interruptible when it is sure that it will not block. For example when applied to an empty MVar like in the given program. The reason I'm asking is that in my threads library[2] I previously applied 'putMVar' to an empty MVar to signal the termination of a thread. However due to some comments in the topic about "Asynchronous Exception Wormholes" I got a bit scared that 'putMVar' might throw exceptions even in the scope of a block. Because this could cause dead-locks in my threads library, I rewrote it using TMVars which don't have interruptible operations. However, I'm still not sure about the exact semantics so I would like to clear this up. Regards, Bas [1] http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exce… [2] darcs get http://code.haskell.org/~basvandijk/code/threads/

4 5