- Glasgow-haskell-users

Re: [Haskell-cafe] createProcess shutting file handles
by Duncan Coutts 16 Feb '09

16 Feb '09

On Sun, 2009-02-15 at 11:06 +0000, Duncan Coutts wrote: > On Sun, 2009-02-15 at 09:24 +0000, Neil Mitchell wrote: > > Hi > > > > >> What have I done wrong? Did createProcess close the handle, and is > > >> there a way round this? > > > > > > The docs for runProcess says: > > > > > > Any Handles passed to runProcess are placed immediately in the > > > closed state. > > > > > > but the equivalent seems to be missing from the documentation for > > > createProcess. > > > > However the createProcess command structure has the close_fds flag, > > which seems like it should override that behaviour, and therefore this > > seems like a bug in createProcess. > > close_fds :: Bool > > Close all file descriptors except stdin, stdout and stderr in > the new process > > This refers to inheriting open unix file descriptors (or Win32 HANDLEs) > in the child process. It's not the same as closing the Haskell98 Handles > in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. Duncan

3 3

DLL thread safety
by Neil Mitchell 16 Feb '09

16 Feb '09

Hi, I'm building a DLL using the instructions here: http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html I must call startupHaskell before I make any calls to Haskell functions. However, that page doesn't detail any thread safety rules. In particular: * If I call startupHaskell on Thread 1, can I make Haskell calls from Thread 2. * Can I make Haskell calls from both Thread 1 and Thread 2 simultaneously. Many thanks Neil

2 1

:info features
by Remi Turk 14 Feb '09

14 Feb '09

One of my most used GHCi commands is :info, but quite often the type or class definitions that I'm interested in get drowned in lots of instances. So a week ago I wrote a feature request and a little patch that allowed the following: :info Show -- See class definition and instances :info -Show -- See class definition only SPJ agreed with the idea itself, but suggested an alternative set of commands: :info Show -- See class definition only :instances Show -- See instances of Show This would have the advantage of making it easier to later add additional features: :instances Show (Tree _) -- See instances of form (Show (Tree ...)) However, it would make ":i" ambiguous, which is rather sad. Another potential addition to :info (or another command) would be evaluating types to their normal form, that is, expanding (associated) type synonyms. E.g.: :typeeval Plus (Suc Zero) (Suc Zero) -- (Suc (Suc (Suc (Suc Zero)))) Again, the question is whether this is really useful (or reasonably easy to implement, SPJ?) and if so, what interface is to be preferred? So what's your favourite syntax? One of these options or something else? Or are these features completely unnecessary? Oh, the ticket can be found at http://hackage.haskell.org/trac/ghc/ticket/2986#comment:3 Groeten, Remi

5 9

DPH Questions
by James Swaine 12 Feb '09

12 Feb '09

I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special-purpose standard Prelude when writing vectorised code with DPH. We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations. There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step. Also - there are several papers which mention foldP as being part of the (prospective) implementation, but I couldn't find this in any of the modules. Has this one not been implemented yet? Much thanks, James Swaine

3 3

bug in ghc specialiser?
by Malcolm Wallace 11 Feb '09

11 Feb '09

Here is an apparent bug in ghc's specialisation rules. The rewrite rule generated by a SPECIALISE pragma seems to want to pattern-match on exact dictionaries (as well as types). But the compiler is not necessarily able to fully resolve dictionaries before the rules are supposed to fire. First, the source code we want to specialise: {-# SPECIALISE hedgehog :: Float -> Vector3 Float -> [Cell_8 (Coord3 Float)] -> [Cell_8 (Vector3 Float)] -> [(Coord3 Float, Coord3 Float)] #-} hedgehog :: ( Fractional a, Cell cell vert, Eq vert , Geom coord, Geom vector, Embed vector coord ) => a -> vector a -> [cell (coord a)] -> [cell (vector a)] -> [(coord a, coord a)] And the core + interface generated for this module contains the rule: "SPEC Hedgehog.hedgehog" ALWAYS forall Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 CellTypes.$f1 Geometries.$f5 Geometries.$f3 Geometries.$f1 = Hedgehog.hedgehog1 But in a different module, here is what the usage site looks like just before the specialisation rules are supposed to fire: hedgehog_a4wy = Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 $dFractional_a4xP RectGrid.$f2 CellTypes.$f1 (Dataset.$p2Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) (Dataset.$p1Embed @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 @ Geometries.Coord3 Geometries.$f1) Geometries.$f1 Notice how there are several dictionary selector functions sitting there, so although some of the dictionaries match, not all do, and the rule does not fire. However, later the worker-wrapper transformation is able to resolve those outstanding dictionaries, giving: hedgehog_a4wy = Hedgehog.$whedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ CellTypes.MyVertex @ Geometries.Coord3 @ Graphics.Rendering.OpenGL.GL.CoordTrans.Vector3 GHC.Float.$f16 RectGrid.$f2 Geometries.$f5 Geometries.$f3 Geometries.$f1 So I'm left calling the worker for the polymorphic version of the function, rather than the specialised monomorphic code I wanted. Given how many dictionaries are involved, and that this is the inner loop of the program, I'm hoping there is a big performance win waiting for me, if only I can get that specialised code to run! Regards, Malcolm

2 1

Pragma not recognised when wrapped in #ifdef
by Alistair Bayley 11 Feb '09

11 Feb '09

I have this little test program: {-# LANGUAGE CPP #-} #ifdef PRAGMA_DERIVE_TYPEABLE {-# LANGUAGE DeriveDataTypeable #-} #else {-# OPTIONS -fglasgow-exts #-} #endif -- This file is Test/Fail.hs. -- ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail module Test.Fail where import Data.Generics data Fail = Fail deriving Typeable If compile this wih the command ghc --make -optP-DPRAGMA_DERIVE_TYPEABLE -XCPP Test.Fail then I get this error from ghc-6.10.1: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' I've checked the preprocessor output with -E, and that looks fine. I can compile the preprocessor output with ghc without errors. Alistair

7 9

Byte in list
by Aswad, Mustafa K 10 Feb '09

10 Feb '09

Hi dear I need to calculate the size of alist consist of n element (("I(a*b)" , "I(b) , I(a)") in 32 bit machine ? -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.

1 0

Re: How bad is the PowerPC backend?
by Tim Chevalier 10 Feb '09

10 Feb '09

On 2/9/09, David Brown <haskell(a)davidb.org> wrote: > > Which CPU is the x86? The modern x86 CPUs (such as Core2) will be > significantly faster than the PowerPC, even at comparable clock rates. > Have you just compared even C code tests? > I think that goes a long way towards explaining it... a simple C loop that I tried runs for 4.5s on the PC and 30s on the Mac. So probably this isn't GHC's fault. Thanks for the suggestion. Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "In fact, a sense of essence is, in essence, the essence of sense, in effect." -- Douglas Hofstadter

1 0

How bad is the PowerPC backend?
by Tim Chevalier 09 Feb '09

09 Feb '09

Hello, For obscure reasons, I'm running some benchmarks both on an x86 machine (2.20 Ghz, 2 GB of RAM, Linux 2.6.22-15) and on a PowerPC Mac (1 Ghz, 512 MB of RAM, Mac OS 10.5). I noticed that even some pretty simple programs run much slower on the Mac than on the PC. For example, the following program (edited down from the "life" nofib benchmark): ------------------------------------------------- limit xs = go [] xs go acc (x:y:xs) | x==y = acc ++ [x] | otherwise = go (acc ++ [x]) (y:xs) go acc [x] = acc ++ [x] go acc [] = error "limit" main = print (length (limit (iterate (\ x -> if x == 10000 then x else (x+1)) 1))) --------------------------------------------------- runs in about 1.5 seconds on the PC, and 14 seconds on the Mac. This is with ghc -O2, version 6.10.1. The numbers are about the same on either machine whether I use -fvia-C or -fasm. The Mac does have a lot less RAM, but I can see that the program isn't swapping. So is the PPC backend really this bad, or should I be looking for something weird with the hardware or configuration on the Mac? Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I don't like your I-can-use-anything-as-an-adjective attitude." -- Larry Wall

2 2

length of module name affecting performance??
by Daniel Gorín 09 Feb '09

09 Feb '09

Hi While trying to see if I could make some code run faster I stumbled upon something that looks weird to me: 2x-3x performance loss when a module is renamed to a longer name! Here's what I see with the attached examples: #diff long-modname-ver.hs short-modname-ver.hs 2c2 < import VeryLongModuleName --- > import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 < module VeryLongModuleName --- > module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver > /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver > /dev/null real 22.23 user 21.97 sys 0.10 I'm using GHC 6.10.1 on OS X. Any ideas on what may be going on? Thanks Daniel

9 12