Re: perf.haskell.org functional again

Hi, Is CircleCI the future now? In general, yes. But it’s running fine for now, so I would not prematurely throw it over. My requirements are: * needs to run on every commit (not just every push), including branches. * needs to be able to push to a repository¹, so it needs access to

Re: Relocatable dist

Hi Manuel, thanks for the link! Ahh yes lovely RPATH (this reminds me, I should look to verify if I can make GHC link recursively.) The conf files came up on #ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker to make them relocatable. I'll probably take a crack at

Re: Relocatable dist

Hi Moritz, Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac app). Unfortunately, it is not just the libdir in the wrapper scripts that’s in the way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) still not macOS-friendly RPATHs in

Re: perf.haskell.org functional again

Hi Joachim, Great! Just because you mention CI infrastructure and our effort around GHC CI at the moment, do you think, it would make sense to move this to CircleCI eventually? Cheers, Manuel > Am 24.10.2017 um 11:02 schrieb Joachim Breitner : > > Hi, > > after a

Re: perf.haskell.org functional again

Hooray! Thanks for doing this! Sent from my iPhone > On 24 Oct 2017, at 8:02 AM, Joachim Breitner wrote: > > Hi, > > after a system upgrade to avoid weird linker errors, and after some fixes in > the nofib submodule, http://perf.haskell.org/ghc is running again. >

perf.haskell.org functional again

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false

RE: forall in constraint

* Like I say I am DEEPLY suspicious of ForallXImplicitBndrs. I can’t make head or tail of it. Is see in you patch you define type ForallXPat (c :: * -> Constraint) (x :: *) =… What is this? Why do we need it? What goes wrong if we remove it altogether? * Likewise

Re: forall in constraint

In Shayan's implementation he has [1] data ImplicitBndrs x thing = IB (XIB x thing) thing | NewImplicitBndrs (XNewImplicitBndrs x thing) type family XIB x thing type family XNewImplicitBndrs x thing type ForallXImplicitBndrs c x thing = ( c (XIB

RE: forall in constraint

I’m lost. Could you give me a bit more context? I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher kinded parameters. Smells all wrong to me. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 23 October 2017 16:07

Re: forall in constraint

code will involve some hs-boot nastiness. Is there any way to require "forall thing. Data thing" inside the DataId constraint? Alan -- next part -- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/

forall in constraint

I am working on the Trees that Grow stuff, and hit a small problem I have type family XIB x thing type family XNewImplicitBndrs x thing type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) = ( c (XIB x thing) , c (XNewImplicitBndrs x

Re: Can't build docs

Simon Peyton Jones via ghc-devs writes: > On Linux I can't build the docs. Log below > Simon > [snip] > processing users_guide.tex... index license intro 8.2.1-notes 8.4.1-notes > ghci runghc usage using using-warnings using-optimisation > Exception occurred: > File

RE: haddock specializeInstHead

I don’t know, but my instinct is to stick to the monomorphic version for now, it that’s all you need. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 20 October 2017 18:33 To: ghc-devs@haskell.org Subject: haddock specializeInstHead I am

Re: GHC HEAD now needs extra tools to build libffi?

I don't know if it helps, but upgrading my ArchLinux installation yesterday broke my builds because of linker issues with stack. I now have to specify "ghc-build: nopie" in stack.yaml file. (cf https://github.com/commercialhaskell/stack/issues/2712) Could your error be related to PIE too?

Re: GHC HEAD now needs extra tools to build libffi?

Hi, Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann: > I still can’t make sense of this. Is your gold a different version now as > well? It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was upgraded: [2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 ->

Re: GHC HEAD now needs extra tools to build libffi?

I still can’t make sense of this. Is your gold a different version now as well? Sent from my iPhone > On 23 Oct 2017, at 8:45 PM, Joachim Breitner wrote: > > Hi, > > JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes > the issue for

Re: GHC HEAD now needs extra tools to build libffi?

Hi, JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes the issue for perf.haskell.org. Greetings, Joachim Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann: > Hi, > > As it turns out this might be linker madness. I do not yet understand why > this did work

Re: Relocatable dist

Hi, Am Montag, den 23.10.2017, 14:04 +0800 schrieb Moritz Angermann: > I've come wonder, how hard it could be to > make GHC relocatable. (e.g. just unpack the distribution, > and use the compiler from the `bin` folder within). Yes yes yes please! (Sorry for not contributing anything but

RE: splitting metavariables

| Actually, I wonder if we can put the check in just one spot: coreView. | Whenever we use coreView, we're about to inspect a type. And we should | never be inspecting a metavariable in this way. Yes, that's right. Maybe that makes a useful distinction between coreView and tcView; the former

Relocatable dist

Hi, while trying to make the binary-distribution logic work for cross compilers. I've come wonder, how hard it could be to make GHC relocatable. (e.g. just unpack the distribution, and use the compiler from the `bin` folder within). Right now this does not work due to the need for the path to