- Glasgow-haskell-users

GHC iOS ARMv7/ARMv7s fat support completed
by Luke Iannini 26 Jan '14

26 Jan '14

Hi folks, Happy to report that I've finished an approach to armv7/armv7s fat compilation, just in time for 7.8's imminent release. You'll find the necessary scripts here: https://github.com/ghc-ios/ghc-ios-scripts and the latest instructions for building GHC for iOS usage here: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I've also added support for a perf-cross BuildFlavour, which will give a higher-performance and profiling-ready build that matches what we'll be putting together as the official 7.8 GHC iOS binaries: https://ghc.haskell.org/trac/ghc/ticket/8700 Cheers Luke

2 1

Parallel building multiple targets
by Sami Liedes 23 Jan '14

23 Jan '14

Hi, I have a Haskell project where a number of executables are produced from mostly the same modules. I'm using a Makefile to enable parallel builds. I received advice[1] that ghc -M is broken, but that there is parallel ghc --make in HEAD. As far as I can tell, ghc --make does not allow building several binaries in one run, so I think it may not still be a full replacement for Makefiles. However I have a question about ghc --make that is also relevant without parallel ghc --make: If I have two main modules, prog1.hs and prog2.hs, which have mutual dependencies (for example, both import A from A.hs), is it safe to run "ghc --make prog1" in parallel with "ghc --make prog2"? IOW, is there some kind of locking to prevent both from building module A at the same time and interfering with each other? Is there a good way (either in current releases or HEAD) to build multiple binaries partially from the same sources in parallel? Sami [1] http://stackoverflow.com/questions/20938894/generating-correct-link-depende…

4 7

Re: RFC: include a cabal-install executable in future GHC releases
by Herbert Valerio Riedel 22 Jan '14

22 Jan '14

On 2014-01-22 at 10:08:02 +0100, Henning Thielemann wrote: > Am 22.01.2014 09:57, schrieb Herbert Valerio Riedel: >> On 2014-01-21 at 20:22:48 +0100, Ganesh Sittampalam wrote: >>> I feel this blurs the roles of GHC and the Platform. >> >> IMO, that's a weak argument, as the roles are already blurred: > >> GHC comes with `haddock`, `hp2ps`, and `hpc` executables which could be >> provided by the HP instead. > > At least haddock is bound to the specific GHC version. When I look at http://hackage.haskell.org/package/haddock, there are multiple versions, 2.12.0 and the 4 versions of 2.13.*, which are all declared to work with ghc == 7.6.*, that is, 5 haddock versions compatible with 3 released versions of GHC 7.6. So while it may be bound to a major version of the GHC API, haddock can obviously have more releases than GHC has releases (otherwise it could just carry GHC's version), and can therefore be updated.

2 1

--split-objs
by harry 20 Jan '14

20 Jan '14

The documentation for --split-objs states that "this only makes sense for libraries". How is an executable compiled against a split-objs library? According to https://github.com/haskell/cabal/issues/1611#issuecomment-30750655, this isn't happening by default. -- View this message in context: http://haskell.1045720.n5.nabble.com/split-objs-tp5741209.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 6

Re: RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 20 Jan '14

20 Jan '14

indeed, after thinking a wee bit more, yes, it'd be AMAZING if cabal devs made binaries visibly available to the community! (also, it does seem like cabal / cabal-install docs aren't super discoverable for some people) On Mon, Jan 20, 2014 at 12:24 AM, Oren Ben-Kiki <haskell-oren(a)ben-kiki.org>wrote: > Hear hear! This would be most welcome. > > > On Mon, Jan 20, 2014 at 2:14 AM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> that still requires some discovery though! The idea (i'd hope) would be >> to make the "my first ghc install on a vm" (for experts and new folks both) >> >> go from >> >> #install ghc via whatever mechanism, eg wget, guntar, cd blah ; make >> install PREFIX=yah >> #figure out how to install cabal, eg discover wget and then ./bootstrap >> # cabal install thingsIwannaTry >> >> to >> # install ghc via some wget and make >> #cabal install nice things >> >> >> On Sun, Jan 19, 2014 at 7:11 PM, Mikhail Glushenkov < >> the.dead.shall.rise(a)gmail.com> wrote: >> >>> Hi, >>> >>> On Mon, Jan 20, 2014 at 1:02 AM, Carter Schonwald >>> <carter.schonwald(a)gmail.com> wrote: >>> > >>> > point being: It'd be great for haskell usability (and egads amounts of >>> > config time, even by seasoned users) the ghc bindists / installers >>> included >>> > a cabal-install binary >>> >>> For Windows, we provide a stand-alone cabal.exe on the Cabal site [1]. >>> I guess we could do the same for Linux and OS X. >>> >>> [1] http://www.haskell.org/cabal/download.html >>> >>> -- >>> () ascii ribbon campaign - against html e-mail >>> /\ www.asciiribbon.org - against proprietary attachments >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> >> >

1 0

GADT records revisited
by "Philip K.F. Hölzenspies" 17 Jan '14

17 Jan '14

Dear all, I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a GHC tells me this: foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: fooBar :: FooBar x a -> a ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? Regards, Philip

3 2

Enabling TypeHoles by default
by Krzysztof Gogolewski 15 Jan '14

15 Jan '14

Hello, As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by default. Rationale: (1) This way holes are far easier to use; just entering "_" allows to check type of a subexpression, no need of adding "-XTypeHoles". (2) This affects error messages only; i.e. the set of programs that compile stays the same - Haskell 2010. The only exception is that if you use -fdefer-type-errors, then a program with a hole compiles, but this seems fine with philosophy of -fdefer-type-errors. If so: would you like it to be in 7.8 or wait a cycle? My preference is 7.8, two people (John and Richard) suggested 7.10. -KG

14 24

Feature request: Vacuous/error constraint (related to 7.7 closed type families regression)
by Merijn Verstraaten 14 Jan '14

14 Jan '14

I was trying to fix one of my closed type families examples for the new syntax, and run into an unfortunate issue. Due to a kind error in my code one of my constraints was being silently discarded (see ticket: https://ghc.haskell.org/trac/ghc/ticket/8669) The main reason I resorted to this (in hindsight) ill-kinded hack is the lack of a vacuous (i.e. never holding) constraint to produce type errors. I would love to be able to explicitly force GHC into realising "this constraint can never hold", if I had the ability to pass along a String/Symbol to be reported to the user, that would be even better. Cheers, Merijn

3 2

Problem with the object file name of the Main module.
by Christian Brolin 14 Jan '14

14 Jan '14

H. The documentation (version 7.6.3) section 7.7.2 Output files says that the source file name of the Main module does not have to be Main.hs making it "possible to have several Main modules in separate source files in the same directory". While this is true and promising it is seems to be unusable since GHC always compiles the main source file into an object file called Main.o.

4 7

Mips64el Linux Build
by cherry 05 Jan '14

05 Jan '14

Hello, I am new to the list, though I have been using GHC for a long time. Just say Hello. I would like to share my experience about building GHC (7.7.20131112) on/for mips64el linux, just in case anybody is interested, as it seems not documented (on Wiki pages of Platforms, CrossCompiling, or Porting). Ignore this email if it is not interesting or too trivial. It bootstrapped by cross compiling on x86_64 linux, with some tweaking on mk/build.mk and the build process. In particular, I needed to specify export CPP="mips64el-unknown-linux-gnu-gcc -E" otherwise the configure script just found to use the native "gcc -E" and it failed in preprocessing rts C files. Also in mk/build.mk I forced GhcThreaded = NO GhcWithInterpreter = YES # so, it can use TH and build happy The make process failed when trying to use ghc-stage2, but at that point the stage 2 compiler is already built, that's enough. With this cross-compiled ghc-stage2, the native build on mips64el machine was done without much interleaving. inplace/lib/unlit was x86_64 binary, and needed to be rebuild. Also manually built alex and happy (and their dependencies). Then it just went through. So, the new way of porting seems just cross compiling followed by native compiling? Somewhat surprisingly, GHCi is also working (forced it to be built), with system's dynamic linker. Is there need to write/update a wiki page for this? Thanks, cherry

2 1