February 2009 - Glasgow-haskell-users

Re: [Haskell-beginners] Baffled by Parsec
by Colin Paul Adams 22 Feb '09

22 Feb '09

>>>>> "Felipe" == Felipe Lessa <felipe.lessa(a)gmail.com> writes: Felipe> On Sun, Feb 22, 2009 at 4:50 AM, Colin Paul Adams Felipe> <colin(a)colina.demon.co.uk> wrote: >> OK - I see it here, but I was looking in >> Text.ParserCombinators.Parsec.Char, where I can't see it (I can >> see satisfy). I can't see how I am supposed to make that >> apparently disconnected leap (other than by asking here, which >> works :-) ) Felipe> It is there, too! =P Felipe> http://hackage.haskell.org/packages/archive/parsec/3.0.0/doc/html/Text-Pars… Hm. It's not on my local copy of the GHC libraries documentation (ghc 6.10.1), although if I click the source button, I can see it. -- Colin Adams Preston Lancashire

1 0

Compiler optimizations questions for ghc 6.10...
by Tyson Whitehead 21 Feb '09

21 Feb '09

(compiled with ghc 6.10 with options -O2 -ddump-simpl) I was wondering why lvl_s1mF is not being inlined into a_s1Gv in the core at the bottom of this email as that is the only place it is ever referenced. It also seems the extra levels of indirection are defeating the strictness analyzer on eta_s1CN in a_s1Gv as all code branches either directly force it or ultimately pass it to digit_s1l3 as in the included branch. Also, why isn't digit_s1l3 optimized to take its first parameter unboxed? It is strict in its first argument, and grepping the core shows that it is only ever used like in lvl_s1mF (i.e., passed things like lvl_s1mG). Thanks! -Tyson PS: Is there any way to get better control over the loop breaker choice? For a slightly simpler digit function, it is not chosen, and great code is produced. I've tried using INLINE on digit, but that seems to result in the monad bind operator not being inlined, which produces even worse code. . . . letrec { lvl_s1mF :: Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int [Str: DmdType {s1l3->C(S)}] lvl_s1mF = digit_s1l3 lvl_s1mG; . . . a_s1Gv :: GHC.Types.Int -> GHC.Types.Int -> Control.Monad.Error.ErrorT [GHC.Types.Char] Control.Monad.Identity.Identity ((GHC.Types.Int, GHC.Types.Int) GHC.Types.Int) [Arity 2 Str: DmdType U(L)L {a1hP->U(TTTL) s1ka->U(L)}] a_s1Gv = a_s1Gv = \ (eta_a1px [ALWAYS Just U(L)] :: GHC.Types.Int) (eta_s1CN [ALWAYS Just L] :: GHC.Types.Int) -> . . .... GHC.Bool.True -> (((lvl_s1mF `cast` (... ~ GHC.Types.Int -> Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity) (GHC.Types.Int, GHC.Types.Int))) (GHC.Types.I# (GHC.Prim.+# x_a1tl 1))) `cast` (... ~ GHC.Types.Int -> Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity ((GHC.Types.Int, GHC.Types.Int) GHC.Types.Int))) eta_s1CN .... . . . . . digit_s1l3 [ALWAYS LoopBreaker Nothing] :: GHC.Types.Int -> Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int [Arity 1 Str: DmdType U(L)] digit_s1l3 = \ (x_aqR [ALWAYS Just U(L)] ::GHC.Types.Int) -> case x_aqR of x_XsO [ALWAYS Just A] { GHC.Types.I# ipv_s1bt [ALWAYS Just L] -> let { . . . } in (\ (eta_X1sC [ALWAYS Just L] :: GHC.Types.Int) (eta_s1FE [ALWAYS Just U(L)] :: GHC.Types.Int) -> . . . ) `cast` (... ~ Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity)) GHC.Types.Int) . . . } . . . lvl_s1mG :: GHC.Types.Int [Str: DmdType m] lvl_s1mG = GHC.Types.I# 0

5 17

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