- ghc-devs - Haskell.org

7.8.1 RC
by Austin Seipp 04 Nov '13

04 Nov '13

Hello all, First and foremost, I realize that I said an RC was coming on Friday along with a branch, but I've unfortunately been a bit behind the gun this week, and several things more things have come to my attention recently. For the delay, I am very sorry. Here's an update on the most pertinent tickets and what needs to happen. One thing is that Herbert and I would like to upload many of the bootstrap libraries to hackage to coincide with the release, but this requires a server upgrade that should happen quite soon (thanks to Duncan/Herbert.) Herber and I also went over #8305, which should (in our opinion) certainly be part of the RC so issues can be filed, and clearly documented. Herbert has a patch for this, and I'll review it today. Second, the new OS X release, Mavericks (and, by association, XCode 5) seem to be a little confusing at the moment, and I don't have access to these machines quite yet. Only a Lion machine. One reason this is a delay is because I don't quite understand e.g. #8497 and #8493 in particular. There has also historically been some issues with different OS X builds not working on different platforms due to XCode and/or strange ABI issues, so I need to make my own to double check. Preprocessing seems to becoming a hot issue* on the note of #8493, and this also certainly needs attention once I get my hands on a machine. There's been a lot of pain around making all this 'work correctly', and working by proxy is simply becoming difficult I think, so I just need to dig into it a bit once I have my hands on something. Also relevant to this is that I'll be signing the announcement, and giving out tarballs with checksums(!), so some of these issues must be fixed for distribution (like #5987, which I am still investigating.) Finally, I have some incoming patches to fix a few of the critical priority bugs (related to Windows, mostly,) but they need to be polished and I need to investigate some other things related to them (e.g. due to lack of time, I only have a 'very slow path' fix for #8228, which is a bit annoying. And also this new msys2 thing.) * Richard Smith, if you're out there, I should have listened to you on the LLVM list. I'll learn from this one. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Current link-destination Haddock warnings in base
by Herbert Valerio Riedel 01 Nov '13

01 Nov '13

Hello *, ...currently, when generating Haddock for `base` I see the warnings below; shall those warnings remain for GHC 7.8.1, or do we want to export (at least some of) the missing link destinations to reduce the amount of Haddock warnings? ,---- | Warning: Data.Type.Coercion: could not find link destinations for: | GHC.Types.Coercible | Warning: Data.Typeable.Internal: could not find link destinations for: | GHC.Prim.Proxy# | Warning: Text.Read: could not find link destinations for: | GHC.Types.Coercible | Warning: Data.List: could not find link destinations for: | Data.List.nonEmptySubsequences | Warning: GHC.Foreign: could not find link destinations for: | GHC.Foreign.CString GHC.Foreign.CStringLen | Warning: GHC.IO.Handle: could not find link destinations for: | GHC.IO.Handle.Types.Handle__ GHC.IO.Exception.ResourceVanished | Warning: GHC.IO.Handle.FD: could not find link destinations for: | GHC.IO.FD.FD System.Posix.Internals.FD | Warning: System.IO: could not find link destinations for: | GHC.IO.Exception.ResourceVanished | Warning: Prelude: could not find link destinations for: | GHC.Types.Coercible | Warning: Data.Data: could not find link destinations for: | GHC.Types.Coercible | Warning: GHC.Event: could not find link destinations for: | GHC.Event.TimerManager.TimerManager `---- Cheers, hvr

1 0

TemplateHaskell usage of Annotations
by Gergely Risko 30 Oct '13

30 Oct '13

Hi, In the recent weeks I've been working on making it possilbe to use Annotations (both generate and reify) from TemplateHaskell. We've hit some gray area where design decisions were needed during the reviews. SPJ asked me to write up a wikipage on my use-case and the approach that is taken in the current patches, so we can discuss alternative ideas, problems and questions openly. http://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Annotations Therefore, if you're interested please use this thread, the bug tracker or the wiki to comment on these issues! Thanks, Gergely Risko

3 4

XCode 5
by Kazu Yamamoto 28 Oct '13

28 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 27 Oct '13

27 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 27 Oct '13

27 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