July 2015 - ghc-devs - Haskell.org

GHC crashing in checkProddableBlock during linking
by Luke Iannini 24 Jul '15

24 Jul '15

Hi all, I'm encountering a crash in GHC 7.10.1 and 7.8.4 on Windows when I attempt to use Template Haskell in anything that relies on a package that contains C++; in my case, bindings to the Bullet physics engine. This is a pretty big blocker for me as I haven't found any good workarounds, so it would be awesome to get a fix in (I guess I just missed 7.10.2) I've made some progress here and a minimal reproduction if anyone can help: https://ghc.haskell.org/trac/ghc/ticket/10672 Cheers Luke

1 0

Improving the "Get Haskell Experience"
by Mark Lentczner 23 Jul '15

23 Jul '15

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options. Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan: - Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users. - Use the *stack* model for package installation: - The global db has only the GHC packages - There is a package db for each curated set, Haskell Platform becomes one such set - Projects each have their own package db, much like sandboxes. - Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that *stack* can be used to build and install, on as needed, the corresponding Haskell Platform release packages. We think this plan solves many different community needs: - We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work. To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting *stack* ready such a distribution; and configuring (or updating) *cabal-install* to support the three-layer package db scheme. We think we can do this in short order. We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially *ghc*, *cabal*, and *stack*. We'd like to get your input. - Michael & Mark

5 5

RE: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997)
by Simon Peyton Jones 23 Jul '15

23 Jul '15

Could it be creeping up because Haddock is doing more than before? Ie not just because GHC is being bad? S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 22 July 2015 17:33 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Testsuite: recenter haddock.base | allocation numbers (1b76997) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e1948e | e247dc57c500/ghc | | >--------------------------------------------------------------- | | commit 1b76997dba5c35ee956960e1948ee247dc57c500 | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Wed Jul 22 18:21:44 2015 +0200 | | Testsuite: recenter haddock.base allocation numbers | | | >--------------------------------------------------------------- | | 1b76997dba5c35ee956960e1948ee247dc57c500 | testsuite/tests/perf/haddock/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/haddock/all.T | b/testsuite/tests/perf/haddock/all.T | index 94f7cbd..1e5a16c 100644 | --- a/testsuite/tests/perf/haddock/all.T | +++ b/testsuite/tests/perf/haddock/all.T | @@ -5,7 +5,7 @@ | test('haddock.base', | [unless(in_tree_compiler(), skip), req_haddock | ,stats_num_field('bytes allocated', | - [(wordsize(64), 9014511528, 5) | + [(wordsize(64), 9418857192, 5) | # 2012-08-14: 5920822352 (amd64/Linux) | # 2012-09-20: 5829972376 (amd64/Linux) | # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 +23,7 @@ | test('haddock.base', | # 2014-10-07: 8322584616 (x86_64/Linux) | # 2014-12-14: 9502647104 (x86_64/Linux) - Update to | Haddock 2.16 | # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate so- | called "silent superclass parameters" (and others) | + # 2015-07-22: 9418857192 (x86_64/Linux) - Just slowly | creeping up. | | ,(platform('i386-unknown-mingw32'), 4434804940, 5) | # 2013-02-10: 3358693084 | (x86/Windows) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

2 2

Test failures: T4945 and haddock.base
by Thomas Miedema 22 Jul '15

22 Jul '15

Simon, Allocation for haddock.base is now 9466142208 bytes according to [1]. Before your changes yesterday it was 9385186792, according to [2]. Thomas [1] https://phabricator.haskell.org/harbormaster/build/5076/?l=0 [2] https://perf.haskell.org/ghc/#revision/9ade087108afe2eec2698b6ce41146df0252…

2 2

build system
by Simon Peyton Jones 21 Jul '15

21 Jul '15

Friends With the new build system I get this kind of output HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o AR libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a LD libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o WARNING: file compiler\specialise\Specialise.hs, line 724 But I have no idea which module caused the WARNING, nor do I have a command-line to copy/paste to reproduce it. (With the old module-at-a-time system I could copy/paste the command line for the specific module.) Is there a way to * make things sequential so I can tell which warnings from which module * get a command line to copy/paste to compile that module? Thanks Simon

4 7

Re: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images
by Alan & Kim Zimmerman 21 Jul '15

21 Jul '15

Ok. But it may be worth manually fixing the version on the official web site once 7.10.2 comes out On Tue, Jul 21, 2015 at 9:19 PM, GHC <ghc-devs(a)haskell.org> wrote: > #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 7.10.3 > Component: Documentation | Version: 7.10.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: Phab:D958, > | Phab:D970 > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 7.10.2 => 7.10.3 > > > Comment: > > I think we may need to punt on this for 7.10.2. I spent several hours on > this today and have been entirely unable to get even the an `<img>` tag to > be produced in the HTML, much less a rendered image. Sadly DocBook appears > to be an antiquated disaster. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10416#comment:14> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Trac error
by Tamar Christina 20 Jul '15

20 Jul '15

Hi All, Did something change with Trac recently? I am able to browse it fine when not logged in, but when I log in I get presented with: Oops… Trac detected an internal error: AttributeError: 'FakeSession' object has no attribute 'authenticated' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. on basically any page I try going to and directly after the login action. I have tried multiple devices and browsers. Regards, Tamar

1 0

build system question build-prog and bindisttest
by Tamar Christina 19 Jul '15

19 Jul '15

Hi All, In my ghc.mk I have declared: $(eval $(call build-prog,driver/ghc-split,dist,0)) $(eval $(call bindist,driver/ghc-split,ghc.mk)) compilation is fine but during testing I get this error: ===--- building final phase Bad GHC version '7.8.3' for 'bindisttest/a/b/c/ghc-7.11.20150719/bin/ghc-split.exe' bindisttest/ghc.mk:21: recipe for target 'test_bindist' failed I assume this is because I tell it to build ghc-split at stage 0, so it's using the bootstrapping compiler which in my case is 7.8.3. Now it's perfectly fine to build this at stage 1 or 2, but when I change it to either of those building fails telling me that ghc-stage1 or ghc-stage2 cannot be found... Could the dependency check me wrong? How do I go about fixing this? Regards, Tamar

2 4

Re: Improving the "Get Haskell Experience"
by Greg Weber 19 Jul '15

19 Jul '15

The main reason I am using stack is for its support for building a project containing multiple packages. There aren't any other tools that make this a first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame. On the other hand, stack already has good package distribution. But providing both cabal-install and stack is the right choice that helps keep the Haskell platform relevant and avoid new users having to go through multiple installation steps. On Sun, Jul 12, 2015 at 12:07 PM, <amindfv(a)gmail.com> wrote: > The HP is a place for tools which have stabilized. A few reasons why I > don't think stack is ready: > > - stack has initial interest from the community, but so did ghc-dev and > hsenv. It's still (imo) in proof of concept stage, and we don't know where > its lessons will ultimately end up. In those other two cases, they ended up > being folded into cabal, which is one likely scenario with stack. > > - There are other solutions on the horizon! There's a GSOC project that > will add nix-style package management to cabal. This should eliminate most > (all?) the cabal hell we know and love, and that's why most stack users are > trying it, no? > > - The HP is for stable apis for users, too -- we provide tools that users > won't have to unlearn or re-learn. Most languages don't have two package > managers! We're clearly in an unstable state, which isn't when we should > add to the HP. > > If 9 months from now stack is clearly the right tool for the job (i.e. > we're considering deprecating cabal), then I'd definitely consider > supporting adding it to the HP but otherwise i'm strongly -1. (If it needs > saying, I don't think stack is a bad tool). > > tl;dr: The dust hasn't settled. Please don't add tools to the HP which we > don't know will be in common use (in their current form) a year from now. > > Tom > > > El Jul 12, 2015, a las 12:25, Mark Lentczner <mark.lentczner(a)gmail.com> > escribió: > > > No - we are not talking about the upcoming, 7.10.2 HP release. It would > for the next major release after that. > > > > Yes, stack has only been out ~1 month, but it has already shown traction > in the community, and it has a clear working solution for managing > "curated" pacakge sets, like Haskell Platform. > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

4 4

New release of GHC 7.8 to support OS X El Capitan
by Oleg Grenrus 18 Jul '15

18 Jul '15

Hi, first some background: there is an issue with having Haskell on the next OS X “El Capitan”: [1] caused by security updates in the operating system. The cause is too old `unix` package, the same issue as in [2] Could someone verify that my understanding of the issue is correct, i.e. how Cabal-the-tool and Cabal-the-library interoperate. For me it seems, that one of the easiest ways to fix the issue (for the users), is to have a new release in 7.8 branch, with updated `unix` dependency. Or is it there too might hassle to be possible? Related issues: [3] [4] [1] https://github.com/haskell/cabal/issues/2653 <https://github.com/haskell/cabal/issues/2653> [2] https://github.com/haskell/unix/pull/18 <https://github.com/haskell/unix/pull/18> [3] https://github.com/commercialhaskell/stack/issues/563 <https://github.com/commercialhaskell/stack/issues/563> [4] https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535 <https://github.com/ghcformacosx/ghc-dot-app/issues/39#issuecomment-122088535> Greetings, Oleg P.S. hopefully Windows 10 doesn’t pose similar surprises.

4 3