- ghc-devs - Haskell.org

about template haskell's pretty print: 3 % 5 -> 3 / 5
by Yoshikuni Jujo 27 Aug '13

27 Aug '13

Hello! I think it's better that the ghc can read what is printed by pretty printer. Now: pprLit 0 (RationalL 3.5) => 7 % 2 I want: pprLit 0 (RationalL 3.5) => 7 / 2 I'll send patch --- pprLit i (RationalL rat) = parensIf (i > noPrec) $ integer (numerator rat) <+> char '/' <+> integer (denominator rat)

1 0

RE: Haskell platform
by Simon Peyton-Jones 26 Aug '13

26 Aug '13

They [happy,alex] are in <platform>/lib/extralibs/bin now for some reason. The HP installer should have added that to the PATH though. Oh, thank you! I never thought of looking there. The installer didn't add it. Mark, it would be amazingly helpful if http://www.haskell.org/platform/ had clear documentation about this! At the moment * It's hard to find an authoritative list of what's in (a particular version of) HP. I tried the "Comprehensive" link on the HP page, leading to http://www.haskell.org/platform/contents.html, and that did mention Happy and Alex, but in a general kind of way. * I tried "Documentation" which leads here http://lambda.haskell.org/platform/doc/current/start.html, but that doesn't have a list of what's in it. (For the libraries part you can kind-of deduce it from the right hand column of the "libraries" link http://lambda.haskell.org/platform/doc/current/frames.html, but it's pretty indirect. * I couldn't find a list of what executable programs should be installed. * It would be really great to know where those executables live. None of this is hard; maybe just no one has asked. Thanks! Simon From: Niklas Larsson [mailto:metaniklas@gmail.com] Sent: 23 August 2013 02:10 To: Simon Peyton-Jones Subject: Re: Haskell platform Hi! They are in <platform>/lib/extralibs/bin now for some reason. The HP installer should have added that to the PATH though. Niklas 2013/8/23 Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> 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 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2

Configure: gcc problem under mingw/i386
by Niculae Ionita 26 Aug '13

26 Aug '13

Hi all, I'm new to GHC Dev and I'm trying to build GHC 7.7 (the repo is about 9 days old) on a Windows machine with mingw32. I followed the very helpful article for newcomers to GHC dev ( http://ghc.haskell.org/trac/ghc/wiki/Newcomers# ) and up to configure it was easy. Now I get a problem with configure, the last few output lines are: GHC build : i386-unknown-mingw32 GHC host : i386-unknown-mingw32 GHC target : i386-unknown-mingw32 configure: Building in-tree ghc-pwd checking for path to top of build tree... j:/ghc checking for gcc... j:/ghc/inplace/mingw/bin/gcc.exe checking whether the C compiler works... no configure: error: in `/j/ghc': configure: error: C compiler cannot create executables See `config.log' for more details From config.log it's clear that j:/ghc/inplace/mingw/bin/gcc.exe is missing (actually already the bin is missing). My gcc is in /mingw/bin, which is in PATH, but even if I try with the option --with-gcc=/mingw/bin/gcc I get the same error. So I was looking in the configure script and found out that, for mingw32 and i386, gcc must be under $hardtop/inplace/mingw/bin/, and if not, there are commands to unpack all tools from tar files like ghc-tarballs/mingw/binutils*.tar.lzma and a few others. The point is, I don't have the subdirectory ghc-tarballs under my ghc directory. Now, my questions: 1. Are there any reasons to not use the building tools coming from the mingw installation, and use the dedicated ones? 2. Where could I find those tarballs? Did I miss something when updated the repositories? Thanks, Nicu

3 4

Finding definitions made in the current module
by David Luposchainsky 26 Aug '13

26 Aug '13

Hey everyone, I'm having trouble finding a good middle ground between the global and local environments in the typechecker. I would like to get an environment of things that are defined in the current module, but - TcGblEnv includes everything in scope, which is too general. - TcLclEnv is (if I'm right) meant to handle scoping, which is too narrow. The reason for this is that the AMP warnings should be restricted to a single module. In the current implementation, having a module import an AMP-violating module issues a warning from each module using the offender (including that module itself). It does the job, but it's not pretty. David

1 0

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