- ghc-devs - Haskell.org

Re: dll-split
by Ryan Scott 30 Aug '17

30 Aug '17

Thanks for putting so much effort into this work, Tamar! > When I do turn it on, by default you will get a large ~45min hit in compile time. Yikes, that's really bad! Bad enough that I have to wonder: would it be worth including genlib among the other executables that we bundle with GHC? Fortunately, us GHC developers have the foresight to know that we should install genlib, but I imagine less informed Windows users probably won't get the memo and will start to wonder why compilation became so slow all of a sudden. Ryan S.

3 3

dll-split
by lonetiger＠gmail.com 29 Aug '17

29 Aug '17

Hi All, I have just killed off dll-split, this means that you no longer need to maintain a list of modules in GHC.mk. If you’re a non-Windows programmer you can stop reading here, for those that build on Windows: The replacement for dll-split is called gen-dll, and it is able to automatically partition any library we build, so this issue is hopefully solved once and for all. Currently dynamic linking is still turned off as I have a few more patches to upstream. When I do turn it on, by default you will get a large ~45min hit in compile time. This is because dlltool which BFD based is quite slow. To mitigate this gen-dll supports the use of the msys2 project’s genlib tool. This tool finishes in seconds instead of tens of minutes like dlltool. To install it just run pacman -Sy mingw-w64-$(uname -m)-tools-git The wiki pages have been updated accordingly already. If you install this now you won’t notice any difference in build time later. Thanks, Tamar

1 0

Crossreferenced GHC 8.0.2
by Robin Palotai 29 Aug '17

29 Aug '17

Hello GHC devs, I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I find myself reading GHC source from time to time while working on the indexer, and partly since it's fun. First, here you can click around [2] and find where beloved functions are called from: http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs?corpus&signature (scroll down a bit, imports are not linked yet). Second, the way I indexed was pretty simple. I took the output of `make`, replaced the ghc used with the ghc_kythe_wrapper, and filtered the lines which included '-c', since I noticed that those duplicate previous large compile lines. This only indexes the stage1 compilation AFAIU. Feel free to suggest a better way to tap into the compilations to get everything properly indexed (and possibly only once). Any comments welcome! Robin [1]: https://github.com/google/haskell-indexer [2]: TLDR UI quirks: - Click the :: in top-left to navigate file tree - Ctrl-Click (on linux) to go directly to definition (otherwise click stuff from bottom pane) - Bottom pane often hides content, close it if stuck.

3 7

RE: [commit: ghc] master: Adjust test suite stats (a055f24)
by David Feuer 28 Aug '17

28 Aug '17

These were regressions from your simplifier refactoring. Yes, we should investigate. I'll open a ticket this evening, unless someone else gets to it first. But we surely don't want to keep CI red on every commit until then. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> Date: 8/28/17 4:57 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24) David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: [commit: ghc] master: Adjust test suite stats (a055f24)
by Simon Peyton Jones 28 Aug '17

28 Aug '17

David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0

1 0

RE: Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

| note that you mistyped "lockd" (aka "lock daemon") as "locd" Oh, sorry about mistyping simonpj@cam-05-unx:~/tmp$ ps -Af | grep lockd root 140 2 0 2016 ? 00:00:00 [kblockd] simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd | also, the output of "rpcinfo -p" would be interesting to know simonpj@cam-05-unx:~/tmp$ rpcinfo -p Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' The command could not be located because '/usr/sbin' is not included in the PATH environment variable. This is most likely caused by the lack of administrative privileges associated with your user account. rpcinfo: command not found | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 28 August 2017 12:51 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Alex install failure | | Simon, | | note that you mistyped "lockd" (aka "lock daemon") as "locd" | | also, the output of "rpcinfo -p" would be interesting to know | | On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep locd | > simonpj 20138 1184 0 12:46 pts/7 00:00:00 grep locd | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep portmap | > simonpj 22601 1184 0 12:46 pts/7 00:00:00 grep portmap | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep rpcbind | > root 1472 1 0 2016 ? 00:00:13 rpcbind -w | > simonpj 26634 1184 0 12:46 pts/7 00:00:00 grep rpcbind | > | > simonpj@cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home | > type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81) | > | > | -----Original Message----- | > | From: Ben Gamari [mailto:ben@well-typed.com] | > | Sent: 25 August 2017 17:46 | > | To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | Cc: ghc-devs <ghc-devs(a)haskell.org> | > | Subject: RE: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | | > | > | I have implemented this in wip/ghc-pkg-locking. Do you think | > | you > | could give this branch a try? If it still fails then we'll | > | have to > | try to debug things in-situ. | > | > | > | > Alas, no go. | > | > | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | Cheers, | > | | > | - Ben | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csi | > monpj%40microsoft.com%7C33b163bdb97f4f59d80f08d4ee0b07ea%7C72f988bf86f | > 141af91ab2d7cd011db47%7C1%7C0%7C636395178517098924&sdata=EOVdQbvvTDGP9 | > 2o8AHcVEcapHMicnVptxMCpwRPrsvE%3D&reserved=0

3 5

Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

Friends I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below It's complaining about a lock file being an invalid argument (see highlight below). If I manually remove the file I get past that, it successfully installs tf-random, but the same thing happens on the next package. So I can install packages one at a time, but that's silly. Any ideas? Simon cabal install alex Resolving dependencies... Configuring tf-random-0.5... Building tf-random-0.5... Failed to install tf-random-0.5 Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' Configuring tf-random-0.5... Building tf-random-0.5... Preprocessing library tf-random-0.5... [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o ) [2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] In the use of 'bitSize' (imported from Data.Bits): Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented" | ^^^^^^^ [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o ) [4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o ) Creating package registration file: /tmp/pkgConf-tf-random-05965166491189641421.5 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3mXYlHUEE5hzgewx Registering tf-random-0.5... cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' cabal: Error: some packages failed to install: QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. alex-3.2.1 depends on tf-random-0.5 which failed to install. tf-random-0.5 failed during the final install step. The exception was: ExitFailure 1 simonpj@cam-05-unx:~/code/HEAD$

5 11

Re: New primitive types?
by David Feuer 27 Aug '17

27 Aug '17

Atomic operations, or the lack thereof, don't seem terribly relevant to immutable Haskell constructor fields. David FeuerWell-Typed, LLP -------- Original message --------From: Carter Schonwald <carter.schonwald(a)gmail.com> Date: 8/26/17 10:56 PM (GMT-05:00) To: Florian Weimer <fw(a)deneb.enyo.de>, Michal Terepeta <michal.terepeta(a)gmail.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Re: New primitive types? Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer <fw(a)deneb.enyo.de> wrote: > * Michal Terepeta: > > > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < > carter.schonwald(a)gmail.com> > > wrote: > >> One issue with packed fields is that on many architectures you can't > > quite do subword reads or > >> writes. So it might not always be a win. > > > > Could you give any examples? > > Historic DEC Alpha, now long obsolete. > > It is very hard to create compliant and performant implementations of > Java 5, C 11 or C++ 11 on such architectures. All these languages > (and their subsequent revisions) require that naturally aligned > objects can be accessed independently. For example, you can't use a > simple read-modify-write cycle to implement a single-byte store using > word operations. > > That's why such architectures really do not have a future (or even a > present), except maybe in niche markets such as GPGPU (but even there, > things are heading towards the de-facto standard memory model). >

1 0

Tying knots with strict constructors
by David Feuer 27 Aug '17

27 Aug '17

Once in a while, one desires to tie a recursive knot and is stymied by a strict data constructor. I recently encountered this problem trying to improve the implementation of `never` in the `streaming` package. The Stream type is defined thus: data Stream f m r = Step !(f (Stream f m r)) | Effect (m (Stream f m r)) | Return r It would be nice to be able to write never :: Applicative f => Stream f m r never = fix (Step . pure) Unfortunately, if `pure` is strict (e.g., Identity), this won't work. The Step wrapper attempts to force `pure never` and then apply the Step worker. This will never work. The streaming package works around the problem by representing the `never` stream in a different way, at the potential cost of some efficiency. In other contexts, there may be no (safe) workaround at all. This is terribly frustrating, because it seems almost possible to express what I want in Core, and even possible to express it in Haskell with a really awful unsafeCoerce. The nasty version looks like this: data StreamL f m r = StepL (f (StreamL f m r)) | EffectL (m (StreamL f m r)) | ReturnL r never :: forall f m r. Applicative f => Stream f m r never = case loop of StepL x -> x `pseq` unsafeCoerce loop where loop :: StreamL f m r loop = StepL (pure loop) in loop {-# NOINLINE loop #-} {-# NOINLINE never #-} That is, I make a copy of the Stream type, but with a lazy version of the Step constructor, I tie my knot, I make very sure that the strict field is evaluated, and then I unsafeCoerce the whole thing in a thoroughly unsupported fashion to get back to the right type. Ideally, It would be nice to get GHC to manufacture, and expose to users, bidirectional patterns that offer more access to the raw representation of a type. Basically, I want to get a bidirectional pattern for Step that: 1. Is lazy when used as a constructor (applying the "worker" constructor directly) 2. Is viewed as lazy on matching, so the strictness analysis comes out right. Using such a feature will presumably always be dangerous (unless someone does a ton of work to find an efficient way to make it safe), but I'd rather have a reasonable dangerous way to do it than an unreasonable dangerous way, if that can be accomplished. Unfortunately, I haven't been able to think of a reasonable design for such a language feature. Does anyone else have any ideas? Or some other thought about how such things might be done? David

1 0

Where to raise an issue for the stm library
by Harendra Kumar 26 Aug '17

26 Aug '17

Can someone tell me where to raise an issue for the stm library? The hackage link sends me here http://git.haskell.org/packages/stm.git. But this page provides no clue on raising issues. I wondered if GHC trac itself is used for this library. I saw some other libraries in the drop down list but not this one in the GHC trac ticket creation page. It is frustrating that figuring out how to raise an issue is not easy for such an important library. -harendra

3 5