August 2013 - ghc-devs

7.8 Feature window
by Austin Seipp 26 Aug '13

26 Aug '13

All, GHC 7.8's release is drawing near. We would like to make a release candidate sometime around ICFP, which will be in late September. Unfortunately that's just over a month a way, so the clock is ticking! The tree will need a few weeks of stabilization. After that, we will release an RC, and likely branch. Then things will roughly return to normal. The exact date for feature cutoff is not set yet (but I will follow up soon on this.) So, I'd like a show of hands and a quick 'check in' for outstanding work for 7.8. There are a few things we know for sure are - or were - tentatively scheduled for this release: * SIMD improvements * New Template Haskell * Constraint solver for type naturals These are - as far as I'm aware - the largest outstanding features which not quite yet in HEAD. For the release, we would like to minimize 'disruptive' features, because 7.8 already has many large changes. In particular, Dynamic GHCi and dynamic builds will likely prove the biggest challenge 'in the field', so we would like plenty of time to stress this as best we can for the RC, and the release itself. There are some things which we are fairly certain will not make it: * Joachim's new newtype coercion implementation * Adam's new record implementation There are some things I'm not very privvy to perhaps, but could still go in: * Nicolas possibly had some optimisation improvements according to Simon. * Edsko had a small patch for extended plugin functionality in HEAD, but Luite and Thomas also have input here. Status is uncertain. * ERDI was working on pattern synonyms. I believe you were having some trouble with the implementation. Can someone help him if necessary? Finally, there are loose ends to tie off: * I believe Simon and Jose were having discussions about the new Typeable implementation, regarding hand-written instances. This should be fine for 7.8 and is mostly some behavioral tweaking I think. I've undoubtedly missed things here. Please fill me in. :) Note that before the freeze, you should interpret 'disruptive' with your own good judgement. Smaller patches and improvements are certainly welcome as always, and you shouldn't wait on me to push something if you feel good about it. If you're ever unsure, just ask. Worst case is something gets backed out, but it's nothing we cannot come back to. -- Regards, Austin - PGP: 4096R/0x91384671

13 36

It's one of those days...
by Ben Lippmeier 26 Aug '13

26 Aug '13

From a fresh ghc-head checkout. On OSX Lion ------------------------------------------------ $ ./sync-all get ... == libraries/dph: running git config --local core.ignorecase true == running git config --local core.ignorecase true == running git submodule init == running git submodule update error: Failed connect to git.haskell.org:3128; Operation timed out while accessing http://git.haskell.org/packages/Cabal.git/info/refs?service=git-upload-pack fatal: HTTP request failed Unable to fetch in submodule path 'libraries/Cabal' git failed: 256 at ./sync-all line 119. ------------------------------------------------ On OSX Snow Leopard ------------------------------------------------ $ make ... ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes Binary Bitmap BlockId BreakArray BufWrite ByteCodeAsm ByteCodeInstr ByteCodeItbls ByteCodeLink CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC ... TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet" make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault make: *** [all] Error 2 ------------------------------------------------ On Debian ------------------------------------------------ $ inplace/bin/ghc-stage2 --make ~/tmp/Hello.hs -fforce-recomp ... (.data+0x0): undefined reference to `r5Iv_closure' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__40.o):(.text+0x85): undefined reference to `rjV_info' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__40.o): In function `S82I_srt': (.data+0x0): undefined reference to `rjV_closure' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__42.o):(.text+0x85): undefined reference to `rjV_info' /home/benl/devel/ghc/ghc-head/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(PSQ__42.o): In function `S83p_srt': ------------------------------------------------ I'm sure it's my fault, but I don't have any more computers... Ben.

4 5

(in-place) mutable unboxable Ints (was: [GHC] #8158: Replace IO manager's IntMap with a mutable hash table)
by Herbert Valerio Riedel 25 Aug '13

25 Aug '13

Hello Simon, On 2013-08-24 at 08:54:20 +0200, GHC wrote: [...] > Comment (by simonmar): > > @bos: GHC has a `FastMutInt` type for this purpose, which is a 1-element > mutable unboxed array. I'd be interested to know whether performance > differs between this and `ForeignPtr`. > > source:ghc/compiler/utils/FastMutInt.lhs One thing I have been wondering about: ...even with FastMutInt, which is defined as data FastMutInt = FastMutInt (MutableByteArray# RealWorld) If I have a hypothetical data structure, data IoStats = IoStats { sBytesRecv :: {-# UNPACK -#} !FastMutInt , sBytesSent :: {-# UNPACK -#} !FastMutInt , sPacketsRecv :: {-# UNPACK -#} !FastMutInt , sPacketsSent :: {-# UNPACK -#} !FastMutInt } Then (if have the numbers right) each instance of IoStats takes 1 word for the IoStats info-ptr, plus 1 word for each unpacked FastMutInt (which is basically reduces to pointer to a MutableByteArray#), and 3 words for each MutableByteArray# as those result in separate heap objects; that is, a total of 17 words needs to be allocated to keep track of 4 counters. The overhead could be improved somewhat, if I used a 4-word-long MutableByteArray (which would still be a separate heap object and thus result in a single 3-word overhead), but the data declaration would be less expressive IMHO. Would it be possible (w/ reasonable effort) to have an unpackable version of FastMutInt which only has a total storage cost of 1 word (when unpacked), so that IoStats would have a total storage cost of 5 words (and no indirections)? Or even just a new unboxed primitive MutInt# type in the style of Int#, so that FastMutInt would be defined similiar to 'Int' as data FastMutInt = FMI# MutInt# ? PS: The FastMutInt API doesn't seem to provide atomic decrements/increments, what would be needed to provide that? Cheers, hvr

2 1

Re: Getting rid of HEAP_ALLOCED
by Simon Marlow 25 Aug '13

25 Aug '13

On 24/08/13 23:08, Edward Z. Yang wrote: > Part of the resource limits work needs to access the bdescr for a thunk > when it is entered. Of course, right now, this needs to go through > HEAP_ALLOCED; I imagine this would way to slow to put into the generated > code. So I happened across this page describing some previous efforts > to get rid of the HEAP_ALLOCED check: > > http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced > > So I'm currently implementing method 2, and I'm wondering what the best > way to setup the indirection table might be: maybe some sort of > null-terminated array? What's the proper way for the linker to figure > out where the indirection table lives? Getting rid of HEAP_ALLOCED would be wonderful! And I'm really glad I wrote that wiki page, I had completely forgotten about those ideas. It seems to me that what we want to do at starting is like a GC: we traverse all the static objects copying them to a new area and updating all the internal pointers at the same time. You can arrange that all the indirections end up next to each other by putting them in a special section. Then you can traverse the contents of the section so long as you have a symbol at the beginning and the end, or something like that. There are other ways to do it, such as having the module initialisation code register something with the RTS. It pains me to have to use this solution when what we really ought to do is memory-mapping tricks to put the static objects where we want them. Cheers, Simon

1 0

Re: [commit: ghc] master: Update email addresses (cbe3dba)
by Herbert Valerio Riedel 24 Aug '13

24 Aug '13

Hello Gabor, On 2013-08-22 at 22:51:31 +0200, git(a)git.haskell.org wrote: > Link : http://ghc.haskell.org/trac/ghc/changeset/cbe3dba89c085f7556fe32126381dac68… > commit cbe3dba89c085f7556fe32126381dac68d93dd8b > Author: Gabor Greif <ggreif(a)gmail.com> > Date: Mon Aug 19 11:31:15 2013 +0200 > > Update email addresses in the diff chunks below, shouldn't mail be rather sent to the ghc-devs(a)haskell.org list? [...] > diff --git a/compiler/vectorise/Vectorise/Builtins/Base.hs b/compiler/vectorise/Vectorise/Builtins/Base.hs > index 0cb4bbb..bcd85cb 100644 > --- a/compiler/vectorise/Vectorise/Builtins/Base.hs > +++ b/compiler/vectorise/Vectorise/Builtins/Base.hs > @@ -194,7 +194,7 @@ indexBuiltin fn f i bi > text "' is not yet implemented." > , text "This function does not appear in your source program, but it is needed" > , text "to compile your code in the backend. This is a known, current limitation" > - , text "of DPH. If you want it to work, you should send mail to cvs-ghc(a)haskell.org" > + , text "of DPH. If you want it to work, you should send mail to ghc-commits(a)haskell.org" > , text "and ask what you can do to help (it might involve some GHC hacking)."]) > where xs = f bi > > @@ -213,5 +213,5 @@ lookupEnvBuiltin fn env n > text "' is not yet implemented." > , text "This function does not appear in your source program, but it is needed" > , text "to compile your code in the backend. This is a known, current limitation" > - , text "of DPH. If you want it to work, you should send mail to cvs-ghc(a)haskell.org" > + , text "of DPH. If you want it to work, you should send mail to ghc-commits(a)haskell.org" > , text "and ask what you can do to help (it might involve some GHC hacking)."]) [...]

2 1

Haddock panic
by Jan Stolarek 24 Aug '13

24 Aug '13

I am working on improving new comparison primops and implementing Geoffrey's proposal [1]. I renamed GHC.Prim to GHC.Prim.BuiltIn and GHC.PrimWrappers (in ghc-prim library) to GHC.Prim. I can build the compiler and testsuite passes succesfully, but ./validate fails with 'haddock panic' when building documentation for ghc-prim library: Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' haddock: internal error: haddock: panic! (the 'impossible' happened) (GHC version 7.7.20130823 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Have any of you ever broke haddock in a similar way? Looks as if GHC session was not initialized properly, but I have no idea how could I have triggered such a behaviour. Janek [1] - http://www.haskell.org/pipermail/ghc-devs/2013-August/002072.html

1 0

Can't make libffi
by Mateusz Kowalczyk 23 Aug '13

23 Aug '13

Trying to build HEAD I get. "inplace/bin/ghc-stage1@exeext_host@" -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.dyn_o "inplace/bin/ghc-stage1@exeext_host@" -fPIC -dynamic -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.dyn_o "inplace/bin/ghc-pkg@exeext_host@" --simple-output field rts extra-libraries \ | sed -e 's/$[^ ][^ ]*$/-l\1/g' > rts/dist/libs.depend "inplace/bin/ghc-pkg@exeext_host@" --simple-output field rts library-dirs \ | sed -e 's/$[^ ][^ ]*$/-L\1/g' >> rts/dist/libs.depend make[1]: *** No rule to make target `libffi/build/inst/lib/libffi@soext_target@', needed by `rts/dist/build/libffi@soext_target@'. Stop. make: *** [all] Error 2 I know there is some repository moving shenanigans going on at the moment so I am not sure whether that's something to look out for. All I did was ./sync-all get and then ./sync-all pull without changing anything – I have the same setup as I did couple of weeks ago. -- Mateusz K.

2 7

Building on windows
by Simon Peyton-Jones 23 Aug '13

23 Aug '13

I've got a new Windows laptop, and have being having a torrid time getting GHC to build on it. 1. Build falls over with checking for gcc... c:/code/HEAD/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables Turns out that an earlier error was configure: Making in-tree mingw tree tar (child): ../../ghc-tarballs/mingw/binutils*.tar.lzma: Cannot open: No such file or directory tar (child): Error is not recoverable: exiting now tar: Child returned status 2 tar: Error is not recoverable: exiting now ./configure: line 4050: inplace/mingw/bin/realgcc.exe: No such file or directory configure: In-tree mingw tree created configure: Making in-tree perl tree BUT this error was not fatal, so the build went on (notwithstanding the red message above), leading to a MUCH more obscure error later. 2. Why wasn't ghc-tarballs there? Oh, apparently you have to say sync-all -windows get That's really hard for a naïve user to work out. Can't we either always get it, or work out that we are on windows? 3. I carefully installed mingw/msys as described on http://www.mingw.org/wiki/Getting_Started I used mingw-set-inst, which launches a GUI for a package installer. All seems well. I update my path. But then Can't locate Autom4te/ChannelDefs.pm in @INC (@INC contains: /mingw/share/autoco nf /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_ perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) a t /c/Programme/MinGW/bin/autoreconf-2.68 line 40. BEGIN failed--compilation aborted at /c/Programme/MinGW/bin/autoreconf-2.68 line 40. After a long struggle I found that I had missed a crucial thing. With the new autoconf tools, it's essential that c:/mingw be mounted as /mingw, because /mingw is hard-coded into autoconf perl scripts. http://www.mingw.org/wiki/Getting_Started does say (deep in the middle) to edit c:/mingw/msys/1.0/etc/fstab with a text editor, but that appeared to have no effect for me. Saying "mount c:/mingw /mingw" did work. I have no idea why. What is horrible is how uninformative the error message is. I guess we should update the Windows build instructions. I still don't know if I've bottomed out here because I can't find Happy/Alex in the Haskell platform. Sigh. Simon

3 3

RE: concrete syntax for role annotations
by Simon Peyton-Jones 23 Aug '13

23 Aug '13

(Adding ghc-devs, who will, I hope, have opinions) I'm sympathetic to this. In general our story for pragmas {-# blah #-} is that they affect only optimisation (eg INLINE) or warnings (eg DEPRECATED). You can ignore/leave them out. But here you really can't. Well, I suppose leaving out the annotation does not risk soundness (as in run-time seg-fault); it just risks sets being ordered wrong. I don't have a strong opinion here. You could also imagine other syntaxes e.g. data Set a(role N) = ... I suppose. You are right that we need to get this nailed for 7.8, so we don't end up changing it later. Simon From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 23 August 2013 05:52 To: Simon Peyton-Jones; Dimitrios Vytiniotis; Stephanie Weirich Subject: concrete syntax for role annotations Hi all, On a Reddit discussion of my recent blog post on roles (http://www.reddit.com/r/haskell/comments/1kgivs/roles_a_new_feature_of_ghc_…) it was suggested that a better syntax is available for specifying role annotations. Currently, I've implemented > data Set a@N = ... to mark Set's parameter's role as N. The suggested syntax is > data Set a {-# ROLE N #-} = ... This suggested syntax is certainly much more verbose, but it's fully backwards-compatible, avoiding the need for preprocessing statements in libraries. These annotations should hopefully be few and far between, and I just think it's worth considering the backwards-compatible syntax before 7.8 is released and we're stuck. What do we think? Should I forward the question to glasgow-haskell-users, perhaps? Richard

1 0

Haskell platform
by Simon Peyton-Jones 22 Aug '13

22 Aug '13

Urk. The Haskell Platform claims to include Happy and Alex. http://www.haskell.org/platform/contents.html But 2013.2.0.0 doesn't. Is that intentional? That's a big problem for people using HP to build GHC. I'm installing 2012.4.0.0 in the hope that it does. No, nor does 2012.2 Am I just being stupid here? Simon

2 1