February 2019 - ghc-devs

TTG: Handling Source Locations
by Richard Eisenberg 12 Feb '19

12 Feb '19

Hi devs, I just came across [TTG: Handling Source Locations], as I was poking around in RdrHsSyn and found wondrous things like (dL->L wiz waz) all over the place. General outline: https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… <https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou…> Phab diff: https://phabricator.haskell.org/D5036 <https://phabricator.haskell.org/D5036> Trac ticket: https://ghc.haskell.org/trac/ghc/ticket/15495 <https://ghc.haskell.org/trac/ghc/ticket/15495> Commit: https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5… <https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5…> I see why this change is wanted and how the new version works. It seems to me, though, that this move makes us *less typed*. That is, it would be very easy (and disastrous) to forget to match on a location node. For example, I can now do this: > foo :: LPat p -> ... > foo (VarPat ...) = ... Note that I have declared that foo takes a located pat, but then I forgot to extract the location with dL. This would type-check, but it would fail. Previously, the type checker would ensure that I didn't forget to match on the L constructor. This error would get caught after some poking about, because foo just wouldn't work. However, worse, we might forget to *add* a location when downstream functions expect one. This would be harder to detect, for two reasons: 1. The problem is caught at deconstruction, and figuring out where an object was constructed can be quite hard. 2. The problem might silently cause trouble, because dL won't actually fail on a node missing a location -- it just gives noSrcSpan. So the problem would manifest as a subtle degradation in the quality of an error message, perhaps not caught until several patches (or years!) later. So I'm uncomfortable with this direction of travel. Has this aspect of this design been brought up before? I have to say I don't have a great solution to suggest. Perhaps the best I can think of is to make Located a type family. It would branch on the type index to HsSyn types, introducing a Located node for GhcPass but not for other types. This Isn't really all that extensible (I think) and it gives special status to GHC's usage of the AST. But it seems to solve the immediate problems without the downside above. Sorry for reopening something that has already been debated, but (unless I'm missing something) the current state of affairs seems like a potential wellspring of subtle bugs. Thanks, Richard

6 11

RE: Performance of pattern synonyms
by Simon Peyton Jones 11 Feb '19

11 Feb '19

Are you as convinced as you were of the semantics of pattern synonyms? I can see they are the right semantics given a run-time implementation but the alternative compile-time implementation has a lot to recommend it. What exactly is "the alternative compile-time implementation"? Remember, although pattern synonyms are set up to call a matching function, that matching function is often inlined, which reduces the overhead to zero. I say "often" inlined. An INLINE pragma for pattern synonyms would be a good feature. Widening to ghc-devs. Simon From: Matthew Roberts <matthew.roberts(a)mq.edu.au> Sent: 11 February 2019 00:10 To: matthew.pickering(a)cs.ox.ac.uk; gergo(a)erdi.hu; Simon Peyton Jones <simonpj(a)microsoft.com>; rae(a)cs.brynmawr.edu Subject: Performance of pattern synonyms Hi all, I am working with someone on a compile-time pattern matching extension and the most important prior work is pattern synonyms in Haskell. I hope you might indulge a couple of questions I have not been able to answer myself from the literature: * [In my testing](http://pattern-benchmarks.herokuapp.com/posts/2019-02-09-peano.html<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpattern-be…>), pattern synonyms have remarkable performance, has anyone ever benchmarked them before? * Do you have - on hand - the hackage data you used in investigating uses of pattern synonyms? I am looking for real-world usage of pattern matching extensions. * Are you as convinced as you were of the semantics of pattern synonyms? I can see they are the right semantics given a run-time implementation but the alternative compile-time implementation has a lot to recommend it. Thanks for your time, Matt Roberts Department of Computing, Macquarie University

3 2

RE: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in JUnit output (224fec6)
by Simon Peyton Jones 11 Feb '19

11 Feb '19

Are these commits really for #16188? For which we have a MR in progress https://gitlab.haskell.org/ghc/ghc/merge_requests/207 I was just surprised to see wip/T16188 going by. Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 10 February 2019 21:32 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in | JUnit output (224fec6) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T16188 | Link : | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fchangeset%2F224fec6983e16ecfc44a80d47e591a2425468e | af%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0d | d08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63685431128635 | 6725&sdata=ZS4Bp%2FMsebLALA27waYiWgtyx%2FyrKSkiCLcFXvSfXBE%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 224fec6983e16ecfc44a80d47e591a2425468eaf | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Thu Jan 24 14:20:11 2019 -0500 | | testsuite: Report stdout and stderr in JUnit output | | This patch makes the JUnit output more useful as now we also report | the | stdout/stderr in the message which can be used to quickly identify | why a | test is failing without downloading the log. | | This also introduces TestResult, | previously we were simply passing around tuples, making things the | implementation rather difficult to follow and harder to extend. | | | >--------------------------------------------------------------- | | 224fec6983e16ecfc44a80d47e591a2425468eaf | testsuite/driver/junit.py | 23 ++++++++-------- | testsuite/driver/testglobals.py | 15 +++++++++++ | testsuite/driver/testlib.py | 58 ++++++++++++++++++++++++++--------- | ------ | testsuite/driver/testutil.py | 7 +++-- | 4 files changed, 69 insertions(+), 34 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 224fec6983e16ecfc44a80d47e591a2425468eaf | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0dd | 08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854311286366 | 720&sdata=RH6Jnvs7cNsnGyLpwONSZ0Cldighb85HZtuWfn4Gc9Q%3D&reserved | =0

2 1

Commit comments - call for opinions
by Tobias Dammers 10 Feb '19

10 Feb '19

Dear all, So far, we had a feature in Trac where git commit messages mentioning a ticket would automatically be copied into a comment on that commit. See, for example, this comment: https://ghc.haskell.org/trac/ghc/ticket/13615#comment:47 GitLab does things slightly differently. It has "live" git repository information available, and rather than the relatively static comment list we see in Trac, it synthesizes a "timeline" style list of events relevant to an issue, which includes comments ("notes"), but also issue status updates, git commits, and other things. So when a commit mentions a GitLab issue, then GitLab will insert a link to that commit into the issue's event timeline. This means that in principle, copying commit messages into notes would be redundant, and we initially decided to ignore commit comments during the Trac/GitLab migration. However, it also means that the issue timeline will no longer display the actual commit message anymore, just a link to the commit ("@username mentioned this issue in commit 1234beef" or similar). So what used to be a narrative that you could read top-down to retrace the issue's history is now a bit more scattered. Now, the ideal solution would be for GitLab to instead display the full commit message, but I don't see this happening anytime soon, because it would require a patch to GitLab itself. So we're left with two options: a) Import commit comments as notes, duplicating the commit message into the note, and having both the full commit note and a hyperlinked commit reference in the issue timeline. b) Don't import commit comments as notes, just rely on GitLab to insert the hyperlinked commit reference. If any of you have any preference either way, please do tell. Thanks! -- Tobias Dammers - tdammers(a)gmail.com

5 5

Memory ordering and thunk update
by Ben Gamari 09 Feb '19

09 Feb '19

Hi Simon and Peter, I just wanted to draw your attention to !337 [1], where I try to fix #15994. While it's possible I have missed something, it looks to me like there has been a bug lurking here for quite some time. In particular on a weak memory model machine we do not place a write barrier between the construction of the result of a thunk evaluation and making the results visible to other cores via the indirection's indirectee field. This essentially means that a thread looking at the indirectee may essentially see uninitialized memory. Specifically, updateWithIndirection is currently: # Evaluation result p2 initialized by caller ... ((StgInd *)p1)->indirectee = p2; write_barrier(); SET_INFO(p1, &stg_BLACKHOLE_info); ... whereas I think this should rather be # Evaluation result p2 initialized by caller ... write_barrier(); ((StgInd *)p1)->indirectee = p2; SET_INFO(p1, &stg_BLACKHOLE_info); ... I describe the reasoning for this in more detail in the Note added in !337. All-in-all, I'm rather surprised to find this bug. While we won't see this issue manifest on x86_64 due to this architecture's memory model, we have long supported ARM, PowerPC, and SPARC, all of which have weakly-ordered execution modes. I can't find any relevant open tickets from these platforms. The fact that this wasn't noticed on these platforms makes me wonder whether I am just missing something. Let me know what you think. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/337

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Good to hear you managed to build GHC both with Make and Hadrian. Best wishes with your first GHC patch! Cheers, Andrey From: Eric Crockett [mailto:ecrockett0@gmail.com] Sent: 09 February 2019 18:21 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: Re: Cannot build with Hadrian Andrey, I had already deleted the folder and tried again with make, which was successful. But since I sent the email, I figured I'd try again with hadrian as well. I followed exactly what I did above (which is what I did the first time, too) and it worked fine. *shrug* Thanks anyway! Eric On Sat, Feb 9, 2019 at 5:03 AM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com<mailto:ecrockett0@gmail.com>> To: ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com<mailto:KBdwgb1mLAWgiCsJok6unVhchY%2BuLBbTQ@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com> To: ghc-devs <ghc-devs(a)haskell.org> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

Cannot build with Hadrian
by Eric Crockett 09 Feb '19

09 Feb '19

GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities

1 0

Constructor wrappers vs workers in generated Core
by Christopher Done 08 Feb '19

08 Feb '19

Hi all, I'm compiling Haskell modules with this simple function. I'd like to interpret the Core for practical use and also educational use. compile :: GHC.GhcMonad m => GHC.ModSummary -> m GHC.ModGuts compile modSummary = do parsedModule <- GHC.parseModule modSummary typecheckedModule <- GHC.typecheckModule parsedModule desugared <- GHC.desugarModule typecheckedModule pure (GHC.dm_core_module desugared) And then I'm taking the mg_binds from ModGuts. I want to work with the simplest, least-transformed Core as possible. One thing that's a problem for me is that e.g. the constructor GHC.Integer.Type.S# in this expression \ (ds_dnHN :: Integer) -> case ds_dnHN of _ [Occ=Dead] { S# i# -> case isTrue# (># i# 1#) of _ [Occ=Dead] { False -> (\ _ [Occ=Dead, OS=OneShot] -> $WS# 2#) void#; True -> case nextPrimeWord# (int2Word# i#) of wild_Xp { __DEFAULT -> wordToInteger wild_Xp } }; Jp# bn -> $WJp# (nextPrimeBigNat bn); Jn# _ [Occ=Dead] -> $WS# 2# } is referred to by its wrapper, "$WS#". In general, I'd prefer if it Core always constructed the worker S# directly. It would reduce the number of cases I have to handle. Additionally, what if a worker gets transformed by GHC from e.g. "Wibble !(Int,Int)" to "Wibble !Int !Int", are then case alt patterns going to scrutinize this transformed two-arg version? (As documented here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DataTypes#Thelife…) So my question is: is it possible to disable this wrapper transformation of data constructors? If not it seems like I'll have no option but to handle this extra wrapper stuff, due to the case analyses. That wouldn't be the end of the world, it'd just delay me by another week or so. For strict fields in constructors I was planning on simply forcing the fields in my interpreter when a constructor becomes saturated (and thereby enabling some nice inspection capabilities), rather than generating extra wrapper code that would force the arguments. Cheers

3 5

Fwd: [Haskell] PhD studentships in FP at Bristol
by Matthew Pickering 07 Feb '19

07 Feb '19

Hi all, If there are any students considering applying for PhD programs who are also GHC hackers then Bristol could be a great option for you. Myself and Csongor are currently students here and both actively working on GHC. The programming languages group in Bristol has grown from 1 to 6 people in the last three years and is continuing to expand. Cheers, Matt ---------- Forwarded message --------- From: Meng Wang <meng.wang(a)bristol.ac.uk> Date: Thu, Feb 7, 2019 at 11:20 PM Subject: [Haskell] PhD studentships in FP at Bristol To: Haskell(a)haskell.org <Haskell(a)haskell.org>, Haskell-Cafe(a)haskell.org <Haskell-Cafe(a)haskell.org> Hi list, The programming language group at the University of Bristol is looking for up to three more PhD students in the broad area of functional programming, verification, and testing to join a very dynamic group of FP researchers. http://www.bristol.ac.uk/engineering/departments/computerscience/people/men… http://www.bristol.ac.uk/engineering/departments/computerscience/people/ste… http://www.bristol.ac.uk/engineering/departments/computerscience/people/nic… The positions are fully funded, and with additional bursaries for attending conferences. The ideal candidates will have a strong background in functional programming, especially Haskell, and an appetite for cutting-edge research. For enquiries, please email meng.wang(a)bristol.ac.uk before February 22nd. Best regards, Meng _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

1 0