- Glasgow-haskell-users

proposal: separate lists for ghc-cvs commits and ghc-dev chatter
by Carter Schonwald 07 Dec '12

07 Dec '12

hey all, It seems to me (and i've certainly heard other people echo this sentiment) that: ghc dev chatting gets buried in the huge volume of commit + build report emails, and that creates (perhaps) another barrier to involvement in ghc dev at the hobbyist (rather than part time/full time ) scale? So my question for the community (and of course current ghc devs ) 1) do others agree that theres value in separating the two? 2) would this just be another use of the ghc-users list or would it be worth having a ghc-dev list? 3) most importantly, would the folks actively involved in ghc dev be willing/able to do so? That said, it does seem like the majority of the interesting ghc-dev chatter is on Trac issues, which is a good thing, though theres lots of interesting wee nuggets buried on the ghc-cvs list intermittently I hope this question makes sense for y'all! -Carter

12 15

GHCI segfault on Double math
by Ron Alford 07 Dec '12

07 Dec '12

I'm trying to see if this is reproducible, or it's just my machine. I'm on a MacBook Pro (15-inch, Mid 2012), OS X 10.8.2, Haskell Platform 2012.4.0.0 (32 bit): $ ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> properFraction (-1.1 :: Float) (-1,-0.100000024) Prelude> properFraction (1.1 :: Double) (1,0.10000000000000009) Prelude> properFraction (-1.1 :: Double) (-1,Segmentation fault: 11 'ceiling' and other code that uses properFraction segfaults on negative doubles, too. Compiled code doesn't have this defect. I'm going to try the 64 bit version to see if it resolves this problem. -Ron Alford

2 1

Emitting constants to the .data section from the NatM monad
by Johan Tibell 07 Dec '12

07 Dec '12

Hi! I'm trying to implement word2Double# and I've looked at how e.g. LLVM does it. LLVM outputs quite clever branchless code that uses two predefined constants in the .data section. Is it possible to add contents to the current .data section from a function in the NatM monad e.g. coerceWord2FP :: Width -> Width -> CmmExpr -> NatM Register ? Cheers, Johan P.S. Given this C code double f(unsigned long long u) { return u; } LLVM generates this rather clever code: .section __TEXT,__text,regular,pure_instructions .section __TEXT,__literal8,8byte_literals .align 3 LCPI1_0: .long 1602224128 // constant we'd like to ouput .long 0 // constant we'd like to ouput .section __TEXT,__text,regular,pure_instructions .globl _f .align 4, 0x90 _f: pushl %ebp movl %esp, %ebp subl $16, %esp movl 8(%ebp), %eax movl 12(%ebp), %ecx movl %ecx, -4(%ebp) movl %eax, -8(%ebp) testl %ecx, %ecx // check sign sets %al // check sign xorb $1, %al // check sign movzbl %al, %eax // 0 if signed fildll -8(%ebp) // load integer fadds LCPI1_0(,%eax,4) // add one of two constants fstpl -16(%ebp) // store and pop fldl -16(%ebp) addl $16, %esp popl %ebp ret

2 3

validate fails: No rule to make target `fast'
by Johan Tibell 07 Dec '12

07 Dec '12

I'm getting this build failure from a: make maintainer clean perl boot; ./configure CPUS=2 sh validate ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final validate_build_transformers cd libraries/transformers && "/Users/tibell/src/ghc/bindisttest/install dir/bin/ghc" --make Setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... cd libraries/transformers && ./Setup configure --with-ghc="/Users/tibell/src/ghc/bindisttest/install dir/bin/ghc" --with-haddock="/Users/tibell/src/ghc/bindisttest/install dir/bin/haddock" --enable-library-vanilla --disable-shared --disable-library-prof --global --builddir=dist-bindist --prefix="/Users/tibell/src/ghc/bindisttest/install dir" Configuring transformers-0.3.0.0... cd libraries/transformers && ./Setup build --builddir=dist-bindist Building transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... [ 1 of 24] Compiling Data.Functor.Product ( Data/Functor/Product.hs, dist-bindist/build/Data/Functor/Product.o ) [ 2 of 24] Compiling Data.Functor.Compose ( Data/Functor/Compose.hs, dist-bindist/build/Data/Functor/Compose.o ) [ 3 of 24] Compiling Data.Functor.Identity ( Data/Functor/Identity.hs, dist-bindist/build/Data/Functor/Identity.o ) [ 4 of 24] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist-bindist/build/Control/Monad/Trans/Class.o ) [ 5 of 24] Compiling Control.Monad.IO.Class ( Control/Monad/IO/Class.hs, dist-bindist/build/Control/Monad/IO/Class.o ) [ 6 of 24] Compiling Control.Monad.Trans.Cont ( Control/Monad/Trans/Cont.hs, dist-bindist/build/Control/Monad/Trans/Cont.o ) [ 7 of 24] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist-bindist/build/Control/Monad/Trans/Error.o ) [ 8 of 24] Compiling Control.Monad.Trans.Identity ( Control/Monad/Trans/Identity.hs, dist-bindist/build/Control/Monad/Trans/Identity.o ) [ 9 of 24] Compiling Control.Monad.Trans.List ( Control/Monad/Trans/List.hs, dist-bindist/build/Control/Monad/Trans/List.o ) [10 of 24] Compiling Control.Monad.Trans.Maybe ( Control/Monad/Trans/Maybe.hs, dist-bindist/build/Control/Monad/Trans/Maybe.o ) [11 of 24] Compiling Control.Monad.Trans.Reader ( Control/Monad/Trans/Reader.hs, dist-bindist/build/Control/Monad/Trans/Reader.o ) [12 of 24] Compiling Control.Monad.Trans.RWS.Lazy ( Control/Monad/Trans/RWS/Lazy.hs, dist-bindist/build/Control/Monad/Trans/RWS/Lazy.o ) [13 of 24] Compiling Control.Monad.Trans.RWS ( Control/Monad/Trans/RWS.hs, dist-bindist/build/Control/Monad/Trans/RWS.o ) [14 of 24] Compiling Control.Monad.Trans.RWS.Strict ( Control/Monad/Trans/RWS/Strict.hs, dist-bindist/build/Control/Monad/Trans/RWS/Strict.o ) [15 of 24] Compiling Control.Monad.Trans.State.Lazy ( Control/Monad/Trans/State/Lazy.hs, dist-bindist/build/Control/Monad/Trans/State/Lazy.o ) [16 of 24] Compiling Control.Monad.Trans.State ( Control/Monad/Trans/State.hs, dist-bindist/build/Control/Monad/Trans/State.o ) [17 of 24] Compiling Control.Monad.Trans.State.Strict ( Control/Monad/Trans/State/Strict.hs, dist-bindist/build/Control/Monad/Trans/State/Strict.o ) [18 of 24] Compiling Control.Monad.Trans.Writer.Lazy ( Control/Monad/Trans/Writer/Lazy.hs, dist-bindist/build/Control/Monad/Trans/Writer/Lazy.o ) [19 of 24] Compiling Control.Monad.Trans.Writer ( Control/Monad/Trans/Writer.hs, dist-bindist/build/Control/Monad/Trans/Writer.o ) [20 of 24] Compiling Control.Monad.Trans.Writer.Strict ( Control/Monad/Trans/Writer/Strict.hs, dist-bindist/build/Control/Monad/Trans/Writer/Strict.o ) [21 of 24] Compiling Data.Functor.Constant ( Data/Functor/Constant.hs, dist-bindist/build/Data/Functor/Constant.o ) [22 of 24] Compiling Control.Applicative.Lift ( Control/Applicative/Lift.hs, dist-bindist/build/Control/Applicative/Lift.o ) [23 of 24] Compiling Control.Applicative.Backwards ( Control/Applicative/Backwards.hs, dist-bindist/build/Control/Applicative/Backwards.o ) [24 of 24] Compiling Data.Functor.Reverse ( Data/Functor/Reverse.hs, dist-bindist/build/Data/Functor/Reverse.o ) In-place registering transformers-0.3.0.0... cd libraries/transformers && ./Setup haddock --builddir=dist-bindist Running Haddock for transformers-0.3.0.0... Preprocessing library transformers-0.3.0.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Haddock coverage: 100% ( 2 / 2) in 'Data.Functor.Product' 100% ( 2 / 2) in 'Data.Functor.Compose' 100% ( 2 / 2) in 'Data.Functor.Identity' 100% ( 8 / 8) in 'Control.Monad.Trans.Class' 100% ( 2 / 2) in 'Control.Monad.IO.Class' 100% ( 14 / 14) in 'Control.Monad.Trans.Cont' 100% ( 15 / 15) in 'Control.Monad.Trans.Error' 100% ( 7 / 7) in 'Control.Monad.Trans.Identity' 100% ( 7 / 7) in 'Control.Monad.Trans.List' 100% ( 9 / 9) in 'Control.Monad.Trans.Maybe' 100% ( 18 / 18) in 'Control.Monad.Trans.Reader' 100% ( 37 / 37) in 'Control.Monad.Trans.RWS.Lazy' 100% ( 2 / 2) in 'Control.Monad.Trans.RWS' 100% ( 37 / 37) in 'Control.Monad.Trans.RWS.Strict' 100% ( 33 / 33) in 'Control.Monad.Trans.State.Lazy' 100% ( 2 / 2) in 'Control.Monad.Trans.State' 100% ( 33 / 33) in 'Control.Monad.Trans.State.Strict' 100% ( 20 / 20) in 'Control.Monad.Trans.Writer.Lazy' 100% ( 2 / 2) in 'Control.Monad.Trans.Writer' 100% ( 20 / 20) in 'Control.Monad.Trans.Writer.Strict' 100% ( 2 / 2) in 'Data.Functor.Constant' 100% ( 6 / 6) in 'Control.Applicative.Lift' 100% ( 2 / 2) in 'Control.Applicative.Backwards' 100% ( 2 / 2) in 'Data.Functor.Reverse' Documentation created: dist-bindist/doc/html/transformers/index.html cd libraries/transformers && ./Setup install --builddir=dist-bindist Installing library in /Users/tibell/src/ghc/bindisttest/install dir/lib/transformers-0.3.0.0/ghc-7.7.20121206 Registering transformers-0.3.0.0... cd libraries/transformers && ./Setup clean --builddir=dist-bindist cleaning... cd libraries/transformers && rm -f Setup Setup.exe Setup.hi Setup.o make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: *** No rule to make target `fast'. Stop. make: *** [test] Error 2 ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. -------------------------------------------------------------------

1 0

Dynamic libraries by default and GHC 7.8
by Ian Lynagh 07 Dec '12

07 Dec '12

Hi all, GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

21 60

The end of an era, and the dawn of a new one
by Simon Peyton-Jones 07 Dec '12

07 Dec '12

Friends You'll have seen Simon Marlow's recent announcement (included below): | Today I'm announcing that I'm leaving Microsoft Research. Simon Marlow and I have worked together on GHC for nearly two decades. During much of that time we have shared a cup of coffee every morning (one cup each, since you ask), to discuss what's going on in GHC-land. We had frequent detailed and illuminating debates about design alternatives. Simon is the absolute master of GHC's code generation, runtime system, garbage collector, support for parallel execution, and much else besides. His sheer programming skill in rooting out obscure and hard-to-reproduce runtime system bugs has always amazed me. He is more than just a great hacker, of course. He is a leader in our community, has a strong publication record, chaired the Haskell Prime committee for a year, and is sought after for tutorials about parallel programming. I owe Simon a great debt, as I think we all do, for the care and skill he has lavished on GHC. He's not going to disappear entirely, but he will be spending much less time on GHC than in the past. That is a change, but it's a change that was always going to happen sometime, and while change is sometimes uncomfortable, it can also open up new possibilities. GHC is over 20, and like my own children (who are actually all a bit younger than GHC), that's not a bad time to start to head out into the world. Over time, more and more people have started to help with the task of developing and maintaining GHC. We'll have to do more of that. These days GHC has a very large "surface area" (running on different platforms, dynamic linking, debugger, profiler, GHCi, libraries and Cabal, etc etc), and has grown far beyond what any single person or research group can manage. Lest you should wonder, I myself will certainly continue to work on GHC. But my job is to be a *researcher*, and I am not well equipped -- in temperament or expertise -- to deal with the myriad complexities of deployment, upgrade policy, portability, and the like. Well Typed (mostly in the guise of Ian Lynagh) will continue to handle some of these issues, but again there is too much for one person to do. So we need your help. Seriously. Rather than just thinking "GHC HQ will sort it out", I would welcome you saying "Shall I take responsibility for X?". Johan, Bryan, and others offering to be GHC Performance Tsars is a great recent example. But don't wait to be asked: just make an offer if you see a gap or an open ticket --- and I think there will be plenty of those. Particularly valuable are offers to take responsibility for a particular area (eg the LLVM code generator, or the FFI). I'm hoping that this sea change will prove to be quite empowering, with GHC becoming more and more a community project, more resilient with fewer single points of failure. I am going to miss that cup of coffee though. Thank you Simon! Facebook is lucky to have you. Onward and upward. Simon (PJ) | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 22 November 2012 11:27 | To: haskell; glasgow-haskell-users(a)haskell.org | Subject: Leaving Microsoft | | Today I'm announcing that I'm leaving Microsoft Research. | | My plan is to take a break to finish the book on Parallel and Concurrent | Haskell for O'Reilly, before taking up a position at Facebook in the UK | in March 2013. | | This is undoubtedly a big change, both for me and for the Haskell | community. I'll be stepping back from full-time GHC development and | research and heading into industry, hopefully to use Haskell. It's an | incredibly exciting opportunity for me, and one that I hope will | ultimately be a good thing for Haskell too. | | What does this mean for GHC? Obviously I'll have much less time to work | on GHC, but I do hope to find time to fix a few bugs and keep things | working smoothly. Simon Peyton Jones will still be leading the project, | and we'll still have support from Ian Lynagh, and of course the | community of regular contributors. Things are in a reasonably stable | state - there haven't been any major architectural changes in the RTS | lately, and while we have just completed the switchover to the new code | generator, I've been working over the past few weeks to squeeze out all | the bugs I can find, and I'll continue to do that over the coming months | up to the 7.8.1 release. | | In due course I hope that GHC can attract more of you talented hackers | to climb the learning curve and start working on the internals, in | particular the runtime and code generators, and I'll do my best to help | that happen. | | Cheers, | Simon

5 7

Does GHC still support x87 floating point math?
by Johan Tibell 06 Dec '12

06 Dec '12

Hi, I'm currently trying to implement word2Double#. Other such primops support both x87 and sse floating point math. Do we still support x87 fp math? Which compiler flag enables it? -- Johan

4 3

Extending GHCi
by Dennis Felsing 06 Dec '12

06 Dec '12

Hi! I'm currently trying to extend ghc-vis[1], a tool to visualize live data structures in GHCi and GHC compiled programs, similar to GHCi's :print and vacuum. I want to show the type of a subexpression visualized in ghc-vis. As types aren't stored in GHC they have to be reconstructed. For this I need read access to internal GHC(i) information, like the type of data constructors. Type reconstruction is already happening inside GHCi's debugger[2]. Another concern is having a feature for binding a subexpression to a GHCi variable, so that it appears in ":show bindings" and can be used within the current GHCi session. To me it seems like neither is currently possible from a program running within GHCi. Therefore I just started an extensible GHCi, called eGHCi[3]. So far it should compile on GHC 7.4.2 and 7.6.1, but does nothing else than the regular GHCi. I took the relevant files to compile my own GHCi binary from the corresponding GHC versions, just as ghci-haskeline[4] did before. In order to get type reconstruction and bindings running I'm planning to provide a function > runInGhci :: GhciMonad a -> IO a which enables programs running in eGHCi to run commands inside the GhciMonad. Another change I'm planning is a function > setupHandler :: Event -> GhciMonad a -> IO () which sets an event handler up to be called whenever the specified event occurs. For now the only event I would need is PostEvaluation, which is evoked after an evaluation occured. I want to use this to update the view of ghc-vis automatically after the user entered a new command on the GHCi command line. My first thought was to define new GHCi commands (like :def) instead of functions, but then only the user could use them, and not the programs running inside of GHCi. Now I'm wondering whether the approaches I have in mind are sensible or if anyone can think of a better way to achieve my goals? Is there a way to extend GHCi without copying some of its source code? Is there a chance of having these features flow back into mainline GHCi once they are properly implemented? Thanks, Dennis Felsing [1] http://felsin9.de/nnis/ghc-vis [2] http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger#TypeReconstruction [3] git clone git://r0q.ath.cx/eghci [4] http://hackage.haskell.org/package/ghci-haskeline

3 2

Generating a C call from a MachOp
by Johan Tibell 06 Dec '12

06 Dec '12

Hi, I'm trying to implement word2Double#, which I represent as a MachOp I call MO_UF_Conv (which is very similar to MO_SF_Conv). On some platform I need to implement this MachOp as a call to a C function. Here's what I did in the PPC backend (PPC/CodeGen.hs) for example: getRegister' dflags (CmmMachOp mop [x]) -- unary MachOps = case mop of MO_UF_Conv from to -> coerceWord2FP from to x coerceWord2FP :: Width -> Width -> CmmExpr -> NatM Register coerceWord2FP fromRep toRep x = do dflags <- getDynFlags (src, src_code) <- getSomeReg x -- This is not the type of register I need! dst <- getNewRegNat (floatSize toRep) targetExpr <- cmmMakeDynamicReference dflags addImportNat CallReference lbl let target = ForeignTarget targetExpr (ForeignConvention CCallConv [NoHint] [NoHint] CmmMayReturn) call_code <- genCCall target [src] [dst] let code' = src_code `appOL` call_code return (Fixed (floatSize toRep) dst code') where lbl = mkCmmCodeLabel primPackageId (fsLit $ word2FloatLabel toRep) This doesn't work. The issue is that to make a C call I need CmmFormals and CmmActuals. I cannot figure out how to get the former, as I need to get hold of a LocalReg, which I don't see any way of creating. I could try to make MO_UF_Conv a CallishMachOp, but then I'll have a more difficult time implementing this MachOp in e.g. the LLVM backend, where I don't want to generate a C call but instead output some instructions. I could use some pointers. Cheers, Johan

1 0

Re: Patch to enable GHC runtime system with thr_debug_p options...
by Joachim Breitner 06 Dec '12

06 Dec '12

Dear Michał, Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb "Michał J. Gajda": > On 12/02/2012 09:20 PM, Joachim Breitner wrote: > >> I noticed that Ubuntu, as well as Debian and original packages come > >> without some variants of threaded debugging binaries. > >> A recent change added of printing a stack trace with -xc option requires > >> using both -ticky and profiling compile options, > >> which in turn forces program to be compiled in a -debug RTS way. > >> Since stack trace looks like indispensable debugging tool, and > >> convenient parallelization is strength of Haskell, > >> I wonder is there any remaining reason to leave beginners with a cryptic > >> error message > >> when they try to debug a parallel or threaded application, and want to > >> take advantage of stack trace? > >> > >> The resulting ghc-prof package would be increased by less than 1%. > >> > >> Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream --- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.000000000 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug # Usually want the debug version ifeq "$(BootingFromHc)" "NO" I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default. Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

3 2