Re: Hadrian

Hi, two things. a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand a subtree, it's

RE: Hadrian

Hi Ben, > Well, the GitHub repo will still exist. Is that enough? Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file: -- Objdump is only required on OpenBSD and AIX, as

RE: Hadrian

Andrey Mokhov writes: > Thanks Ben, > > Just to clarify: By history I mean not just commits, but GitHub issues > and PRs as well -- together they contain a lot of valuable interlinked > information for GHC/Hadrian developers. > Well, the GitHub repo will still

RE: Hadrian

Thanks Ben, Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers. > That is pretty much precisely the use-case which > git subtree was designed to address. This will

RE: Hadrian

Andrey Mokhov writes: > Hi Mathieu, > > Yes, in principle we can merge right now, as long as it's clear that Hadrian > still requires more work before taking over. > > My only concern is that merging will make it more difficult for us to > quickly iterate on

RE: Hadrian

Hi Mathieu, Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over. My only concern is that merging will make it more difficult for us to quickly iterate on Hadrian: the GitHub workflow is more convenient (at least for me) than

Re: Hadrian

"Boespflug, Mathieu" writes: > Hi all, > > As a user who tried to be an early adopter of Hadrian, I can attest to > Andrey's remarks about GHC progress sometimes (frequently?) breaking > Hadrian. > > Ben, Andrey - how about this strawman proposal: > > we merge Hadrian into GHC

Re: Hadrian

Hi all, As a user who tried to be an early adopter of Hadrian, I can attest to Andrey's remarks about GHC progress sometimes (frequently?) breaking Hadrian. Ben, Andrey - how about this strawman proposal: we merge Hadrian into GHC *now*, not because ./validate with Hadrian works (it doesn't

Re: Determine instance method from class method callsite

I have the same problem with a compiler plugin that I am writing. In GHC Core I need to get from a dict-fun identifier (e.g. $fMyClassDouble to the type class instance bindr (starting with $c). lookupInstEnv from the InstEnv module seemed to do it, but it seems to look up the matching key

Re: Compiling natively GHC for ARMv7l softabi

October 19, .00µ2017 6:.00ÿ8 PM, "Moritz Angermann" wrote: > Shiftag, > > any chance you could try this with 8.2 again then? >

Re: Compiling natively GHC for ARMv7l softabi

Shiftag, any chance you could try this with 8.2 again then? Cheers, Moritz > On Oct 19, 2017, at 9:56 PM, Ben Gamari wrote: > > Moritz Angermann writes: > >> Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even >>

Re: Compiling natively GHC for ARMv7l softabi

Moritz Angermann writes: > Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even > make it to the assembly stage... > This was a known bug in 8.0. See #11784. IIRC I fixed it for 8.2. Cheers, - Ben signature.asc Description: PGP signature

Re: Compiling natively GHC for ARMv7l softabi

October 19, 2017 11:52 AM, "Moritz Angermann" wrote: > Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even > make it to the assembly > stage... > >> On Oct 19, 2017, at 3:32 PM, shif...@nanotek.info wrote: >> >> October 19, 2017 10:34 AM,

[ANN] GHC DevOps Group

We announced the GHC DevOps Group at the Haskell Implementors’ Workshop in Oxford earlier this year in Simon PJ’s ”Progress on GHC” session. (The videos are unfortunately not yet online.) To finally announce it more broadly, I wrote a blog post:

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

Hi, As it turns out this might be linker madness. I do not yet understand why this did work with the "old" libffi though. The command that fails is a rather long gcc invocation asking it to link a bunch of libraries together. $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold'

Re: Compiling natively GHC for ARMv7l softabi

Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage... > On Oct 19, 2017, at 3:32 PM, shif...@nanotek.info wrote: > > October 19, 2017 10:34 AM, "Moritz Angermann" > wrote: > >>> "inplace/bin/ghc-stage1" -static

Re: Compiling natively GHC for ARMv7l softabi

October 19, 2017 10:34 AM, "Moritz Angermann" wrote: >> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist >> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header >> -Irts -Irts/dist/build >> -DCOMPILING_RTS

Re: Compiling natively GHC for ARMv7l softabi

> > "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header > -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP > -dcmm-lint -i -irts -irts/dist/build

Re: Compiling natively GHC for ARMv7l softabi

October 18, 2017 6:51 PM, "Ben Gamari" wrote: > shif...@nanotek.info writes: > >> October 17, 2017 10:45 PM, "Ben Gamari" wrote: >> >> Hi Guys, >> >> Thanks a mil !!! > > Great! > > Do let us know if anything else goes boom. > > Cheers, > > -