- ghc-devs - Haskell.org

RC timeline for 7.8 REDUX
by Carter Schonwald 27 Dec '13

27 Dec '13

Hey Everyone, what is the set of tasks left before we can do a 7.8 RC? Is it there are some serious bugs that have been left unaddressed? Is there anything preventing us from doing an RC sometime in the next two weeks? I understand certain type system related problems have been getting a bit of polish over the past month or so, but if thats the blocker I'd like to know so that when people ask I can point to a concrete reason. I can only speak for myself, but theres been a pretty painful communication gap about whats left before we hit RC, and whenever someone asks me "when is 7.8 coming out, and how can i help make it happen on time?", I can only reply with "no one knows" and "do stuff". that said, happy holidays and preemptive happy new years to everyone! -Carter

2 2

GeneralizedNewtypeDeriving regression in HEAD?
by Nathan Howell 27 Dec '13

27 Dec '13

I can't file a trac ticket at the meny but wanted to see if this is a bug... This is an excerpt from llvm-general that compiles on 7.6.3 but doesn't without ImpredicativeTypes enabled on HEAD: https://gist.github.com/NathanHowell/8138977 thanks, -n

2 1

My first patch
by Krzysztof Langner 25 Dec '13

25 Dec '13

Hello, Since I'm new here I will first introduce myself. My name is Krzysztof and I have more then 20 years experience with object oriented languages. Recently I learned about functional programming. And I really like it. Because my current project uses OO languages (no FP) I decided to try to engage with GHC development to learn Haskell. So here is my first patch. It is related to the ticket: https://ghc.haskell.org/trac/ghc/ticket/5412 I just changed error message so it should be easier (I hope) to understand what has happened. No functionality was changed. The patch is attached to the ticket. Should I submit it to someone to review? -- Thanks Krzysztof Langner

2 2

Help needed: adding pattern synonym support to Haddock
by Dr. ERDI Gergo 20 Dec '13

20 Dec '13

Hi, I've started looking at adding pattern synonym support to Haddock (as part of #5144), but I've realized that pattern synonyms are different enough from other, existing declarations that are processed by Haddock that I'd like to discuss it first. Who would be 'the Haddock guy' to talk to? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' Duct tape is like the force; it has a light side and a dark side, and it holds the universe together.

2 1

Building GHC in a small amount of memory, in parts.
by Aaron Friel 19 Dec '13

19 Dec '13

I am trying to build GHC-HEAD and produce a reliable Dockerfile (see: docker.io) to allow others to use GHC-HEAD and also to make my own build process more reliable. I would like advice/assistance on two things to help this. For reference, I am using the stackbrew/ubuntu:13.10 image as my starting point, and bootstrapping GHC to HEAD using the current GHC (7.6.x) in Ubuntu's repositories. First issue: I am having issues with constraining the resource consumption during the build and have resorted to a few hacks such as replacing ld with gold (or rather, a script that filters out --hash-size arguments) and a custom build.mk file that uses -fasm for stage1. I would also like the final (stage 2?) result to be compiled with llvm, perhaps even without requiring gcc installed at all. How can I continue to push down the resource requirements of a build, and end up with a GHC that represents the bleeding edge? (That is what I want to be testing against, finding bugs for, etc.) Here is my build.mk: ################## BUILD.MK # Default to a very fast build for compilation and stage1: SRC_HC_OPTS = -H64m -O0 GhcStage1HcOpts = -O -fasm # But then use perf-llvm settings for remaining settings: GhcStage2HcOpts = -O2 -fllvm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 -fllvm -XGenerics GhcLibWays += p DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO # Disable building all docs HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO ################## BUILD.MK Second issue: These seem to bring memory usage down, but the monolithic ".\make" command is difficult to debug and very time consuming. When building a container image from a Dockerfile, the commands used are cached so that subsequent attempted builds use the intermediate results. So, even though my Dockerfile starts out with "apt-get update; apt-get upgrade -y", I don't have to do that every time I retry my build. Currently my Dockerfile pulls all the requisite packages from Ubuntu's repos, downloads and builds the latest cabal-install and builds alex, happy, hscolour and haddock, gets the ghc repo from GitHub, does "perl boot" ".\configure" and then I hit a wall with the monstrous amount of work that ".\make" does. I have tried splitting it up by doing ".\make stage=1", ".\make 1", and various combinations, but I hit dependency issues. Is there a way to break up the build into multiple commands?

1 0

eqExprX - dead code?
by Joachim Breitner 17 Dec '13

17 Dec '13

Hi, I came across some seemingly dead code, but I’d like to ask here before I clean it up. (Generally, cleaning up dead code is desirable, right?) The function eqExprX takes a parameter id_unfolding_fun which allows it to look through variable unfoldings. But the only use of this fuction is in eqExpr, which passes "const noUnfolding". Therefore, the two fancy cases in lines 1351-1362 never apply: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/coreSyn/CoreUtils.lhs#l1… Some archeology: In Dec 2010, SPJ removed a use of eqExprX from the CSE module, which made use of that parameter (aae915d6). Thinking about it, it is probably safe to clean up the code. And if not, I’m not going to be offended by a "git revert", but just doing the change instead of waiting for permission seems to be more efficient to me. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 0

arm-apple-darwin10-cabal install woes
by Schell Scivally 16 Dec '13

16 Dec '13

Hi all, I posted this earlier to the haskell-iphone list and heard it may be better off here. I'm having trouble installing primitive from hackage with arm-apple-darwin10-cabal. It seems a funky error is happening that is not getting written out or logged. Here is the output from my attempted install from hackage after a `rm -rf ~/.cabal` and `arm-apple-darwin10-cabal update`: http://lpaste.net/97092. Nothiing is listed in the log mentioned. So I tried installing from the git repo and got the same error. Then I tried to configure build and then install and the build phase spat out: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive library: dist-arm/build/libHSprimitive-0.5.2.0.a will be fat and ar(1) will not be able to operate on it In-place registering primitive-0.5.2.0... So it seems it's building but not linking? Maybe I shouldn't be developing with cabal? What's the normal procedure here? -- Schell Scivally http://blog.efnx.com http://github.com/schell http://twitter.com/schellsan

1 0

Using features from containers-0.5
by Joachim Breitner 16 Dec '13

16 Dec '13

Hi, especially to Austin with his Release Manager hat on, in my nested-cpr branch I have a few nice patches that clean up, refactor and especially Note’ify the demand analyzer. I’d like to see both my branch to be shorter, and to see those improvements in the mainline independent of whether nested-cpr will turn out to be useful, so I invested some time to rebase my branch and move all these patches below those that actually change the code. The result is the contents of the wip/nested-cpr branch up to and including the patch “Make types of bothDmdType more precise”, which I find especially useful (currently c26d31, but I tend to rebase while I add more polish or remove typos). I am confident that this is a pure refactoring (validate passes without changes to the testsuite, nofib shows identical Allocation numbers), and I’d like to push this to master. But one of the patches, “Clarify the default demand on demand environments” (currently 2b6a6a), uses a function from containers (IntMap.mergeWithKey) which was only added in containers-0.5, which ships with GHC 7.6, but not with 7.4. But especially that change is nice, as removes the confusing modifyEnv function and makes the code (IMHO) easier to understand. What is the policy here? Is it ok to expect the user to upgrade the containers package of the bootstrap compiler? Or can we start building containers before stage-1, so that we can expect the new code (but when I tried it seems that this needs some adjustments to the build system)? Or should I add an alternative definition via CPP in compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until 7.9 (which would then drop the requirement to be bootstrappable with 7.4, right?) Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 2

Ways issues with GhcDynamic=YES
by Ben Gamari 15 Dec '13

15 Dec '13

I've spent much of the day trying to determine the root cause of, ... "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc" "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214/bin/ghc-pkg" "/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214" '' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8/lib/ghc-7.7.20131214' '/opt/exp/ghc/root-ghc-llvm-dyn-7.8/share/doc/ghc/html/libraries' NO ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") I'm attempting to produce a build to validate dynamic linking with LLVM so build.mk looks something like, DYNAMIC_BY_DEFAULT = YES BuildFlavour = quick-llvm Looking at the interface files produced for ghc-prim, it seems that ghc-cabal is looking for the wrong extension, $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist-install/build/GHC/CString.hi | grep --after-context=1 Way Way: Wanted [d, y, n], got [] $ inplace/bin/ghc-stage2 --show-iface libraries/ghc-prim/dist-install/build/GHC/CString.dyn_hi | grep --after-context=1 Way Way: Wanted [d, y, n], got [d, y, n] Any ideas what might be going on here? How is `ghc-cabal` supposed to know which interface file to use? Cheers, - Ben

1 0

Cross-Compiler: Windows-to-iOS
by Alex Carter 13 Dec '13

13 Dec '13

Hello, ghc-devs! This is continuation of a conversation from the iphone list, but since it seems to be more of a general cross-compilation issue, I'll toss it up for you guys. (See the conversation history below if you're curious.) The gist is that I'm trying to build a Windows-to-iOS cross-compiler, and since I imagine this isn't something done very often, I've hit a few bumps along the way. First up, gcc (4.5.2, inplace/mingw/bin) really doesn't seem to like rts/Task.h:283, complaining "error: aggregate value used where an integer was expected." For this configuration, presumably OSThreadId is pthread_t and TaskId is uint64, so I'm not sure why it doesn't like the casts. I worked around with return *( (TaskId*) ( (size_t*) &taskID ) ); Last night I was stuck on compiling some automatically generated headers that come out of the deriveConstants utility, and as best I can gather, it generates a header that is (marginally) dependent upon the platform on which it's currently running by using System.Info.os, but the compilation that uses the header seems to be expecting it to work for the target (runtime, maybe?). I added an "os" switch to deriveConstants rather than using System.Info.os and passed the target OS through in includes/ghc.mk where it's invoked. So that seems to fix my issues with StgAsyncIOResults (Windows-only, right?) but I have no idea if these hacks make any sense in the big picture, or if the compiler will even work once I finish the build... Presently I'm stuck on something I expected to be rather straightforward: "Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM." The iOS toolchain I'm using is in my PATH, and both "llc -version" and "opt -version" work as expected in my shell. I'm curious if it's because of the odd version number: $ llc -version LLVM (http://llvm.org/) LLVM version 3.3svn ... Is ./configure perhaps getting caught up on the "svn" and treating this as a failure of version detection? I haven't been able to find a way to manually override the configuration and specify the LLVM paths. Any help is appreciated so I can get back to writing Haskell instead of build debugging. ;) Thanks, Alex On Wed, Dec 11, 2013 at 12:27 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > Yes, this is correct. ghc_boot_platform describes the platforms for the > stage 1 compiler (assuming you're looking at the one in compiler/stage1). > ghcplatform.h describes the platforms in use for compiled code, so the host > in that case is ios. In fact ghcplatform.h shouldn't have a target platform > at all - the only reason it does is for "backwards compatibility", though I > don't remember exactly what goes wrong if we remove these. > > Cheers, > Simon > > > On 11/12/2013 00:08, Alex Carter wrote: >> >> I'm on an interesting journey building a GHC cross-compiler on Windows >> to target iOS, using a third-party iOS toolchain for Windows >> (http://www.pmbaty.com/iosbuildenv/ for the curious), and I'm running >> into an unusual issue. Since this is a cross-compiler, this should be >> all stage 1, so in ghc_boot_platform.h I see what I expect: >> >> ... >> #define BUILD_OS "mingw32" >> #define HOST_OS "mingw32" >> #define TARGET_OS "ios" >> ... >> >> but ghcplatform.h shows: >> >> ... >> #define BUILD_OS "mingw32" >> #define HOST_OS "ios" >> ... >> #define TARGET_OS "ios" >> ... >> >> which I understand to mean that whatever's happening there is set up >> for the stage 2 compiler (unless there's some good magic happening >> here with the deriveConstants utility?). I discovered this through a >> pragma added at the error site: >> >> ... >> rts/Task.h:280:9: note: #pragma message: HOST_OS=ios >> rts/Task.h:287:5: error: aggregate value used where an integer was >> expected >> ... >> >> Anybody know what's going on here? Is it right (for some reason beyond >> my current comprehension) for ghcplatform.h to have the #defines it >> does? Is HOST_OS=ios correct, but rts/Task.h:280 should also check >> defined(ios_HOST_OS)? >> >> Thanks for the help, >> Alex >> >> >> >> _______________________________________________ >> iPhone mailing list >> iPhone(a)haskell.org >> http://www.haskell.org/mailman/listinfo/iphone >> >

1 0