- Glasgow-haskell-users

Alternative (per-project) package database
by Dimitry Golubovsky 30 Jun '10

30 Jun '10

Hi, Summarizing my findings (I couldn't find solution to this problem anywhere; maybe somebody else gets interested as well). Experimental setting: A simple package targeting a hello-world like application. We will keep all dependent upon packages in a subdir named .private-pkg All commands are run from within this project directory. Bootstrapping: Initialize packages database ghc-pkg init .private-pkg Clone few initial packages from the existing installation: ghc-pkg describe <package name here> | (GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg register -) These packages are (in this order): ffi, rts, ghc-prim, integer-gmp, base-4.2.0.1 (or whatever base-4 you have) If just "base" is specified, ghc-pkg will attempt to dump the description of base-3.x.x.x package which is not what we need. Check that packages are installed without problems. $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Try to install some package (for simplicity, choose `bytestring' as it has only base in dependencies). (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install bytestring --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Our test executable looks like this: --------------------------------------------------------------------------- module Main where import System.Directory main = do putStrLn "Hello Private World" getDirectoryContents "." >>= putStrLn . show --------------------------------------------------------------------------- So we have to include `directory' as dependency in the project's cabal file. Let's build the executable: (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) Resolving dependencies... Configuring filepath-1.1.0.4... Preprocessing library filepath-1.1.0.4... Building filepath-1.1.0.4... [1 of 3] Compiling System.FilePath.Windows ( System/FilePath/Windows.hs, dist/build/System/FilePath/Windows.o ) [2 of 3] Compiling System.FilePath.Posix ( System/FilePath/Posix.hs, dist/build/System/FilePath/Posix.o ) [3 of 3] Compiling System.FilePath ( System/FilePath.hs, dist/build/System/FilePath.o ) Registering filepath-1.1.0.4... Installing library in /home/dima/src/hello-pvt/lib/filepath-1.1.0.4/ghc-6.12.2 ............................... Building directory-1.0.1.1... [1 of 1] Compiling System.Directory ( System/Directory.hs, dist/build/System/Directory.o ) Registering directory-1.0.1.1... Installing library in /home/dima/src/hello-pvt/lib/directory-1.0.1.1/ghc-6.12.2 Registering directory-1.0.1.1... Configuring hello-pvt-0.1... Preprocessing executables for hello-pvt-0.1... Building hello-pvt-0.1... Linking dist/build/hello-pvt/hello-pvt ... Installing executable(s) in /home/dima/src/hello-pvt/bin .................... $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 directory-1.0.1.1 ffi-1.0 filepath-1.1.0.4 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 old-locale-1.0.0.2 old-time-1.0.0.5 rts-1.0 unix-2.4.0.2 Thus, everything needed got compiled and installed under the project's directory. So it will be easy to clean everything up just by removing bin, lib, and .private-pkg subdirs (or choose a better prefix for cabal install, so everything will install in a single location). So, cabal does work in project-private mode. Maybe developers of cabal-install would consider adding such mode to the program, so all these extra options will not be needed. Of course votes from other users will increase the chance of such addition ;) Thanks. -- Dimitry Golubovsky Anywhere on the Web

2 1

GHC.IO.Device and "ready" method?
by Dimitry Golubovsky 29 Jun '10

29 Jun '10

Hi, Should an implementation of GHC.IO.Device expect the `ready' method to be called from a thread different than one waiting for an I/O operation on a handle to complete, while that operation is in progress? As a more general question, are GHC Handles (and underlying implementations of GHC.IO.Device and GHC.IO.BufferedIO) expected to be thread-safe? I would be happy to store the id of the thread that calls mkFileHandle somewhere in the underlying `dev' and simply reject all I/O requests that come from other threads, but is this correct/permitted behavior? Thanks. -- Dimitry Golubovsky Anywhere on the Web

3 2

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

29 Jun '10

Marc, Marc Weber wrote: > If you want to give hack-nix a try you can get what you're looking for > by running these two commands: > hack-nix --build-env > . ./default-env > However you have to install Nix once. I thought I could stay within Cabal without adding Nix, however Nix was on my mind. My initial thought is: for bootstrapping, I could dump package descriptions from the global database for few basic packages (rts, ghc-prim, base, etc.) and run them through ghc-pkg register with GHC_PACKAGE_PATH set to cover only per-project package conf directory. -- Dimitry Golubovsky Anywhere on the Web

1 0

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