- Glasgow-haskell-users

Building GHC on Windows
by Felix Martini 23 Feb '09

23 Feb '09

Hi all, Simon Marlow has recently posted a patch that adds Unicode support to Handle I/O. He mentioned that it didn't work yet on Windows so i was thinking of looking at the source code to see how the new Unicode support works and perhaps try to make it work on Windows. I have built GHC from source in the past on Windows and the process was cumbersome compared to building it on Linux. But i was curious to see if it has gotten easier. After reading the Wiki i decided to get the source with Git as Darcs was slow with remote downloads. Ok, that was a lot quicker than before! Let's see, i need to run sync-all to get the core libraries. I remember that i used to use darcs-all so it must be a new script. Sync-all doesn't have an extension so i probably need to run it with msys. That doesn't work, somehow my msys environment does not find git. So let's try the Git Bash environment which also uses msys (and does not have bash). Now i get a cryptic error: "at ./sync-all line 99, <IN> line 19." It seems the script cannot determine the default remote repo. The top line shows that it is a Perl script and i don't know Perl enough to see what is wrong. I have Perl installed on this Windows pc so let's try to run the script directly. That doesn't work either: the Perl script wants to use grep and sed. All this is likely trivial to fix but at the same time these little roadblocks may also explain why few developers on Windows contribute code to GHC and Haskell. Regards, Felix

3 6

DLL support with GHC
by Neil Mitchell 22 Feb '09

22 Feb '09

Hi, What is the current status of shared object support within GHC? Using GHC 6.10.2 (or the branch for it) I can create DLL's under Windows, following these instructions: http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html .Can a similar thing be done under Linux? If so, where is this documented? Many thanks Neil

2 2

Re: [Haskell-beginners] Baffled by Parsec
by Antoine Latter 22 Feb '09

22 Feb '09

On Sun, Feb 22, 2009 at 2:14 AM, Felipe Lessa <felipe.lessa(a)gmail.com> wrote: > > My GHC 6.10.1 was compiled from source and Parsec comes from a > different ebuild (Gentoo), and digit isn't documented as well. It must > be some problem with parsec < 3, because Hackage has the same problem > for old Parsec[1]. > > [1] http://hackage.haskell.org/packages/archive/parsec/2.1.0.1/doc/html/Text-Pa… > >From the sources: > upper, lower, alphaNum, letter, digit, hexDigit, octDigit :: CharParser st Char I think I've seen Haddock have trouble documenting declarations which share a type signature in other places, as well. Antoine

1 0

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