June 2010 - Glasgow-haskell-users

Alternative (per-project) GHC package database?
by Dimitry Golubovsky 29 Jun '10

29 Jun '10

Hi, I would like to have a completely per-project configuration of GHC installed packages. Suppose I have a project (targeting one or more executables) directory: /my/project and a (initially empty) subdirectory in it: /my/project/packages and GHC and Cabal are run like cd /my/project ; GHC_PACKAGE_PATH=/my/project/packages cabal install so the default global and user package configurations are not visible when building the project. How can I bootstrap a fresh minimal working GHC package configuration at the empty location? Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

new recursive do notation (ghc 6.12.x) spoils layout
by John Lask 23 Jun '10

23 Jun '10

Whilst I have nothing against the change in syntax for recursive do aka http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html Instead of writing mdo a <- getChar b <- f c c <- g b putChar c return b you would write do a <- getChar rec { b <- f c ; c <- g b } putChar c return b it does spoil the nice layout - it would be nice to just be able to write (which does not parse) do rec a <- getChar b <- f c c <- g b putChar c return b I don't particularly care that the only recursive statements are #2,#3 - I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised "do rec" as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this?

3 3

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

22 Jun '10

Simon, On Tue, Jun 22, 2010 at 4:31 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > So the problem is that fillReadBuffer has to return 0 to indicate EOF, but > you are killing the slave thread as soon as it has reached the end of the > stream. So you get one call to fillReadBuffer that returns the data up to > the end of the stream, and the next call that should return 0 blocks on the > Chan indefinitely because the slave thread has already been killed. Thanks for your reply. Updated paste: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26455 I enclosed readChan in a catchException call which seems to have cured the problem: it just simulates EOF on the handle if the thread is blocked (channel vanished). Interestingly that in the failing version, handle closing was done in a separate thread (thread 3), but in the updated version it was the same thread 1. -- Dimitry Golubovsky Anywhere on the Web -- Dimitry Golubovsky Anywhere on the Web

2 1

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