- Glasgow-haskell-users

GHC 6.10 changes for recursive calls to class instances
by Ganesh Sittampalam 19 Feb '09

19 Feb '09

Hi, I have a problem in GHC 6.10 with functions in a class instance calling other functions in the same class instance. It seems that the dictionary is freshly constructed for this call, despite being already available. The reason I care is that I want to memoise some expensive computations inside the dictionary for each instance. [Obviously I also have to make sure that the dictionary isn't constructed multiple times by external callers, but I can make other arrangements to ensure that.] To see the problem in action, run main from the attached code. In GHC 6.8 and before, this only executes the trace statement once. In GHC 6.10, the trace statement executes twice, at all optimisation levels. This seems related to http://hackage.haskell.org/trac/ghc/ticket/2902, but I'm a little unclear on whether it's the same problem or not. Cheers, Ganesh

1 0

Plans for GHC 6.10.2
by Ian Lynagh 19 Feb '09

19 Feb '09

Hi all, This is just a quick summary of our plans for GHC 6.10.2. While it is possible that we will fix some others, for the 6.10.2 release we mainly intend to look at the high-priority bugs in the 6.10.2 milestone. They are listed here: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If there is a bug not in that list that is causing you major problems, then please let us know. We expect to have a release candidate ready around the end of next week. Thanks Ian

4 6

hsc2hs and HsFFI.h
by Ian Lynagh 18 Feb '09

18 Feb '09

Hi all, Currently, hsc2hs (as shipped with GHC) cannot be used with just hsc2hs Foo.hsc as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897) To make it work you need to run something like hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc (it also works when called by Cabal, as Cabal passes it this flag automatically). However, we would like to have it work without needing to use any special flags, and without having to use it from within a Cabal package. The obvious solution to this problem would seem to be to put HsFFI.h in /usr/lib/hsc2hs/include and have hsc2hs automatically add that to the include path. However, hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't a compiler-independent header file; for example, GHC's implementation defines HsInt to be a 64-bit integer type on amd64, whereas hugs's implementation defines it to be a 32-bit type. We therefore need a different HsFFI.h depending on which compiler we are using. One option would be to have hsc2hs (when installed with GHC) append "-I /usr/lib/ghc-6.10.1/include" to the commandline. If the user gives a "-I /usr/lib/hugs/include" flag then this path will be looked at first, and the hugs HsFFI.h will be used. Another option would be for the user to tell hsc2hs which compiler they're using, e.g. hsc2hs --compiler=/usr/bin/ghc Foo.hsc (this "compiler" is distinct from the C compiler that hsc2hs will use). hsc2hs will then pass the appropriate -I flag, depending on what sort of compiler it is told to use. The hsc2hs that comes with GHC would probably default to using the GHC that it is installed with, but standalone hsc2hs would probably default to searching for /usr/bin/ghc, /usr/bin/hugs, etc. This last approach would also make it possible for hsc2hs to take "-package foo" flags, and add the include paths for the requested packages too. The downside is that it's pushing a lot more knowledge into hsc2hs, which means there is one more thing to keep in sync. Has anyone got any other alternatives to consider? Or opinions on which solution is best? Thanks Ian

6 5

Re: [Haskell-cafe] Gtk2HS 0.10.0 Released
by Christian Maeder 17 Feb '09

17 Feb '09

Duncan Coutts wrote: > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: >> Does this version work from ghci? >> >> -- Lennart > > Specifically I believe Lennart is asking about Windows. It's worked in > ghci in Linux for ages and it worked in ghci in Windows prior to the > 0.9.13 release. > > In the 0.9.13 release on Windows there was something funky with linking > (possibly due to using a newer mingw) and ghci's linker could not > understand was was going on and could not load the packages. I'm having trouble http://hackage.haskell.org/trac/ghc/ticket/2615 (cairo depends on pthread, which has a linker script) Is there an easy workaround? Maybe that ticket can be considered in "Plans for GHC 6.10.2" Cheers Christian

3 3

Users guide missing
by Neil Mitchell 16 Feb '09

16 Feb '09

Hi The web page: http://haskell.org/haskellwiki/GHC Links to the latest users guide as a PDF, unfortunately the file is missing: http://www.haskell.org/ghc/docs/latest/users_guide.pdf Thanks Neil

1 0

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