October 2013 - ghc-devs

XCode 5
by Kazu Yamamoto 27 Oct '13

27 Oct '13

Hi all, To check ticket #8139, I'm wondering whether or not I should install XCode 5 to my MacBook Air. I heard that GCC will be removed if XCode 5 is installed. I also heard that if we modify "lib/settings" of GHC 7.6.3, GHC 7.6.3 can work with clang. So, my question: how can I build GHC head with clang? Is "make maintainer-clean; perl boot; ./configure" just enough? Does "configure" automatically find clang and use it if GCC does not exist? --Kazu

2 3

Re: Wither Haskell Platform 2013.4.0.0
by Mark Lentczner 26 Oct '13

26 Oct '13

It wasn't my intention to open up the whole question of scheduled releases. HP has a regular release schedule, and there were many good discussions leading up to it. As for the timing of those releases, last time we looked into this there was no good release time that worked for all the common Linux distro's release schedules. Perhaps GNOME has figured this one out - they release stable end of September and end of March. We could aim to glide toward that. Back to this release: GHC 7.8 won't be ready for inclusion in an HP for quite some time. We haven't even seen the first release yet! If it has stabilized by end of February, then it could make it into the next HP (assuming we don't move the schedule up to match GNOME). But I think realistically, one shouldn't expect a GHC 7.8 as part of an HP release until 2014.4.0.0. *[Aside: If the community wants to see closer tracking, then we probably need to start talking about a different way of producing GHC - with both stable and experimental releases happening... when this idea has been raised in the past, GHC central hasn't had the person-power to do it.]* * * The next Mac OS X is indeed right around the corner (no official date from Apple, just "this Autumn") - the GM release candidate of both OS X Mavericks and Xcode 5 are already in developers (and my) hands. My understanding is that current HP just won't work on it - which means we really should get something out to support it. SO, back to concrete ideas: *A) Minor release* *• Minor rev:* since GHC and most packages haven't changed, and we won't be adding anything, just roll it as normal now. *• Bump for Mac:* immediately after, roll HP 2013.4.1.0 which has GHC 7.6.3 + patches (perhaps named 7.6.4?), so this works w/Xcode 5 *—or—* *B) Delay release* *• New packages:* running the normal process, just a month late *• Bump for Mac: *get GHC central to put out 7.6.4 which has what is needed to support Xcode 5 *—or—* *C) Skip a release* *• Go for 7.8:* push everyone (GHC central, library maintainers) to get 7.8 stable ASAP *• Big Push for Packages:* use the time to push for a significant increase in the packages in the Platform *• Release in March: *aiming to sync with GNOME, assuming they're on to something! As attractive as some aspects of C are, it leaves anyone with a Mac out in the cold for six months: They either can't upgrade, or can't Haskell. A requires duplicate effort (mostly on my part), but is otherwise mechanical... and not that exciting. B deviates from our schedule, but if GHC can roll a 7.6.4, might get us an HP with some new packages. — Mark

5 8

segfault
by Kazu Yamamoto 26 Oct '13

26 Oct '13

Hi, I cannot build GHC head on Linux today: "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name random-1.0.1.1 -hide-all-packages -i -ilibraries/random/. -ilibraries/random/dist-install/build -ilibraries/random/dist-install/build/autogen -Ilibraries/random/dist-install/build -Ilibraries/random/dist-install/build/autogen -Ilibraries/random/. -optP-include -optPlibraries/random/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package time-1.4.1 -O2 -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -odir libraries/random/dist-install/build -hidir libraries/random/dist-install/build -stubdir libraries/random/dist-install/build -dynamic-too -c libraries/random/./System/Random.hs -o libraries/random/dist-install/build/System/Random.o -dyno libraries/random/dist-install/build/System/Random.dyn_o Segmentation fault --Kazu

2 2

_SC_PHYS_PAGES
by Kazu Yamamoto 26 Oct '13

26 Oct '13

Hi Ben, Cc: ghc-devs, I'm trying to build GHC head on OS X Mavericks with Xcode 5. 72f8b8d694362890a424f5fa21fef37cee921ecf introduced _SC_PHYS_PAGES. "man 3 sysconf" of OS X says that _SC_PHYS_PAGES exists. But actually I cannot find it in unistd.h. This is one of the problems which I hit up on now. Would you suggest me any workarounds? --Kazu

1 0

Turning ForceSpecConstr/NoSpecConstr into pragmas?
by Austin Seipp 25 Oct '13

25 Oct '13

Hello all, Early last week I was reminded of something, which was that vector/dph depend on the stage2 compiler - this is because both packages use annotations to specify ForceSpecConstr and NoSpecConstr on several key datatypes. For most of our platforms (now including ARM,) this should generally be OK, because we have stage2 and the linker available to support it. But in particular, it makes vector and dph unusable for cross compilers. This might be somewhat problematic for e.g. iOS or an RPi, where we only have a stage1 cross compiler - but it's reasonable to assume we may want to use vector there! And more and more libraries depend on vector these days. I believe these are the only instances in which vector/dph needs stage2. So I ask: is it reasonable to change this to a pragma built into the compiler? That is, ------------------------------------------------------------ data SPEC = SPEC | SPEC2 {-# ANN type SPEC ForceSpecConstr #-} data PArray a = PArray Int# (PData a) {-# ANN type PArray NoSpecConstr #-} ------------------------------------------------------------- becomes something like: ------------------------------------------------------------- data SPEC = SPEC | SPEC2 {-# SPECIALIZE Constructor SPEC #-} data PArray a = PArray Int# (PData a) {-# NOSPECIALIZE Constructor PArray #-} ------------------------------------------------------------- I'm not particularly interested in a bikeshedding discussion about the exact syntax for the pragma (although this somewhat falls in line with 'INLINE ConLike' as a special case,) - I just want to know if this sounds reasonable. Looking at SpecConstr in the compiler, there seems to be quite a lot of note summarising that we need a better design - in particular, notes about nuking NoSpecConstr (as it appeared before ForceSpecConstr,) and turning ForceSpecConstr into a library type of some sort. I don't propose changing any of this really, just removing the dependency on the annotations. But if someone thinks a library type would be better suited for this - I'm totally fine with that too and am all-ears for a suggestion. And of course, both of these can continue to be supported for a while, although the patches to vector, at least, would be trivial to switch it over. Ben, Manuel, Simon - you three are the experts here I believe. Thoughts? Perhaps I'm missing something key here? -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 14

RE: [commit: packages/ghc-prim] master: Add actual documentation for new SPEC type. (8822cfc)
by Simon Peyton-Jones 25 Oct '13

25 Oct '13

Austin, I think this needs a pointer to this in the user manual. I wouldn't look in GHC.Types when fiddling with SpecConstr! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 25 October 2013 15:34 | To: ghc-commits(a)haskell.org | Subject: [commit: packages/ghc-prim] master: Add actual documentation | for new SPEC type. (8822cfc) | | Repository : ssh://git@git.haskell.org/ghc-prim | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/8822cfce44a3197f6f418563723c9c | c4760e8db9/ghc-prim | | >--------------------------------------------------------------- | | commit 8822cfce44a3197f6f418563723c9cc4760e8db9 | Author: Austin Seipp <austin(a)well-typed.com> | Date: Fri Oct 25 09:33:49 2013 -0500 | | Add actual documentation for new SPEC type. | | Signed-off-by: Austin Seipp <austin(a)well-typed.com> | | | >--------------------------------------------------------------- | | 8822cfce44a3197f6f418563723c9cc4760e8db9 | GHC/Types.hs | 8 +++++++- | 1 file changed, 7 insertions(+), 1 deletion(-) | | diff --git a/GHC/Types.hs b/GHC/Types.hs | index 0e03143..4f97215 100644 | --- a/GHC/Types.hs | +++ b/GHC/Types.hs | @@ -155,5 +155,11 @@ isTrue# x = tagToEnum# x | -- you're reading this in 2023 then things went wrong). See #8326. | -- | | --- | Lorem ipsum... | +-- | SPEC is used by GHC in the @SpecConstr@ pass in order to inform | +-- the compiler when to be particularly aggressive. In particular, it | +-- tells GHC to specialize regardless of size or the number of | +-- specializations. However, not all loops fall into this category. | +-- | +-- Libraries can specify this by using 'SPEC' data type to inform which | +-- loops should be aggressively specialized. | data SPEC = SPEC | SPEC2 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

pull failing due to deleted .buildinfo files
by Simon Marlow 25 Oct '13

25 Oct '13

I just tried to pull into my tree, and encountered several failures of this kind: == libraries/process: running git pull --rebase Cannot pull with rebase: You have unstaged changes. Please commit or stash them. But I have made no local changes, at least not on purpose. Git reports that: # Changes not staged for commit: # deleted: process.buildinfo I know how to revert this and keep going, but it seems that the build shouldn't be deleting files in the repo. Anyone know anything about this? Cheers, Simon

2 2

hoopl questions
by Brett Letner 24 Oct '13

24 Oct '13

Hi all - Some (beginner) hoopl questions: 1) There doesn't seem to be a "run" function or a way to create FuelMonads. I found runWithFuel, getFuel and setFuel, but they are in the hidden Compiler.Hoopl.Fuel module. This is ghc version 7.6.3 and hoopl version 3.9.0 2) Are there any examples that show "inlining" empty graphs/blocks? Suppose I have a C C graph that looks like this: label 12: goto 13; I'd like to rewrite all the occurrences of label 12 to label 13 and eliminate the label 12 graph (from what I've seen this will happen automatically once all the label 12 references are gone). 3) How about inlining single use graphs? Suppose I have two C C graphs that look like this: label 15: <nodes O O> goto 16; label 16: <nodes O O> <node O C> If the only reference to label 16 is from the label 15 graph, then I'd like to rewrite it as: label 15: <nodes O O from label 15> <nodes O O from label 16> <node O C from label 16> Thanks, Brett

4 5

RE: FW: can't make build fail
by Simon Peyton-Jones 23 Oct '13

23 Oct '13

Yes, I can reproduce it now. good. I'm on the trail. It's to do with the AMP warnings! | -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 23 October 2013 17:13 | To: Simon Peyton-Jones | Subject: Re: FW: can't make build fail | | Simon, | | Strangely I can also not trigger this bug on my machine with validate! | BUT I can trigger it with a normal build! | | For example, this passes: | | $ CPUS=10 sh ./validate | | But this *does* | | $ make distclean && make maintainer-clean && ./boot&& ./configure && | make -j10 | | with a non-specified mk/build.mk (i.e. right after a fresh clone.) | | Can you perhaps try building this way on snake.foxdie.org? | | On Wed, Oct 23, 2013 at 6:22 AM, Simon Peyton-Jones | <simonpj(a)microsoft.com> wrote: | > Austin, (or anyone else) | > | > #8320 is urgent, but I can’t debug it if I can’t reproduce it. You | can | > reproduce it. Can you help me do so? | > | > | > | > Simon | > | > | > | > From: Simon Peyton-Jones | > Sent: 22 October 2013 08:08 | > To: Austin Seipp | > Subject: can't make build fail | > | > | > | > Austin | > | > I have just done a vanilla “sh validate” on snake.foxdie.org, and it | worked | > fine. Haddock docs were built. | > | > So I can’t reproduce the failure #8320 on the very same machine that | you get | > the failure. That’s weird. You could sudo to me and try in | ~/code/HEAD. | > | > I didn’t make a mk/validate.mk file, so I’m just using the underlying | > mk/validate-settings.mk | > | > Can’t debug till I can reproduce! | > | > Thanks | > | > Simon | > | > | > | > Microsoft Research Limited (company number 03369488) is registered in | > England and Wales | > | > Registered office is at 21 Station Road, Cambridge, CB1 2FB | > | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671

1 0

ghci tests failing with role outputs
by Richard Eisenberg 23 Oct '13

23 Oct '13

Hi all, The recent spate of commits that I've pushed change the default roles assigned to classes. Accordingly, I also changed the filter used within ghci only to print out role information when it differs from the default. However, if you've incorporated my commits but haven't updated your libraries, you'll get failures in ghci tests, as the roles in your built libraries won't correspond to the new defaults. These errors are harmless, and it's safe to continue to use the old roles in your compiled libraries. But, if you want clean tests, you will have to recompile the libraries, and then everything will line up again. Richard

1 0