- ghc-devs - Haskell.org

Re: Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 30 Aug '13

30 Aug '13

No! Sorry for the confusion Simon, it is HEAD _PLUS_ my own commit that triggers these errors. Oh, and I should add that 'my own commit' is only in my own development repository. So, no worries! /Dan On Fri, Aug 30, 2013 at 4:44 PM, Simon Peyton-Jones <simonpj(a)microsoft.com>wrote: > Wait.. are you saying that with HEAD several test suite programs fail as > you describe below? If so, which? > > Simion**** > > ** ** > > *From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Dan > Rosén > *Sent:* 30 August 2013 14:26 > *To:* David Luposchainsky > *Cc:* ghc-devs(a)haskell.org > *Subject:* Re: Cannot make ghc: Failed to load interface for GHC.Base**** > > ** ** > > Closed, but a note to interested readers: > > killy9999 on #ghc realized the reason why the stage1 compiler cannot be > built with this patch is related to that several test suite programs exit > with erros like this:**** > > GHC/Base.lhs:1:1:**** > > GHC internal error: 'GHC.Base.Monad' is not in scope during type checking, but it passed the renamer**** > > tcl_env of environment: []**** > > > So the error is resolved, and now productive debugging can start.**** > > ** ** > > On Fri, Aug 30, 2013 at 2:50 PM, Dan Rosén <danr(a)chalmers.se> wrote:**** > > Sorry! I thought I got this build error when making HEAD, but I don't. > It builds fine. > > However, if I just cherry-pick this simple commit onto HEAD > https://github.com/danr/ghc/commit/86631ffd294af320cb9b00e1a593201af887ed72 > , > then I do get this error, which is very puzzling. I did a make > maintainer-clean in between. **** > > ** ** > > On Thu, Aug 29, 2013 at 6:05 PM, David Luposchainsky < > dluposchainsky(a)googlemail.com> wrote:**** > > On 2013-08-29 18:03, Austin Seipp wrote: > > When was the last time you cleaned your tree? Earlier this week I made a > > breaking change to the interface file format. If you have a build from > > before then, update and incrementally rebuild, it will break.**** > > I tried all of clean, distclean and maintainer-clean, followed by the > usual build process. The issue remains.**** > > > David > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs**** > > ** ** > > ** ** >

1 0

Re: Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 30 Aug '13

30 Aug '13

Closed, but a note to interested readers: killy9999 on #ghc realized the reason why the stage1 compiler cannot be built with this patch is related to that several test suite programs exit with erros like this: GHC/Base.lhs:1:1: GHC internal error: 'GHC.Base.Monad' is not in scope during type checking, but it passed the renamer tcl_env of environment: [] So the error is resolved, and now productive debugging can start. On Fri, Aug 30, 2013 at 2:50 PM, Dan Rosén <danr(a)chalmers.se> wrote: > Sorry! I thought I got this build error when making HEAD, but I don't. > It builds fine. > > However, if I just cherry-pick this simple commit onto HEAD > https://github.com/danr/ghc/commit/86631ffd294af320cb9b00e1a593201af887ed72 > , > then I do get this error, which is very puzzling. I did a make > maintainer-clean in between. > > > > On Thu, Aug 29, 2013 at 6:05 PM, David Luposchainsky < > dluposchainsky(a)googlemail.com> wrote: > >> On 2013-08-29 18:03, Austin Seipp wrote: >> > When was the last time you cleaned your tree? Earlier this week I made a >> > breaking change to the interface file format. If you have a build from >> > before then, update and incrementally rebuild, it will break. >> >> I tried all of clean, distclean and maintainer-clean, followed by the >> usual build process. The issue remains. >> >> David >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >

2 1

Re: Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 30 Aug '13

30 Aug '13

Sorry! I thought I got this build error when making HEAD, but I don't. It builds fine. However, if I just cherry-pick this simple commit onto HEAD https://github.com/danr/ghc/commit/86631ffd294af320cb9b00e1a593201af887ed72, then I do get this error, which is very puzzling. I did a make maintainer-clean in between. On Thu, Aug 29, 2013 at 6:05 PM, David Luposchainsky < dluposchainsky(a)googlemail.com> wrote: > On 2013-08-29 18:03, Austin Seipp wrote: > > When was the last time you cleaned your tree? Earlier this week I made a > > breaking change to the interface file format. If you have a build from > > before then, update and incrementally rebuild, it will break. > > I tried all of clean, distclean and maintainer-clean, followed by the > usual build process. The issue remains. > > David > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

RE: [Haskell-cafe] Announcing GHC iOS
by Simon Peyton-Jones 30 Aug '13

30 Aug '13

Congratulations! And thank you! GHC only thrives because people like you and Stephen are willing to put in the cycles to help. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Luke Iannini Sent: 29 August 2013 21:44 To: Haskell Cafe Subject: [Haskell-cafe] Announcing GHC iOS Hi all! (in case you don't read /r/haskell : )) Stephen Blackheath and I are extremely happy to report that as of today, GHC can natively build binaries for iOS devices and the iOS Simulator. You'll find everything you need here: http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS The short of it is you can use "ghc-ios myFiles.hs" to get a universal ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project. Stephen's already working on some wonderful FRP-powered games, I'm working on a project called SpaceTime that I'll announce shortly, and you may now all begin creating insanely great iOS software using the finest language in the world : ). Stephen deserves the lion's share of the credit for this project - it's been over 3 years in the making! Many thanks to Maxwell Swadling for generalizing static library builds into a -staticlib flag for GHC, Carter Schonwald for compilation guidance, and the venerable Austin Seipp for reviewing and merging our patches.

1 0

Design discussion for atomic primops to land in 7.8
by Ryan Newton 30 Aug '13

30 Aug '13

There's a ticket that describes the design here: http://ghc.haskell.org/trac/ghc/ticket/8157#comment:1 It is a fairly simple extension of the casMutVar# that has been in since 7.2. The implementation is on the `atomics` branch currently. Feel free to add your views either here or on that task's comments. One example of an alternative design would be Carter's proposal to expose something closer to the full LLVM concurrency ops<http://llvm.org/docs/Atomics.html> : Schonwald <carter.schonwald(a)gmail.com> wrote: > i'm kinda thinking that we should do the analogue of exposing all the > different memory model level choices (because its not that hard to add > that), and when the person building it has an old version of GCC, it falls > back to the legacy atomic operations? > > This also gives a nice path to how to upgrade to the inline asm approach. > These LLVM ops include many parameterized configurations of loads, stores, cmpxchg, atomicrmw and barriers. In fact, it implements much more than is natively supported in most hardware, but it provides a uniform abstraction. My original thought was that any kind of abstraction like that would be built and maintained as a Haskell library, and only the most rudimentary operations (required to get access to process features) would be exposed as primops. Let's call this the "small" set of concurrent ops. If we want the "big set" I think we're doomed to *reproduce* the logic that maps LLVM concurrency abstractions onto machine ops irrespective of whether those abstractions are implemented as Haskell functions or as primops: - If the former, then the Haskell library must map the full set of ops to the reduced small set (just like LLVM does internally) - If we instead have a large set of LLVM-isomorphic primops.... then to support the same primops *in the native code backend *will, again, require reimplementing all configurations of all operations. Unless... we want to make concurrency ops something that require the LLVM backend? Right now there is not a *performance* disadvantage to supporting a smaller rather than a larger set of concurrency ops (LLVM has to emulate these things anyway, or "round up" to more expensive ops). The scenario where it would be good to target ALL of LLVMs interface would be if processors and LLVM improved in the future, and we automatically got the benefit of better HW support for some op on on some arch. I'm a bit skeptical of that proposition itself, however. I personally don't really like a world where we program with "virtual operations" that don't really exist (and thus can't be *tested* against properly). Absent formal verification, it seems hard to get this code right anyway. Errors will be undetectable on existing architectures. -Ryan

7 9

heads up: new .hi format
by Nicolas Frisby 29 Aug '13

29 Aug '13

FYI I just pushed a commit (cf http://ghc.haskell.org/trac/ghc/wiki/LateDmd) that changes the format of the .hi files — so it's safest to do a full rebuild once you pull it.

1 0

Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 29 Aug '13

29 Aug '13

Dear devs, I'm getting this build error when compiling GHC: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o libraries/ghc-prim/GHC/Types.hs:1:1: Failed to load interface for 'GHC.Base' There are files missing in the 'base' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 I uploaded a full log of (perl boot && ./configure && make) here: http://www.cse.chalmers.se/~danr/log (3MB) At lines 2515- I can see this: "/home/dan/code/ghc/inplace/bin/ghc-pkg" update --force libraries/base/dist-install/inplace-pkg-config Reading package info from "libraries/base/dist-install/inplace-pkg-config" ... done. base-4.7.0.0: Warning: haddock-interfaces: /home/dan/code/ghc/libraries/base/dist-install/doc/html/base/base.haddock doesn't exist or isn't a file base-4.7.0.0: cannot find any of ["Control/Applicative.hi","Control/Applicative.p_hi","Control/Applicative.dyn_hi"] (ignoring) ... base-4.7.0.0: cannot find any of ["GHC/Base.hi","GHC/Base.p_hi","GHC/Base.dyn_hi"] (ignoring) Maybe this is related? I don't know if these ignores are expected. I've tried cloning the repo from http://git.haskell.org/ghc.git and the github mirror, I'm using the "quick" build flavour, but I've also tried adding DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO before GhcLibWays' definition in mk/build.mk without success. Any ideas what could be wrong? Thanks, Dan

3 3

Re: make -jN loops on Windows
by Kyle Van Berendonck 29 Aug '13

29 Aug '13

Hi Simon, I think this is a MinGW bug. If we're talking about the same bug (lockup, no console output, task manager shows cpu but it doesn't produce files, etc) I get it when building other projects with -j too and I don't think its GHC's fault. Regards, Kyle Van Berendonck

3 6

Re: [Haskell-cafe] Building recent Cabal/cabal-install
by Johan Tibell 29 Aug '13

29 Aug '13

Hi, Cabal 1.18 is still in the release candidate stage so it has in fact not been released yet. We could either bump the dependency on base to <4.8 before the 1.8 release or we could make a Cabal-1.8.0.1 release together with the GHC release that bumps the dependency. -- Johan On Wed, Aug 28, 2013 at 9:08 PM, Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk>wrote: > Greetings café, > > There are some problems in Haddock to do with Template Haskell that I > believe are being caused by Cabal. These were apparently addressed in > 1.18 which came out recently. ‘Great!’, I thought. > > My problem is that I'm unsure how to use 1.18. I'm using GHC HEAD (well, > 3 days old now) which is meant to come with Cabal 1.18 (the library) and > in fact it seems to ship with it. Running ‘cabal --version’ however: > > > cabal-install version 1.17.0 > > using version 1.17.0 of the Cabal library > > I'm unsure how to get it to use 1.18. I tried to build cabal-install > from git but that just complains about dependencies not being possible > to resolve: it depends on HTTP which depends on base <4.7 but 4.7 comes > with GHC HEAD! > > I am baffled as to how I should go about using 1.18 and would love to > hear from some people who have this up and running. > -- > Mateusz K. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Disallow pushing of new trailing whitespace
by Jan Stolarek 29 Aug '13

29 Aug '13

Right now we have a git hook that prevents pushing a file containing tabs, unless that file had them already (in other words: no new files with tabs in our repos). I propose to add similar hook for trailing whitespaces. Herbert says he can implement that. What do others think? Would you find that useful or problematic? Janek

7 12