From rae at cs.brynmawr.edu Mon May 1 01:01:17 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 30 Apr 2017 21:01:17 -0400 Subject: validation failure on Mac Message-ID: <09D42053-7DCC-4F22-92CA-5D4482A89E44@cs.brynmawr.edu> Hi devs, Trying to validate with tonight's HEAD (+ my local changes) on a Mac yields libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:7: error: error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 [-Werror,-Wundef] | 22 | #elif HAVE_CLOCK_GETTIME | ^ #elif HAVE_CLOCK_GETTIME ^ libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:70:7: error: error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 [-Werror,-Wundef] | 70 | #elif HAVE_CLOCK_GETTIME | ^ #elif HAVE_CLOCK_GETTIME Is this related to the recent change from #ifdef to #if? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Mon May 1 01:10:07 2017 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 01 May 2017 01:10:07 +0000 Subject: validation failure on Mac In-Reply-To: <09D42053-7DCC-4F22-92CA-5D4482A89E44@cs.brynmawr.edu> References: <09D42053-7DCC-4F22-92CA-5D4482A89E44@cs.brynmawr.edu> Message-ID: It is related, see https://mail.haskell.org/pipermail/ghc-devs/2017-April/014055.html I did not check whether `time` has been updated yet. Cheers, Gabor Em seg, 1 de mai de 2017 às 03:01, Richard Eisenberg escreveu: > Hi devs, > > Trying to validate with tonight's HEAD (+ my local changes) on a Mac yields > > *libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:7: **error:* > * error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 > [-Werror,-Wundef]* > * |* > *22 |* #elif *H*AVE_CLOCK_GETTIME > * |** ^* > #elif HAVE_CLOCK_GETTIME > ^ > > *libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:70:7: **error:* > * error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0 > [-Werror,-Wundef]* > * |* > *70 |* #elif *H*AVE_CLOCK_GETTIME > * |** ^* > #elif HAVE_CLOCK_GETTIME > > Is this related to the recent change from #ifdef to #if? > > Thanks, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 1 02:05:55 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 30 Apr 2017 22:05:55 -0400 Subject: validation failure on Mac In-Reply-To: References: <09D42053-7DCC-4F22-92CA-5D4482A89E44@cs.brynmawr.edu> Message-ID: <878tmhe3gc.fsf@ben-laptop.smart-cactus.org> Gabor Greif writes: > It is related, see > > https://mail.haskell.org/pipermail/ghc-devs/2017-April/014055.html > > I did not check whether `time` has been updated yet. > I am indeed working on this. Unfortunately I have been unable to get Travis to build my branch due to unrelated reasons, so validating that my fix indeed fixes the issue has been a slow process. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Tue May 2 00:40:38 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 01 May 2017 20:40:38 -0400 Subject: validation failure on Mac In-Reply-To: <878tmhe3gc.fsf@ben-laptop.smart-cactus.org> References: <09D42053-7DCC-4F22-92CA-5D4482A89E44@cs.brynmawr.edu> <878tmhe3gc.fsf@ben-laptop.smart-cactus.org> Message-ID: <87ziewccqh.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > Gabor Greif writes: > >> It is related, see >> >> https://mail.haskell.org/pipermail/ghc-devs/2017-April/014055.html >> >> I did not check whether `time` has been updated yet. >> > I am indeed working on this. Unfortunately I have been unable to get > Travis to build my branch due to unrelated reasons, so validating that > my fix indeed fixes the issue has been a slow process. > For the record I've partially reverted the patch in question until we have a chance to get all of the necessary core library changes upstream. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue May 2 09:13:51 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 2 May 2017 09:13:51 +0000 Subject: forkprocess01 Message-ID: I got this on Linux in libraries/unix/tests Wrong exit code for forkprocess01(threaded1_ls)(expected 0 , actual 134 ) Stderr ( forkprocess01 ): forkprocess01: internal error: multiple ACQUIRE_LOCK: rts/Task.c 226 (GHC version 8.3.20170428 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted when validaiting. It worked fine when I said "make TEST=forkprocess01" (see below). I have no idea if this matters. Simon make TEST=forkprocess01 PYTHON="python3" "python3" ../../../testsuite/driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=True -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=1 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=True -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=False -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --configfile=../../../testsuite/config/ghc -e 'config.confdir="../../../testsuite/config"' -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-6/testsuite"' --config 'compiler="/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2"' --config 'ghc_pkg="/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-pkg"' --config 'haddock=' --config 'hp2ps="/5playpen/simonpj/HEAD-6/inplace/test spaces/hp2ps"' --config 'hpc="/5playpen/simonpj/HEAD-6/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../../../testsuite/timeout/install-inplace/bin/timeout"' -e "config.stage=2" \ --only=forkprocess01 \ \ \ \ \ \ Timeout is 300 Found 2 .T files... Beginning test run at Tue May 2 10:11:39 2017 BST ====> Scanning ./all.T ====> Scanning ./libposix/all.T =====> forkprocess01(normal) 1 of 1 [0, 0, 0] cd "./forkprocess01.run" && "/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "./forkprocess01.run" && ./forkprocess01 =====> forkprocess01(threaded1_ls) 1 of 1 [0, 0, 0] cd "./forkprocess01.run" && "/5playpen/simonpj/HEAD-6/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -package unix cd "./forkprocess01.run" && ./forkprocess01 +RTS -ls -RTS SUMMARY for test run started at Tue May 2 10:11:39 2017 BST 0:00:03 spent to go through 1 total tests, which gave rise to 8 test cases, of which 6 were skipped 0 had missing libraries 2 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures simonpj at cam-05-unx:~/5builds/HEAD-6/libraries/unix/tests$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Tue May 2 09:51:14 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Tue, 02 May 2017 09:51:14 +0000 Subject: [ANNOUNCE] GHC tarballs for Windows 10 Creators Update In-Reply-To: <8760i6hs8c.fsf@ben-laptop.smart-cactus.org> References: <878tn2idhj.fsf@ben-laptop.smart-cactus.org> <5875A40F-1FCD-4335-B3D8-C471772C7346@gmail.com> <8760i6hs8c.fsf@ben-laptop.smart-cactus.org> Message-ID: Ben Gamari schrieb am Sa., 15. Apr. 2017 um 12:37 Uhr: > Niklas Larsson writes: > > > Hi! > > > > That's great! I see that the download page at > > http://www.haskell.org/ghc/download still links to the old tarballs > > for 8.0.2. Will those links be updated? > > > Yes, they will in due time. > Looking at https://www.haskell.org/ghc/download_ghc_8_0_2#windows, I cannot find a GHC download compatible with the creators update. Has this been forgotten? Kind regards, Benno -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue May 2 13:05:48 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 02 May 2017 09:05:48 -0400 Subject: [ANNOUNCE] GHC tarballs for Windows 10 Creators Update In-Reply-To: References: <878tn2idhj.fsf@ben-laptop.smart-cactus.org> <5875A40F-1FCD-4335-B3D8-C471772C7346@gmail.com> <8760i6hs8c.fsf@ben-laptop.smart-cactus.org> Message-ID: <87pofrcssz.fsf@ben-laptop.smart-cactus.org> Benno Fünfstück writes: > Ben Gamari schrieb am Sa., 15. Apr. 2017 um 12:37 Uhr: > >> Niklas Larsson writes: >> >> > Hi! >> > >> > That's great! I see that the download page at >> > http://www.haskell.org/ghc/download still links to the old tarballs >> > for 8.0.2. Will those links be updated? >> > >> Yes, they will in due time. >> > > Looking at https://www.haskell.org/ghc/download_ghc_8_0_2#windows, I cannot > find a GHC download compatible with the creators update. Has this been > forgotten? > Not forgotten, just still in flight. I'll try to finish it up today. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu May 4 13:39:57 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 04 May 2017 09:39:57 -0400 Subject: Trac maintenance Message-ID: <87mvaskafm.fsf@ben-laptop.smart-cactus.org> Hello everyone, It has been brought to my attention that Trac has been exhibiting some odd behavior (in particular giving a strange error in place of a proper 404 message). If there's no objection I'll bring down Trac for a few minutes in about an hour in order to debug the issue. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From g9ks157k at acme.softbase.org Fri May 5 10:11:48 2017 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri, 05 May 2017 13:11:48 +0300 Subject: Weird problem involving untouchable type variables Message-ID: <1493979108.12756.113.camel@acme.softbase.org> Hi! My inquiry on the users mailing list about untouchable types did not get a reply. Maybe it is better to ask my question here. Today I encountered for the first time the notion of an untouchable type variable. I have no clue what this is supposed to mean. The error message that talked about a type variable being untouchable is unfounded in my opinion. A minimal example that exposes my problem is the following: > {-# LANGUAGE Rank2Types, TypeFamilies #-} >  > import GHC.Exts (Constraint) >  > type family F a b :: Constraint >  > data T b c = T >  > f :: (forall b . F a b => T b c) -> a > f _ = undefined This results in the following error message from GHC 8.0.1: > Untouchable.hs:9:6: error: >     • Couldn't match type ‘c0’ with ‘c’ >         ‘c0’ is untouchable >           inside the constraints: F a b >           bound by the type signature for: >                      f :: F a b => T b c0 >           at Untouchable.hs:9:6-37 >       ‘c’ is a rigid type variable bound by >         the type signature for: >           f :: forall a c. (forall b. F a b => T b c) -> a >         at Untouchable.hs:9:6 >       Expected type: T b c0 >         Actual type: T b c >     • In the ambiguity check for ‘f’ >       To defer the ambiguity check to use sites, enable AllowAmbiguousTypes >       In the type signature: >         f :: (forall b. F a b => T b c) -> a I have no idea what the problem is. The type of f looks fine to me. The type variable c should be universally quantified at the outermost level. Apparently, c is not related to the type family F at all. Why does the type checker even introduce a type variable c0? All the best, Wolfgang From vlad.z.4096 at gmail.com Fri May 5 11:12:11 2017 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Fri, 5 May 2017 14:12:11 +0300 Subject: Weird problem involving untouchable type variables In-Reply-To: <1493979108.12756.113.camel@acme.softbase.org> References: <1493979108.12756.113.camel@acme.softbase.org> Message-ID: I can reproduce this on GHC 8.2.1 and GHC HEAD as well. This looks like a bug in the ambiguity checker. Disabling it with -XAllowAmbiguousTypes, as GHC suggests, makes the error go away. Report it on GHC Trac [1]. As a work-around you could enable -XAllowAmbiguousTypes — it should be safe as it merely disables ambiguity checking, which is not necessary to ensure well-typedness. [1] https://ghc.haskell.org/trac/ghc/ On Fri, May 5, 2017 at 1:11 PM, Wolfgang Jeltsch wrote: > Hi! > > My inquiry on the users mailing list about untouchable types did not get > a reply. Maybe it is better to ask my question here. > > Today I encountered for the first time the notion of an untouchable type > variable. I have no clue what this is supposed to mean. The error > message that talked about a type variable being untouchable is unfounded > in my opinion. A minimal example that exposes my problem is the > following: > >> {-# LANGUAGE Rank2Types, TypeFamilies #-} >> >> import GHC.Exts (Constraint) >> >> type family F a b :: Constraint >> >> data T b c = T >> >> f :: (forall b . F a b => T b c) -> a >> f _ = undefined > > This results in the following error message from GHC 8.0.1: > >> Untouchable.hs:9:6: error: >> • Couldn't match type ‘c0’ with ‘c’ >> ‘c0’ is untouchable >> inside the constraints: F a b >> bound by the type signature for: >> f :: F a b => T b c0 >> at Untouchable.hs:9:6-37 >> ‘c’ is a rigid type variable bound by >> the type signature for: >> f :: forall a c. (forall b. F a b => T b c) -> a >> at Untouchable.hs:9:6 >> Expected type: T b c0 >> Actual type: T b c >> • In the ambiguity check for ‘f’ >> To defer the ambiguity check to use sites, enable AllowAmbiguousTypes >> In the type signature: >> f :: (forall b. F a b => T b c) -> a > > I have no idea what the problem is. The type of f looks fine to me. The > type variable c should be universally quantified at the outermost > level. Apparently, c is not related to the type family F at all. Why > does the type checker even introduce a type variable c0? > > All the best, > Wolfgang > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Fri May 5 20:20:43 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 05 May 2017 16:20:43 -0400 Subject: [GHC] #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused-pattern-binds In-Reply-To: <059.5b11e82fa2b022abded68abbfb5d987c@haskell.org> References: <044.32e35139f2ee897ece4f6184af2a605d@haskell.org> <059.5b11e82fa2b022abded68abbfb5d987c@haskell.org> Message-ID: <871ss3jbs4.fsf@ben-laptop.smart-cactus.org> GHC writes: > #13646: strict patterns with no bindings (e.g. `let !() = ...`) trigger -Wunused- > pattern-binds > -------------------------------------+------------------------------------- > Reporter: exphp | Owner: (none) > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 8.0.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Yes I see the point. Perhaps we should suppress this warning if the > pattern has an outmost bang. > > Does anyone object? Sounds reasonable to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From christiaan.baaij at gmail.com Mon May 8 13:56:59 2017 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 8 May 2017 15:56:59 +0200 Subject: GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions Message-ID: Hello GHC Devs, First some context: I'm using the GHC API to convert Haskell to digital circuit descriptions (clash compiler). When viewed as a structural description of a circuit, recursive let-bindings can be turned into feedback loops. In general, when viewed as a structural description of a circuit, recursive functions describe infinite hierarchy, i.e. they are not realisable as circuit. So now my problem: the simplifier turns recursive let-bindings to recursive functions; i.e. it is turning something which I can translate to a circuit to something which I cannot translate to a circuit. Next follows a reduced test case which exemplifies this behaviour: ``` import Control.Applicative topEntity :: [((),())] topEntity = (,) <$> outport1 <*> outport2 where (outport1, outResp1) = gpio (decodeReq 1 req) (outport2, outResp2) = gpio (decodeReq 2 req) ramResp = ram (decodeReq 0 req) req = core $ (<|>) <$> ramResp <*> ((<|>) <$> outResp1 <*> outResp2) {-# INLINE req #-} core :: [Maybe ()] -> [()] core = fmap (maybe () id) {-# NOINLINE core #-} ram :: [()] -> [Maybe ()] ram = fmap pure {-# NOINLINE ram #-} decodeReq :: Integer -> [()] -> [()] decodeReq 0 = fmap (const ()) decodeReq 1 = id decodeReq _ = fmap id {-# NOINLINE decodeReq #-} gpio :: [()] -> ([()],[Maybe ()]) gpio i = (i,pure <$> i) {-# NOINLINE gpio #-} ``` Now, when we look at the output of the desugarer (-ddump-ds), we can see that the core-level binder of `topEntity` basically follows the Haskell code. However, when we look at the simplifier output, with nearly all transformations disabled (-O0 -ddump-ds), you will see that parts of `topEntity` are split into 3 different top-level, mutually recursive, functions. So my question are: - Which part of the simplifier is turning these local recursive let-binders into global recursive functions? - Is there some way to disable this transformation? - If not, how much effort do you think it would be to put this behaviour behind a dynflag? So that I, as a GHC API user, can disable it for my use-case. I'm willing to implements this dynflag myself. Kind regards, Christiaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 8 14:12:27 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 08 May 2017 10:12:27 -0400 Subject: GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions In-Reply-To: References: Message-ID: <87pofjigj8.fsf@ben-laptop.smart-cactus.org> Christiaan Baaij writes: > Hello GHC Devs, > Hi! > So my question are: > - Which part of the simplifier is turning these local recursive let-binders > into global recursive functions? The simplifier does a bit of let floating. See Simplify.simplLazyBind and SimplEnv.doFloatFromRhs. I suspect this is what you are seeing. > - Is there some way to disable this transformation? You could try adding a flag which is checked by doFloatFromRhs. I'm not sure what, if anything, might break if you do so. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From christiaan.baaij at gmail.com Mon May 8 14:17:36 2017 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Mon, 8 May 2017 16:17:36 +0200 Subject: GHC API user: How to stop simplifier from turning recursive let-bindings into mutually recursive functions In-Reply-To: <87pofjigj8.fsf@ben-laptop.smart-cactus.org> References: <87pofjigj8.fsf@ben-laptop.smart-cactus.org> Message-ID: I've created a ticket for this at: https://ghc.haskell.org/trac/ghc/ticket/13663 On 8 May 2017 at 16:12, Ben Gamari wrote: > Christiaan Baaij writes: > > > Hello GHC Devs, > > > Hi! > > > So my question are: > > - Which part of the simplifier is turning these local recursive > let-binders > > into global recursive functions? > > The simplifier does a bit of let floating. See Simplify.simplLazyBind > and SimplEnv.doFloatFromRhs. I suspect this is what you are seeing. > > > - Is there some way to disable this transformation? > > You could try adding a flag which is checked by doFloatFromRhs. I'm not > sure what, if anything, might break if you do so. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon May 8 20:58:29 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 08 May 2017 16:58:29 -0400 Subject: GHC 8.2.1-rc2 source tarball availability References: <877ffpu3ax.fsf@smart-cactus.org> <87r3184xc2.fsf@ben-laptop.smart-cactus.org> Message-ID: <87a86nhxqi.fsf@ben-laptop.smart-cactus.org> tl;dr: If you would like to produce a binary distribution for GHC 8.2.1-rc2 then let me know, grab the source distribution and start building. The binary distributions will be announced one week from today. Hello GHC packagers, I am happy to announce the release of the 8.2.1-rc2 source distribution to binary packagers. You will find the usual source artifacts at http://downloads.haskell.org/~ghc/8.2.1-rc2/ As usual, the sooner we can get the binary distributions together the better, but I will hold off on announcing the distributions until next Sunday to ensure we're all on the same page. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let me know if you have any trouble building your distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone well. Note that in addition to the usual complement of Linux/Windows/Darwin bindists, I have also produced a FreeBSD distribution this time around. I've noticed that as my tools for producing these distributions improves the marginal cost of producing another distribution is shrinking. I would be happy to add OpenBSD as well, but first we'll need to nail #10032, as far as I understand. Good luck and thanks for all of your work! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue May 9 07:39:40 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 9 May 2017 07:39:40 +0000 Subject: Perf test failing: Trac #13668 Message-ID: Test perf/compiler/T9675 is failing (dramatically) for me. See https://ghc.haskell.org/trac/ghc/ticket/13668 Is it not failing for anyone else? Why does https://perf.haskell.org/ghc/ not show it up? Could someone (Reid?) track down which patch made it go bad? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue May 9 13:41:08 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 May 2017 09:41:08 -0400 Subject: Perf test failing: Trac #13668 In-Reply-To: References: Message-ID: <1494337268.1114.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 09.05.2017, 07:39 +0000 schrieb Simon Peyton Jones via ghc-devs: > Why does https://perf.haskell.org/ghc/ not show it up? I found that max_bytes_used perf tests are too unreliable and flaky, and add too much noise to the performance reports, so perf.haskell.org ignores these. Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Tue May 9 13:52:24 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 09 May 2017 09:52:24 -0400 Subject: Perf test failing: Trac #13668 In-Reply-To: References: Message-ID: <8760hai1d3.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Test perf/compiler/T9675 is failing (dramatically) for me. > See https://ghc.haskell.org/trac/ghc/ticket/13668 > Is it not failing for anyone else? > Why does https://perf.haskell.org/ghc/ not show it up? > Could someone (Reid?) track down which patch made it go bad? It was my "simplification" to Reid's patch, b3da6a6c3546562d5c5e83b8af5d3fd04c07e0c1, that regressed it. I still don't know why I didn't see this in my previous local testing, but I did start noticing it last night. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue May 9 19:37:12 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 09 May 2017 15:37:12 -0400 Subject: Hadrian status Message-ID: <871srxizyv.fsf@ben-laptop.smart-cactus.org> Hi Andrey, Given that 8.2.1 is finally starting to come together, now is probably a good time to start reflecting on what will come in 8.4. I think it would be great if we could finally get Hadrian into the tree for the 8.4 release. It would be even better if we could flip over to Hadrian as the primary build system. However, if we are to do this then I think we should leave plenty of time to iron out the inevitable bugs that will arise. Have you given much thought to the schedule post-8.2? Do you think a complete switch-over will be feasible? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From andrey.mokhov at newcastle.ac.uk Tue May 9 23:38:25 2017 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Tue, 9 May 2017 23:38:25 +0000 Subject: Hadrian status In-Reply-To: References: <871srxizyv.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben and all, I'm strongly in favour of switching GHC to Hadrian as soon as possible, because just keeping up with changes in GHC takes substantial effort. Zhen Zhang (in CC) has been recently helping me, and I hope he could make good progress towards this goal as part of his Summer of Haskell project (I believe he submitted an application). Switching will likely be a painful process for GHC developers, because some of the usual workflows will inevitably break. We could keep both Make and Hadrian in the tree for some period of time, but maintaining two completely different build systems is only feasible for a short period of time. Ben, Could I ask you to go through the open issues (https://github.com/snowleopard/hadrian/issues) and tag them with the 'tree-tremble' milestone if you think they must be implemented before the merge? I don't hack on GHC myself, so it's often difficult for me to judge the relative importance of features; it would be great if you could also tag the issues with priorities (I've just created tags high-/medium-/low-priority). Everyone: Please contribute to the discussions on the minimum set of features that Hadrian should support before it can replace Make in this thread: https://github.com/snowleopard/hadrian/issues/239. Cheers, Andrey -----Original Message----- From: Ben Gamari [mailto:ben at well-typed.com] Sent: 09 May 2017 21:37 To: Andrey Mokhov Cc: GHC developers Subject: Hadrian status Hi Andrey, Given that 8.2.1 is finally starting to come together, now is probably a good time to start reflecting on what will come in 8.4. I think it would be great if we could finally get Hadrian into the tree for the 8.4 release. It would be even better if we could flip over to Hadrian as the primary build system. However, if we are to do this then I think we should leave plenty of time to iron out the inevitable bugs that will arise. Have you given much thought to the schedule post-8.2? Do you think a complete switch-over will be feasible? Cheers, - Ben From moritz.angermann at gmail.com Wed May 10 05:43:12 2017 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Wed, 10 May 2017 13:43:12 +0800 Subject: GHC cross compilation survey results In-Reply-To: References: Message-ID: <4431C846-86DE-40C6-8FDB-20BF79ACE4A0@gmail.com> Dear friends, 20 days ago, together with obsidian.systems, we asked about cross compilation with GHC. A follow up with the result has been posted yesterday[1]. I’ll hope we can improve on many fronts and make building a cross compiling GHC as simple as ./configure --target=... --prefix=... [--disable-large-address-space] with GHC 8.4. I also plan on extending documentation on cross compiling, and maybe even provide pre-built cross compiles. I’ll plan to publish a few more posts regarding cross compiling in general and cross compiling with ghc specifically over the next few month at https://medium.com/@zw3rk. If you would like some more specific details of the survey, please feel free to contact me! Cheers, Moritz [1]: https://medium.com/@zw3rk/cross-compilation-survey-results-3988ad1b677b PS: I am building cross compilers for arm/raspberry pi, armv7/android, aarch64/android, aarch64/iOS, x86_64/iOS, all with limited* TH support as well as x86_64/macOS on a daily basis, and hope that this will ensure to a certain degree that master won’t break the cross compilers. *: without File IO (except for embedFile), and without Process IO. > On Apr 20, 2017, at 6:15 PM, Moritz Angermann wrote: > > Dear friends, > > as some of you might have noticed, together with > obsidian.systems, I’m trying to make cross compiling > GHC a bit easier. To that extend, I’d like to invite > you to fill out a short survey[1], so we understand > the needs of the community better. > > Please follow the attached link and fill out the > survey! > > Cheers, > Moritz > > [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029d7 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Thu May 11 00:06:32 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 10 May 2017 20:06:32 -0400 Subject: Hadrian status In-Reply-To: References: <871srxizyv.fsf@ben-laptop.smart-cactus.org> Message-ID: <87shkcgstz.fsf@ben-laptop.smart-cactus.org> Andrey Mokhov writes: > Hi Ben and all, > > I'm strongly in favour of switching GHC to Hadrian as soon as > possible, because just keeping up with changes in GHC takes > substantial effort. I can imagine; I feel like there has been even more build system churn in GHC than usually recently. > Zhen Zhang (in CC) has been recently helping me, and I hope he could > make good progress towards this goal as part of his Summer of Haskell > project (I believe he submitted an application). > Great, thanks for your effort Zhen! > Switching will likely be a painful process for GHC developers, because > some of the usual workflows will inevitably break. We could keep both > Make and Hadrian in the tree for some period of time, but maintaining > two completely different build systems is only feasible for a short > period of time. > I agree; ideally we will have switched over fully to Hadrian before the 8.4 release. > Could I ask you to go through the open issues > (https://github.com/snowleopard/hadrian/issues) and tag them with the > 'tree-tremble' milestone if you think they must be implemented before > the merge? I don't hack on GHC myself, so it's often difficult for me > to judge the relative importance of features; it would be great if you > could also tag the issues with priorities (I've just created tags > high-/medium-/low-priority). > I had a pass over the issues. The two things that stood out to me above all are * #250 (freezing stage 1): This is something that most GHC developers use on a daily basis. Working on GHC without this feature would be painful indeed. * #308 (document on debugging Hadrian): It will almost certainly be the case that developers will eventually encounter issues. If we have document describing how to start digging into these issues we will be less dependent on scarce resources such as yourself. I've marked these as high priority, milestoned to Tree Tremble. It would also be great to have #187 (validation support) resolved so we can start integration with GHC's CI infrastructure. I've also milestoned a number of things to ghc-quake, * #178 (LLVM toolchain) * #248 (Fix dynamicGhcPrograms) * #246 (build user's guide and man pages) I think that should pretty much cover it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From karel.gardas at centrum.cz Sun May 14 21:11:07 2017 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sun, 14 May 2017 23:11:07 +0200 Subject: GHC 8.2.1-rc2 source tarball availability In-Reply-To: <87a86nhxqi.fsf@ben-laptop.smart-cactus.org> References: <877ffpu3ax.fsf@smart-cactus.org> <87r3184xc2.fsf@ben-laptop.smart-cactus.org> <87a86nhxqi.fsf@ben-laptop.smart-cactus.org> Message-ID: <5918C7EB.1080705@centrum.cz> On 05/ 8/17 10:58 PM, Ben Gamari wrote: > Note that in addition to the usual complement of Linux/Windows/Darwin > bindists, I have also produced a FreeBSD distribution this time around. > I've noticed that as my tools for producing these distributions improves > the marginal cost of producing another distribution is shrinking. I > would be happy to add OpenBSD as well, but first we'll need to nail > #10032, as far as I understand. Hi Ben, the situation on OpenBSD is a little bit lucky than on Solaris since I'm not sure if this helps, but "system" libffi is in fact installed into /usr/local from ports and there is no other libffi on OpenBSD and this by probably lucky coincidence makes GHC working with the only quirk which is GNU tar complaining about missing header files while making binary-dist: "rm" -f bindistprep/ghc-8.2.0.20170507-x86_64-unknown-openbsd.tar cd bindistprep && "/usr/local/bin/gtar" hcf - -T ../bindist-list | /usr/local/bin/xz -c > ../bindistprep/ghc-8.2.0.20170507-x86_64-unknown-openbsd.tar.xz /usr/local/bin/gtar: ghc-8.2.0.20170507/rts/dist/build/ffi.h: Cannot stat: No such file or directory /usr/local/bin/gtar: ghc-8.2.0.20170507/rts/dist/build/ffitarget.h: Cannot stat: No such file or directory /usr/local/bin/gtar: Exiting with failure status due to previous errors mv bindistprep/*.tar.xz . anyway, tarbal is generated, it unpacks well, it even install well (with just ./configure --prefix=; gmake install) and resulting compiler is working and linked libffi is where it should be: $ ghc --make HelloWorld.lhs [1 of 1] Compiling Main ( HelloWorld.lhs, HelloWorld.o ) Linking HelloWorld ... /usr/local/build/karel/ghc-8.2.1-rc2/lib/ghc-8.2.0.20170507/rts/libHSrts.a(RtsFlags.o): In function `copyArg': rts/RtsFlags.c:1912:0: error: warning: warning: strcpy() is almost always misused, please use strlcpy() /usr/local/lib/libgmp.so.10.0: warning: warning: vsprintf() is often misused, please use vsnprintf() /usr/local/build/karel/ghc-8.2.1-rc2/lib/ghc-8.2.0.20170507/rts/libHSrts.a(RtsUtils.o): In function `showStgWord64': rts/RtsUtils.c:220:0: error: warning: warning: sprintf() is often misused, please use snprintf() $ ldd HelloWorld HelloWorld: Start End Type Open Ref GrpRef Name 00001116e2700000 00001116e29e7000 exe 2 0 0 HelloWorld 00001119d555b000 00001119d585a000 rlib 0 1 0 /usr/local/lib/libiconv.so.6.0 00001119b2138000 00001119b23af000 rlib 0 1 0 /usr/local/lib/libgmp.so.10.0 000011195fd4e000 000011195ff75000 rlib 0 1 0 /usr/lib/libm.so.10.0 000011197e36b000 000011197e573000 rlib 0 1 0 /usr/local/lib/libffi.so.1.2 0000111950004000 0000111950213000 rlib 0 2 0 /usr/lib/libpthread.so.23.0 00001119addd3000 00001119ae09e000 rlib 0 1 0 /usr/lib/libc.so.89.4 0000111980e00000 0000111980e00000 rtld 0 1 0 /usr/libexec/ld.so $ ./HelloWorld Hello world!$ so if you like you can give it a try on your OpenBSD. If you are using latest 6.1 please make sure you build and test on wxallowed mount: $ pwd /usr/local/build/karel/ghc-8.2.0.20170507 $ mount /dev/sd1a on / type ffs (local) /dev/sd1d on /usr/local type ffs (local, nodev, wxallowed) otherwise you would get strange "No permission error" while executing any GHC generated executable including tests run by ./configure. I.e. OpenBSD starts to be more picky about programs which execute code from writeable memory page and such security sinners need to be run from wxallowed paths only. Matthias Killian (cced) has done some work on GHC to fix that but IIRC he hit the wall somewhere in rts (IIRC) so nothing from this yet. Thanks, Karel From ben at well-typed.com Tue May 16 02:47:17 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 15 May 2017 22:47:17 -0400 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 Message-ID: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc2/ This is the second of what will likely be either two or three release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support This candidate fixes most of the issues present in release candidate one including, * #13233: typePrimRep panic while compiling GHC with profiling enabled * #13509: type error involving unboxed tuples * #13426: compile-time memory-usage regression * #13560: Windows binary distributions carry absolute paths to toolchain * #13585: Control.Lens.Wrapped.ala causes compiler panic * #13623: Join points produce bad code for stream fusion As always, please let us know if you have difficulty. Thanks to everyone who has contributed! Happy testing, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue May 16 13:55:30 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 May 2017 13:55:30 +0000 Subject: unix/tests failures Message-ID: Something is wrong with libraries/tests/unix. >From `sh validate -fast -no-clean` I get the pile of errors below. If I cd libraries/unix; make THREADS=20 it all works fine It's quite annoying. Any ideas? Simon Unexpected failures: T8308/T8308.run T8308 [bad stdout] (normal) libraries/unix/tests/user001.run user001 [bad exit code] (normal) libraries/unix/tests/forkprocess01.run forkprocess01 [exit code non-0] (threaded1_ls) libraries/unix/tests/getEnvironment01.run getEnvironment01 [bad exit code] (normal) libraries/unix/tests/T1185.run T1185 [bad exit code] (normal) libraries/unix/tests/processGroup001.run processGroup001 [bad exit code] (normal) libraries/unix/tests/fileStatusByteString.run fileStatusByteString [exit code non-0] (normal) libraries/unix/tests/fileStatus.run fileStatus [exit code non-0] (normal) libraries/unix/tests/T8108.run T8108 [bad exit code] (normal) libraries/unix/tests/libposix/posix009.run posix009 [exit code non-0] (normal) libraries/unix/tests/libposix/posix004.run posix004 [exit code non-0] (normal) libraries/unix/tests/libposix/posix010.run posix010 [exit code non-0] (normal) libraries/unix/tests/libposix/posix014.run posix014 [exit code non-0] (normal) libraries/unix/tests/libposix/posix003.run posix003 [exit code non-0] (normal) libraries/unix/tests/libposix/posix006.run posix006 [exit code non-0] (normal) libraries/unix/tests/libposix/posix005.run posix005 [exit code non-0] (normal) Framework failures: signals001 [duplicate] (There are multiple tests with this name) signals002 [duplicate] (There are multiple tests with this name) fileexist01 [duplicate] (There are multiple tests with this name) forkprocess01 [duplicate] (There are multiple tests with this name) user001 [duplicate] (There are multiple tests with this name) resourceLimit [duplicate] (There are multiple tests with this name) queryfdoption01 [duplicate] (There are multiple tests with this name) getEnvironment01 [duplicate] (There are multiple tests with this name) getEnvironment02 [duplicate] (There are multiple tests with this name) getGroupEntryForName [duplicate] (There are multiple tests with this name) getUserEntryForName [duplicate] (There are multiple tests with this name) signals004 [duplicate] (There are multiple tests with this name) fdReadBuf001 [duplicate] (There are multiple tests with this name) fileStatus [duplicate] (There are multiple tests with this name) fileStatusByteString [duplicate] (There are multiple tests with this name) T1185 [duplicate] (There are multiple tests with this name) T3816 [duplicate] (There are multiple tests with this name) processGroup001 [duplicate] (There are multiple tests with this name) processGroup002 [duplicate] (There are multiple tests with this name) executeFile001 [duplicate] (There are multiple tests with this name) T8108 [duplicate] (There are multiple tests with this name) posix002 [duplicate] (There are multiple tests with this name) posix003 [duplicate] (There are multiple tests with this name) posix004 [duplicate] (There are multiple tests with this name) posix005 [duplicate] (There are multiple tests with this name) posix006 [duplicate] (There are multiple tests with this name) posix009 [duplicate] (There are multiple tests with this name) posix010 [duplicate] (There are multiple tests with this name) posix014 [duplicate] (There are multiple tests with this name) libraries/unix/tests/forkprocess01.run forkprocess01 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/forkprocess01.run/forkprocess01.comp.stderr') libraries/unix/tests/user001.run user001 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/user001.run/user001.comp.stderr') libraries/unix/tests/getEnvironment01.run getEnvironment01 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/getEnvironment01.run/getEnvironment01.comp.stderr') libraries/unix/tests/T1185.run T1185 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/T1185.run/T1185.comp.stderr') libraries/unix/tests/processGroup001.run processGroup001 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/processGroup001.run/processGroup001.comp.stderr') libraries/unix/tests/fileStatus.run fileStatus [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/fileStatus.run/fileStatus.comp.stderr') libraries/unix/tests/fileStatusByteString.run fileStatusByteString [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/fileStatusByteString.run/fileStatusByteString.comp.stderr') libraries/unix/tests/T8108.run T8108 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/T8108.run/T8108.comp.stderr') libraries/unix/tests/libposix/posix009.run posix009 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix009.run/posix009.comp.stderr') libraries/unix/tests/libposix/posix004.run posix004 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix004.run/posix004.comp.stderr') libraries/unix/tests/libposix/posix010.run posix010 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix010.run/posix010.comp.stderr') libraries/unix/tests/libposix/posix014.run posix014 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix014.run/posix014.comp.stderr') libraries/unix/tests/libposix/posix003.run posix003 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix003.run/posix003.comp.stderr') libraries/unix/tests/libposix/posix005.run posix005 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix005.run/posix005.comp.stderr') libraries/unix/tests/libposix/posix006.run posix006 [normal] ([Errno 2] No such file or directory: '/tmp/ghctest-yu5pv2/test spaces/../../libraries/unix/tests/libposix/posix006.run/posix006.comp.stderr') The actual log has this kind of stuff cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment02.run" && ./getEnvironment02 =====> forkprocess01(normal) 5910 of 5908 [0, 1, 29] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/forkprocess01.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getGroupEntryForName.run" && ./getGroupEntryForName cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/ghc-compact/tests/compact_share.run" && ./compact_share +RTS -DS -RTS =====> user001(normal) 5911 of 5908 [0, 1, 29] Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) forkprocess01.hi: openBinaryFile: does not exist (No such file or directory) *** unexpected failure for forkprocess01(threaded1_ls) cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/user001.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o user001 user001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix =====> resourceLimit(normal) 5912 of 5908 [0, 2, 29] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/resourceLimit.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o resourceLimit resourceLimit.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix *** framework failure for forkprocess01(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/forkprocess01.run/forkprocess01.comp.stderr' =====> queryfdoption01(normal) 5913 of 5908 [0, 2, 30] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment01.run" && ./getEnvironment01 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/queryfdoption01.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o queryfdoption01 queryfdoption01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix =====> forkprocess01(threaded1_ls) 5913 of 5908 [0, 2, 30] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/forkprocess01.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o forkprocess01 forkprocess01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -package unix =====> getEnvironment01(normal) 5914 of 5908 [0, 2, 30] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment01.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o getEnvironment01 getEnvironment01.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/signals004.run" && ./signals004 Wrong exit code for getEnvironment01(normal)(expected 0 , actual 127 ) Stderr ( getEnvironment01 ): /bin/sh: 1: ./getEnvironment01: not found *** unexpected failure for getEnvironment01(normal) =====> getEnvironment02(normal) 5915 of 5908 [0, 3, 30] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment02.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o getEnvironment02 getEnvironment02.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix *** framework failure for getEnvironment01(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment01.run/getEnvironment01.comp.stderr' =====> getGroupEntryForName(normal) 5916 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getGroupEntryForName.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o getGroupEntryForName getGroupEntryForName.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/ghc-compact/tests/compact_gc.run" && ./compact_gc +RTS -DS -RTS cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup001.run" && ./processGroup001 =====> getUserEntryForName(normal) 5917 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getUserEntryForName.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o getUserEntryForName getUserEntryForName.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T1185.run" && ./T1185 =====> signals004(normal) 5918 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/signals004.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T3816.run" && ./T3816 =====> fdReadBuf001(ghci) 5919 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fdReadBuf001.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" fdReadBuf001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -package unix< fdReadBuf001.genscript =====> fileStatus(normal) 5920 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatus.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o fileStatus fileStatus.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/executeFile001.run" && ./executeFile001 =====> fileStatusByteString(normal) 5921 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatusByteString.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o fileStatusByteString fileStatusByteString.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix =====> T1185(normal) 5922 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T1185.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o T1185 T1185.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatus.run" && ./fileStatus =====> T3816(normal) 5923 of 5908 [0, 3, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T3816.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o T3816 T3816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( fileStatusByteString.hs, fileStatusByteString.o ) Linking fileStatusByteString ... /usr/bin/ld: reopening fileStatusByteString.o: No such file or directory /usr/bin/ld: final link failed: No such file or directory collect2: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** unexpected failure for fileStatusByteString(normal) =====> processGroup001(normal) 5924 of 5908 [0, 4, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup001.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o processGroup001 processGroup001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix002.run" && ./posix002 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T8108.run" && ./T8108 Wrong exit code for fileStatus(normal)(expected 0 , actual 127 ) Stderr ( fileStatus ): /bin/sh: 1: ./fileStatus: not found *** unexpected failure for fileStatus(normal) =====> processGroup002(normal) 5925 of 5908 [0, 5, 31] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup002.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o processGroup002 processGroup002.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup002.run" && ./processGroup002 *** framework failure for fileStatus(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatus.run/fileStatus.comp.stderr' =====> T8108(normal) 5927 of 5908 [0, 5, 32] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T8108.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o T8108 T8108.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix =====> executeFile001(normal) 5927 of 5908 [0, 5, 32] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/executeFile001.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o executeFile001 executeFile001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix *** framework failure for fileStatusByteString(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatusByteString.run/fileStatusByteString.comp.stderr' =====> posix002(normal) 5928 of 5908 [0, 5, 33] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix002.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix002 posix002.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/ghc-compact/tests/compact_bench.run" && ./compact_bench +RTS -DS -RTS 100 Wrong exit code for processGroup002(normal)(expected 0 , actual 127 ) Stderr ( processGroup002 ): /bin/sh: 1: ./processGroup002: not found *** unexpected failure for processGroup002(normal) =====> posix003(normal) 5929 of 5908 [0, 6, 33] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix003.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix003 posix003.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix009.run" && ./posix009 =====> posix004(normal) 5930 of 5908 [0, 6, 33] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix004.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix004 posix004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( posix003.hs, posix003.o ) Linking posix003 ... /usr/bin/ld: reopening posix003: No such file or directory /usr/bin/ld: final link failed: No such file or directory collect2: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** unexpected failure for posix003(normal) =====> posix005(normal) 5931 of 5908 [0, 7, 33] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix005.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix005 posix005.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix004.run" && ./posix004 *** framework failure for processGroup002(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup002.run/processGroup002.comp.stderr' cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix014.run" && ./posix014 =====> posix006(normal) 5932 of 5908 [0, 7, 34] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix006.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix006 posix006.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output *** framework failure for posix003(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix003.run/posix003.comp.stderr' Wrong exit code for posix004(normal)(expected 0 , actual 127 ) Stderr ( posix004 ): /bin/sh: 1: ./posix004: not found *** unexpected failure for posix004(normal) =====> posix009(normal) 5933 of 5908 [0, 8, 35] =====> posix010(normal) 5934 of 5908 [0, 8, 35] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix009.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix009 posix009.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix010.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix010 posix010.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output =====> posix014(normal) 5935 of 5908 [0, 8, 35] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix014.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o posix014 posix014.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( posix005.hs, posix005.o ) Linking posix005 ... /usr/bin/ld: reopening posix005: No such file or directory /usr/bin/ld: final link failed: No such file or directory collect2: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** unexpected failure for posix005(normal) cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/signals001.run" && ./signals001 Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/forkprocess01.run/forkprocess01.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment01.run/getEnvironment01.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatus.run/fileStatus.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileStatusByteString.run/fileStatusByteString.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup002.run/processGroup002.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix003.run/posix003.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix005.run/posix005.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix010.run" && ./posix010 Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( posix006.hs, posix006.o ) posix006.hs:8:11: warning: [-Wdeprecations (in -Wdefault)] In the use of 'sleep' (imported from System.Posix.Unistd): "This function has several shortcomings (see documentation). Please consider using Control.Concurrent.threadDelay instead." Linking posix006 ... /usr/bin/ld: reopening posix006: No such file or directory /usr/bin/ld: final link failed: No such file or directory collect2: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** unexpected failure for posix006(normal) cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/fileexist01.run" && ./fileexist01 *** framework failure for posix005(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix005.run/posix005.comp.stderr' *** framework failure for posix004(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix004.run/posix004.comp.stderr' Wrong exit code for posix010(normal)(expected 0 , actual 127 ) Stderr ( posix010 ): /bin/sh: 1: ./posix010: not found *** unexpected failure for posix010(normal) *** framework failure for posix006(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix006.run/posix006.comp.stderr' cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/signals002.run" && ./signals002 *** framework failure for posix010(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix010.run/posix010.comp.stderr' cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/resourceLimit.run" && ./resourceLimit cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/forkprocess01.run" && ./forkprocess01 +RTS -ls -RTS cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getGroupEntryForName.run" && ./getGroupEntryForName cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/queryfdoption01.run" && ./queryfdoption01 < queryfdoption01.stdin cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getEnvironment02.run" && ./getEnvironment02 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/getUserEntryForName.run" && ./getUserEntryForName cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/user001.run" && ./user001 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/signals004.run" && ./signals004 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/processGroup001.run" && ./processGroup001 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T1185.run" && ./T1185 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix002.run" && ./posix002 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/executeFile001.run" && ./executeFile001 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T3816.run" && ./T3816 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T8108.run" && ./T8108 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix009.run" && ./posix009 cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix014.run" && ./posix014 *** framework failure for T8108(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T8108.run/T8108.run.stdout' *** framework failure for posix009(normal) [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix009.run/posix009.run.stdout' =====> T7815(threaded1) 5936 of 5908 [0, 11, 41] cd "/tmp/ghctest-2h3hp8/test spaces/./rts/T7815.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o T7815 T7815.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "/tmp/ghctest-2h3hp8/test spaces/./rts/T7815.run" && ./T7815 50000 +RTS -N2 -RTS =====> T7653(normal) 5937 of 5908 [0, 11, 41] cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/base/tests/T7653.run" && "/5playpen/simonpj/HEAD-5/inplace/test spaces/ghc-stage2" -o T7653 T7653.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "/tmp/ghctest-2h3hp8/test spaces/../../libraries/base/tests/T7653.run" && ./T7653 File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix004.run/posix004.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix006.run/posix006.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1061, in compile_and_run__ result = simple_build(name, way, extra_hc_opts, 0, top_mod, 1, 1, backpack = backpack) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1203, in simple_build exit_code = runCmd(cmd, None, stdout, stderr, opts.compile_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix010.run/posix010.comp.stderr' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1068, in compile_and_run__ return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1268, in simple_run exit_code = runCmd(cmd, stdin, stdout, stderr, opts.run_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/T8108.run/T8108.run.stdout' Traceback (most recent call last): File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 768, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 852, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1071, in compile_and_run return compile_and_run__( name, way, '', [], extra_hc_opts) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1068, in compile_and_run__ return simple_run( name, way, cmd, getTestOpts().extra_run_opts ) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1268, in simple_run exit_code = runCmd(cmd, stdin, stdout, stderr, opts.run_timeout_multiplier) File "/home/simonpj/code/HEAD-5/testsuite/driver/testlib.py", line 1831, in runCmd with io.open(stdout, 'wb') as f: IOError: [Errno 2] No such file or directory: '/tmp/ghctest-2h3hp8/test spaces/../../libraries/unix/tests/libposix/posix009.run/posix009.run.stdout' -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Tue May 16 14:15:19 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 16 May 2017 10:15:19 -0400 Subject: unix/tests failures In-Reply-To: References: Message-ID: <8737c4ga6g.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Something is wrong with libraries/tests/unix. > From `sh validate -fast -no-clean` I get the pile of errors below. > If I cd libraries/unix; make THREADS=20 it all works fine > It's quite annoying. Any ideas? Hmm, what does `git clean -nfd` say (perhaps try both in libraries/unix and the root of the tree)? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From cma at bitemyapp.com Tue May 16 18:08:42 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 16 May 2017 13:08:42 -0500 Subject: 8.2 and earlier build times Message-ID: I did a build time test with hackage.haskell.org/package/bloodhound today. I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part because it has very few but very large modules which is sort of a pathological case for GHC right now. I first built the deps and library with each compilers and then reran the build once or twice until the results stabilized. The build re-built the V5/Types module and the examples depending on that module. I triggered a build by adding/removing newline characters in the V5/Types module. I've pushed the build targets / stack.yamls to the git repository: https://github.com/bitemyapp/bloodhound Here are the results: 8.2 build: 126.37s user 2.26s system 101% cpu 2:07.16 total 8.0 build: 147.44s user 2.24s system 100% cpu 2:28.93 total 7.10 build: 163.38s user 2.14s system 100% cpu 2:44.64 total 7.8 build: 129.12s user 2.30s system 101% cpu 2:10.09 total Please let me know if you have any questions. -- Chris Allen Currently working on http://haskellbook.com From ben at well-typed.com Tue May 16 18:19:29 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 16 May 2017 14:19:29 -0400 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: <20170516171548.GA9248@x4> References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> <20170516171548.GA9248@x4> Message-ID: <87pof8ekb2.fsf@ben-laptop.smart-cactus.org> Markus Trippelsdorf writes: > On 2017.05.15 at 22:47 -0400, Ben Gamari wrote: >> >> >> The GHC team is very pleased to announce the second candidate of the >> 8.2.1 release of the Glasgow Haskell Compiler. Source and binary >> distributions are available at >> >> https://downloads.haskell.org/~ghc/8.2.1-rc2/ >> >> This is the second of what will likely be either two or three release >> candidates leading up the final 8.2.1 release. This release will >> feature, >> >> As always, please let us know if you have difficulty. Thanks to everyone >> who has contributed! >> >> Happy testing, > > Unfortunately xmobar segfaults from time to time when build with > 8.2.1-rc2, e.g.: > Thanks for your report! Segfaults are certainly no good. Do you know whether these are also reproducible with rc1? What version of xmobar are you using? What does your configuration look like? I've started an xmobar built from upstream's master branch with an empty configuration to see whether this is reproducible locally. I've opened #13707 to track this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From timmcgil at gmail.com Tue May 16 21:40:02 2017 From: timmcgil at gmail.com (Tim McGilchrist) Date: Wed, 17 May 2017 07:40:02 +1000 Subject: 8.2 and earlier build times In-Reply-To: References: Message-ID: Very interesting, that would suggest there is some improvement in build times. I want to test out compile times with each of those compilers on our pathological worst case dependency amazonka ( https://github.com/brendanhay/amazonka) and a library we've built on top of it mismi ( https://github.com/ambiata/mismi) today. The code in both have a lot of derivings for data types which seems to be one of the slowest parts. I'm not that conversant with stack as a tool but were these compile times with optimisations on / off? On Wed, May 17, 2017 at 4:08 AM, Christopher Allen wrote: > I did a build time test with hackage.haskell.org/package/bloodhound today. > > I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part > because it has very few but very large modules which is sort of a > pathological case for GHC right now. > > I first built the deps and library with each compilers and then reran > the build once or twice until the results stabilized. The build > re-built the V5/Types module and the examples depending on that > module. I triggered a build by adding/removing newline characters in > the V5/Types module. > > I've pushed the build targets / stack.yamls to the git repository: > https://github.com/bitemyapp/bloodhound > > > Here are the results: > > > 8.2 build: > 126.37s user 2.26s system 101% cpu 2:07.16 total > > 8.0 build: > 147.44s user 2.24s system 100% cpu 2:28.93 total > > 7.10 build: > 163.38s user 2.14s system 100% cpu 2:44.64 total > > 7.8 build: > 129.12s user 2.30s system 101% cpu 2:10.09 total > > > Please let me know if you have any questions. > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at mistersg.net Wed May 17 01:02:22 2017 From: sean at mistersg.net (Sean Gillespie) Date: Tue, 16 May 2017 21:02:22 -0400 Subject: Newcomer help (Trac #12056) Message-ID: <20170517010222.GA8779@sean-archlinux-2> Howdy, I started looking at Trac #12056 (https://ghc.haskell.org/trac/ghc/ticket/12056), but I'm a bit stuck. Indeed, if I run the following command, I get no warnings ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wbar But if I also specify -Wdeprecated-flags, I get warnings again ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wdeprecated-flags -Wbar on the commandline: warning: unrecognised warning flag: -Wfoo on the commandline: warning: unrecognised warning flag: -Wbar Then I found this little function in compiler/main/HscTypes handleFlagWarnings :: DynFlags -> [Located String] -> IO () handleFlagWarnings dflags warns = when (wopt Opt_WarnDeprecatedFlags dflags) $ do -- It would be nicer if warns :: [Located MsgDoc], but that -- has circular import problems. let bag = listToBag [ mkPlainWarnMsg dflags loc (text warn) | L loc warn <- warns ] printOrThrowWarnings dflags bag So I updated it accept Opt_WarnDeprecatedFlags and Opt_WarnUnrecognisedWarningsFlags. Complete patch here: https://phabricator.haskell.org/D3581 Unfortunately when I did that, -Wno-deprecated-flags no longer had an effect so long as -Wunrecognised-warnings-flags ./inplace/bin/ghc-stage2 -Wunrecognised-warning-flags -Wno-deprecated-flags -XOverlappingInstances on the commandline: warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS And now that is where I'm stuck; I can't seem to find a place where I can distinguish between the different warning types. Even WarnReason is set to NoReason because of the usage of mkPlainWarnMsg. So if I could get some guidance on this, I'd be very grateful. Thanks Sean G From simonpj at microsoft.com Wed May 17 08:56:18 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 17 May 2017 08:56:18 +0000 Subject: 8.2 and earlier build times In-Reply-To: References: Message-ID: That's great news! Faster than GHC 7.8! We should advertise this :-). Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Christopher Allen | Sent: 16 May 2017 19:09 | To: ghc-devs at haskell.org | Subject: 8.2 and earlier build times | | I did a build time test with hackage.haskell.org/package/bloodhound | today. | | I tested 8.2 (RC), 8.0, 7.10, and 7.8. I used Bloodhound in part | because it has very few but very large modules which is sort of a | pathological case for GHC right now. | | I first built the deps and library with each compilers and then reran | the build once or twice until the results stabilized. The build re- | built the V5/Types module and the examples depending on that module. I | triggered a build by adding/removing newline characters in the | V5/Types module. | | I've pushed the build targets / stack.yamls to the git repository: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fbitemyapp%2Fbloodhound&data=02%7C01%7Csimonpj%40microsoft.com% | 7Cc4d32126857a47dd4dd008d49c86aa7c%7C72f988bf86f141af91ab2d7cd011db47% | 7C1%7C0%7C636305549597208612&sdata=kcqWLIARzF8xwaYwZgJ6vOkex1%2FtD53cB | %2BJlYcdnq2o%3D&reserved=0 | | | Here are the results: | | | 8.2 build: | 126.37s user 2.26s system 101% cpu 2:07.16 total | | 8.0 build: | 147.44s user 2.24s system 100% cpu 2:28.93 total | | 7.10 build: | 163.38s user 2.14s system 100% cpu 2:44.64 total | | 7.8 build: | 129.12s user 2.30s system 101% cpu 2:10.09 total | | | Please let me know if you have any questions. | | -- | Chris Allen | Currently working on | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskel | lbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7Cc4d32126857a47dd4dd | 008d49c86aa7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63630554959 | 7208612&sdata=vVpn%2FeGOPMspkvoj9SRl2nvc1CIpE0lZbnXYhyTu%2B9Y%3D&reser | ved=0 | _______________________________________________ | ghc-devs mailing list | ghc-devs at 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%7Csimonpj%40microsoft.com%7Cc4d32126857a47dd4dd008d4 | 9c86aa7c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363055495972086 | 12&sdata=G7cskVvK6Gp7mGLxGbSFPHm4MAQqav69A8PftobVsLE%3D&reserved=0 From george.colpitts at gmail.com Wed May 17 11:52:32 2017 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 17 May 2017 11:52:32 +0000 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben I built from source and ran the tests on my Mac and found some problems. I'm not sure if the failing tests have been ran successfully by others on this platform. I did "make slowtest". Maybe the problem only happens on my machine. I'm new to running the testsuite and not sure how the sleep settings on my computer affect long running computations. - If I want to run a long running test such as "make slowtest" overnight will my computer go to sleep preventing the test from running? i.e. should I invoke it with something like "caffeinate -i make slowtest" ? I almost didn't run the tests assuming they had been run as part of the release process but then I guessed that maybe slowtest had not been run. It would be a pain but would it be worth documenting which tests had been run on which platforms? I assume I should file a bug for the following? make TEST=dynamic-paper WAY=profasm ... =====> dynamic-paper(profasm) 1 of 1 [0, 0, 0] cd "./dependent/should_compile/dynamic-paper.run" && "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 143842 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(profasm) Unexpected results from: TEST="dynamic-paper" SUMMARY for test run started at Wed May 17 08:19:59 2017 ADT 0:00:06 spent to go through 1 total tests, which gave rise to 5 test cases, of which 4 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) It fails with -fsimpl-tick-factor=1000 also: make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000' ... cd "./dependent/should_compile/dynamic-paper.run" && "/Users/gcolpitts/Downloads/ghc-8.2.0.20170507/inplace/bin/ghc-stage2" -c dynamic-paper.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fsimpl-tick-factor=1000 -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 1438402 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for dynamic-paper(profasm) Unexpected results from: TEST="dynamic-paper" SUMMARY for test run started at Wed May 17 08:29:43 2017 ADT 0:00:35 spent to go through 1 total tests, which gave rise to 5 test cases, of which 4 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: dependent/should_compile/dynamic-paper.run dynamic-paper [exit code non-0] (profasm) Cheers George On Mon, May 15, 2017 at 11:48 PM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very pleased to announce the second candidate of the > 8.2.1 release of the Glasgow Haskell Compiler. Source and binary > distributions are available at > > https://downloads.haskell.org/~ghc/8.2.1-rc2/ > > This is the second of what will likely be either two or three release > candidates leading up the final 8.2.1 release. This release will > feature, > > * A new type-indexed Typeable implementation > > * The long awaited Backpack > > * Deriving strategies for disambiguating DeriveAnyClass, > GeneralizedNewtypeDeriving, and stock mechanisms > > * Overloaded record fields > > * Improved compiler performance > > * Better code generation through more robust tracking of join points > > * Compact regions for more efficient garbage collection and serialization > > * Better support for machines with non-uniform memory architectures > > * More robust support for levity (e.g. RuntimeRep) polymorphism > > * A simple interface for streaming eventlog data from live processes > > * Further refinement of DWARF support > > This candidate fixes most of the issues present in release candidate > one including, > > * #13233: typePrimRep panic while compiling GHC with profiling enabled > * #13509: type error involving unboxed tuples > * #13426: compile-time memory-usage regression > * #13560: Windows binary distributions carry absolute paths to toolchain > * #13585: Control.Lens.Wrapped.ala causes compiler panic > * #13623: Join points produce bad code for stream fusion > > As always, please let us know if you have difficulty. Thanks to everyone > who has contributed! > > Happy testing, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed May 17 13:26:34 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 17 May 2017 09:26:34 -0400 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> Message-ID: <87lgpvehrp.fsf@ben-laptop.smart-cactus.org> George Colpitts writes: > Hi Ben > > I built from source and ran the tests on my Mac and found some > problems. I'm not sure if the failing tests have been ran successfully > by others on this platform. I did "make slowtest". Maybe the problem > only happens on my machine. > Currently Harbormaster only runs `make test`, not `make slowtest`. Consequently, `slowtest` is generally rather broken, even on Linux. Every once in a while I look at it and try to pare down the failures, but it's an up-hill battle. > I'm new to running the testsuite and not sure how the sleep settings on my > computer affect long running computations. > > - If I want to run a long running test such as "make slowtest" overnight > will my computer go to sleep preventing the test from running? i.e. should > I invoke it with something like "caffeinate -i make slowtest" ? > That sounds right to me. > I almost didn't run the tests assuming they had been run as part of the > release process but then I guessed that maybe slowtest had not been run. It > would be a pain but would it be worth documenting which tests had been run > on which platforms? > I currently don't validate the binary distribution tarballs. Instead I judge validation state from Harbormaster's testing of the ghc-8.2 branch. Over the summer we intend on revamping our CI infrastructure, which should make it easier to do nightly runs of slowtest (and perhaps provide nightly or even per-commit binary distributions). > I assume I should file a bug for the following? > That would be great. I had a quick look at this and it looks quite likely that the simplifier is looping: even -fsimpl-tick-factor=1000 doesn't succeed. This looks like a real regression. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Wed May 17 16:44:10 2017 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 17 May 2017 16:44:10 +0000 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: <87lgpvehrp.fsf@ben-laptop.smart-cactus.org> References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> <87lgpvehrp.fsf@ben-laptop.smart-cactus.org> Message-ID: Yes, I agree, will file a bug this evening. On Wed, May 17, 2017 at 10:26 AM Ben Gamari wrote: > George Colpitts writes: > > > Hi Ben > > > > I built from source and ran the tests on my Mac and found some > > problems. I'm not sure if the failing tests have been ran successfully > > by others on this platform. I did "make slowtest". Maybe the problem > > only happens on my machine. > > > Currently Harbormaster only runs `make test`, not `make slowtest`. > Consequently, `slowtest` is generally rather broken, even on Linux. > Every once in a while I look at it and try to pare down the failures, > but it's an up-hill battle. > > > I'm new to running the testsuite and not sure how the sleep settings on > my > > computer affect long running computations. > > > > - If I want to run a long running test such as "make slowtest" > overnight > > will my computer go to sleep preventing the test from running? i.e. > should > > I invoke it with something like "caffeinate -i make slowtest" ? > > > That sounds right to me. > > > I almost didn't run the tests assuming they had been run as part of the > > release process but then I guessed that maybe slowtest had not been run. > It > > would be a pain but would it be worth documenting which tests had been > run > > on which platforms? > > > I currently don't validate the binary distribution tarballs. Instead I > judge validation state from Harbormaster's testing of the ghc-8.2 > branch. > > Over the summer we intend on revamping our CI infrastructure, which > should make it easier to do nightly runs of slowtest (and perhaps > provide nightly or even per-commit binary distributions). > > > I assume I should file a bug for the following? > > > That would be great. I had a quick look at this and it looks quite > likely that the simplifier is looping: even -fsimpl-tick-factor=1000 > doesn't succeed. This looks like a real regression. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed May 17 18:11:55 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 17 May 2017 20:11:55 +0200 Subject: 8.2 and earlier build times In-Reply-To: References: Message-ID: On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs wrote: > That's great news! Faster than GHC 7.8! We should advertise this :-). However, not everything is back to 7.8 levels when looking at the time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably similar versions of dependencies): GHC 7.8.4: <> GHC 7.10.3: <> GHC 8.0.2: <> GHC 8.2.1: <> So GHC 8.2.1 seems to have traded memory-in-use (significantly less than 7.8) for compile-time (significantly more than 7.8). From ben at smart-cactus.org Wed May 17 19:11:16 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 May 2017 15:11:16 -0400 Subject: Newcomer help (Trac #12056) In-Reply-To: <20170517010222.GA8779@sean-archlinux-2> References: <20170517010222.GA8779@sean-archlinux-2> Message-ID: <87efvne1t7.fsf@ben-laptop.smart-cactus.org> Sean Gillespie writes: > Howdy, > Hi Sean, > I started looking at Trac #12056 (https://ghc.haskell.org/trac/ghc/ticket/12056), > but I'm a bit stuck. Thanks for looking into this! > > Indeed, if I run the following command, I get no warnings > > ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wbar > > But if I also specify -Wdeprecated-flags, I get warnings again > > ghc Main.hs -Wfoo -w -Wunrecognised-warning-flags -Wdeprecated-flags -Wbar > > on the commandline: warning: unrecognised warning flag: -Wfoo > > on the commandline: warning: unrecognised warning flag: -Wbar > > Then I found this little function in compiler/main/HscTypes > > handleFlagWarnings :: DynFlags -> [Located String] -> IO () > handleFlagWarnings dflags warns > = when (wopt Opt_WarnDeprecatedFlags dflags) $ do > -- It would be nicer if warns :: [Located MsgDoc], but that > -- has circular import problems. > let bag = listToBag [ mkPlainWarnMsg dflags loc (text warn) > | L loc warn <- warns ] > > printOrThrowWarnings dflags bag > > So I updated it accept Opt_WarnDeprecatedFlags and Opt_WarnUnrecognisedWarningsFlags. > Complete patch here: https://phabricator.haskell.org/D3581 > > Unfortunately when I did that, -Wno-deprecated-flags no longer had an effect so long > as -Wunrecognised-warnings-flags > > ./inplace/bin/ghc-stage2 -Wunrecognised-warning-flags -Wno-deprecated-flags -XOverlappingInstances > > on the commandline: warning: > -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS > > And now that is where I'm stuck; I can't seem to find a place where I can distinguish > between the different warning types. Even WarnReason is set to NoReason because of > the usage of mkPlainWarnMsg. > Sorry for the late response; this ended up being quite a rabbit-hole. In general I see relatively few really good solutions here. Ideally we would make the warnings produced by the DynFlags parser proper MsgDocs, as the comment in handleFlagWarnings suggests. However, the comment isn't quite accurate: the reason for not using MsgDoc here isn't just import loops; you also need to have DynFlags in order to construct a MsgDoc (see the smart constructors in ErrUtils). This requirement is something we might be able to hack around in the case of flag errors by simply using some "generic" DynFlags, but I'm not sure that the payoff of doing so is all that great. It seems to me like we should rather stick with the current approach of not using MsgDoc. Instead, we should augment the warnings returned from the DynFlags parser with enough information so we can filter them out later if necessary. This might either be by including a WarnReason with each Located String, or possibly returning Opt_WarnDeprecatedFlags and Opt_WarnUnrecognizedWarningsFlags warnings in separate lists. I tend to think the former would be cleaner. I hope this helps. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Wed May 17 20:15:36 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 17 May 2017 16:15:36 -0400 Subject: 8.2 and earlier build times In-Reply-To: References: Message-ID: <87a86bdytz.fsf@ben-laptop.smart-cactus.org> Herbert Valerio Riedel writes: > On Wed, May 17, 2017 at 10:56 AM, Simon Peyton Jones via ghc-devs > wrote: >> That's great news! Faster than GHC 7.8! We should advertise this :-). > > However, not everything is back to 7.8 levels when looking at the > time-dimension, e.g. for regex-tdfa-1.2.2 (with reasonably similar > versions of dependencies): > Interesting. I tried comparing build times of regex-tdfa-1.1.8 with GHC 8.0.2 and 8.2.1, yet was unable to reproduce this. Rather 8.2 was significantly faster than 8.0.2 (although not in the profiled build, it seems), 8.0.2: real 2m4.403s user 0m2.233s sys 4m49.319s normal build: <> profiled build: <> 8.2.1-rc2: real 1m37.004s user 0m1.690s sys 4m22.921s normal build: <> profiled build: <> My methodology was roughly, $ cabal unpack regex-tdfa-1.1.8 $ cd regex-tdfa-1.1.8 $ use_component ghc 8.0.2 $ cabal configure ; time cabal build --ghc-options='-fforce-recomp -v +RTS -t -RTS' >| 8.0.2 2>&1 $ use_component ghc 8.2.1-rc2 $ cabal configure ; time cabal build --ghc-options='-fforce-recomp -v +RTS -t -RTS' >| 8.2.1 2>&1 The "normal" and "profiled" build metrics are the +RTS -t lines extract from Cabal's profiled and unprofiled GHC invocations. I believe the RTS timings for 8.0.2 are broken due to a (fixed) RTS bug, although I can't come up with a reference at the moment. Herbert, did these timings come from a VPS? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Wed May 17 22:01:26 2017 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 17 May 2017 22:01:26 +0000 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> <87lgpvehrp.fsf@ben-laptop.smart-cactus.org> Message-ID: Done: https://ghc.haskell.org/trac/ghc/ticket/13715#ticket On Wed, May 17, 2017 at 1:44 PM George Colpitts wrote: > Yes, I agree, will file a bug this evening. > > On Wed, May 17, 2017 at 10:26 AM Ben Gamari wrote: > >> George Colpitts writes: >> >> > Hi Ben >> > >> > I built from source and ran the tests on my Mac and found some >> > problems. I'm not sure if the failing tests have been ran successfully >> > by others on this platform. I did "make slowtest". Maybe the problem >> > only happens on my machine. >> > >> Currently Harbormaster only runs `make test`, not `make slowtest`. >> Consequently, `slowtest` is generally rather broken, even on Linux. >> Every once in a while I look at it and try to pare down the failures, >> but it's an up-hill battle. >> >> > I'm new to running the testsuite and not sure how the sleep settings on >> my >> > computer affect long running computations. >> > >> > - If I want to run a long running test such as "make slowtest" >> overnight >> > will my computer go to sleep preventing the test from running? i.e. >> should >> > I invoke it with something like "caffeinate -i make slowtest" ? >> > >> That sounds right to me. >> >> > I almost didn't run the tests assuming they had been run as part of the >> > release process but then I guessed that maybe slowtest had not been >> run. It >> > would be a pain but would it be worth documenting which tests had been >> run >> > on which platforms? >> > >> I currently don't validate the binary distribution tarballs. Instead I >> judge validation state from Harbormaster's testing of the ghc-8.2 >> branch. >> >> Over the summer we intend on revamping our CI infrastructure, which >> should make it easier to do nightly runs of slowtest (and perhaps >> provide nightly or even per-commit binary distributions). >> >> > I assume I should file a bug for the following? >> > >> That would be great. I had a quick look at this and it looks quite >> likely that the simplifier is looping: even -fsimpl-tick-factor=1000 >> doesn't succeed. This looks like a real regression. >> >> Cheers, >> >> - Ben >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu May 18 07:04:58 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 18 May 2017 09:04:58 +0200 Subject: Type families and classes Message-ID: Hi all I am experimenting with Trees that Grow [1] in the context of the GHC HsSyn AST, and wanting to express that a given extension point needs to have certain properties. The specific case is to be able to contain a SourceText, in the context of HsLit So I have (stripped down) data GHCX type family XHsString x type instance XHsString GHCX = SourceText class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a getSourceText :: a -> SourceText instance HasSourceText (XHsString GHCX) where noSourceText = NoSourceText sourceText s = SourceText s getSourceText a = a But this gives an error compiler/hsSyn/HsExtension.hs:80:10: error: • Illegal type synonym family application in instance: XHsString GHCX • In the instance declaration for ‘HasSourceText (XHsString GHCX)’ Is there some way to achieve this, or is it simply impossible? The full work-in-progress source is here[2] Regards Alan [1] https://arxiv.org/abs/1610.04799 [2] https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793f19e758977/compiler/hsSyn/HsExtension.hs#L73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu May 18 07:15:21 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 18 May 2017 09:15:21 +0200 Subject: Type families and classes In-Reply-To: References: Message-ID: And to answer my own question, it seems instance HasSourceText SourceText where noSourceText = NoSourceText sourceText s = SourceText s getSourceText a = a And then applying the appropriate constraint at the use-site does the job. So noSyntaxExpr :: (HasSourceText (XHsString x)) => SyntaxExpr x id Alan On 18 May 2017 at 09:04, Alan & Kim Zimmerman wrote: > Hi all > > I am experimenting with Trees that Grow [1] in the context of the GHC > HsSyn AST, and wanting to express that a given extension point needs to > have certain properties. > > The specific case is to be able to contain a SourceText, in the context of > HsLit > > So I have (stripped down) > > data GHCX > > type family XHsString x > > type instance XHsString GHCX = SourceText > > class HasSourceText a where > -- Provide setters to mimic existing constructors > noSourceText :: a > sourceText :: String -> a > > getSourceText :: a -> SourceText > > instance HasSourceText (XHsString GHCX) where > noSourceText = NoSourceText > sourceText s = SourceText s > getSourceText a = a > > > But this gives an error > > compiler/hsSyn/HsExtension.hs:80:10: error: > • Illegal type synonym family application in instance: > XHsString GHCX > • In the instance declaration for ‘HasSourceText (XHsString GHCX)’ > > Is there some way to achieve this, or is it simply impossible? > > The full work-in-progress source is here[2] > > Regards > Alan > > > [1] https://arxiv.org/abs/1610.04799 > [2] https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793 > f19e758977/compiler/hsSyn/HsExtension.hs#L73 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 18 07:56:06 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 May 2017 07:56:06 +0000 Subject: Type families and classes In-Reply-To: References: Message-ID: Yes that looks right. A class instance can’t dispatch on a type family application. In haskell we don’t allow reverse (a ++ b) = reverse a ++ reverse b and it’s the same for type families and class instances. You should do the type-family reduction yourself, as you do below. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 18 May 2017 08:15 To: ghc-devs at haskell.org Subject: Re: Type families and classes And to answer my own question, it seems instance HasSourceText SourceText where noSourceText = NoSourceText sourceText s = SourceText s getSourceText a = a And then applying the appropriate constraint at the use-site does the job. So noSyntaxExpr :: (HasSourceText (XHsString x)) => SyntaxExpr x id Alan On 18 May 2017 at 09:04, Alan & Kim Zimmerman > wrote: Hi all I am experimenting with Trees that Grow [1] in the context of the GHC HsSyn AST, and wanting to express that a given extension point needs to have certain properties. The specific case is to be able to contain a SourceText, in the context of HsLit So I have (stripped down) data GHCX type family XHsString x type instance XHsString GHCX = SourceText class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a getSourceText :: a -> SourceText instance HasSourceText (XHsString GHCX) where noSourceText = NoSourceText sourceText s = SourceText s getSourceText a = a But this gives an error compiler/hsSyn/HsExtension.hs:80:10: error: • Illegal type synonym family application in instance: XHsString GHCX • In the instance declaration for ‘HasSourceText (XHsString GHCX)’ Is there some way to achieve this, or is it simply impossible? The full work-in-progress source is here[2] Regards Alan [1] https://arxiv.org/abs/1610.04799 [2] https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793f19e758977/compiler/hsSyn/HsExtension.hs#L73 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at mpg.is Thu May 18 12:55:11 2017 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Thu, 18 May 2017 12:55:11 +0000 Subject: Getting valid substitutions to work for subsumption Message-ID: Greetings, I'm working on improving the valid substitution feature that I implemented a few weeks ago, but I'm having a problem making it work with subsumption, i.e. if the types are not exactly equal. You can find all the code on a branch on my fork of GHC on GitHub , with the subsumption checker being the following function: -- Reports whether one type subsumes another, discarding any errors tcSubsumes :: TcSigmaType -> TcSigmaType -> TcM Bool tcSubsumes hole_ty ty = discardErrs $ do { (_, wanted, _) <- pushLevelAndCaptureConstraints $ tcSubType_NC ExprSigCtxt ty hole_ty ; (rem, _) <- runTcS (simpl_top wanted) ; return (isEmptyWC rem) } The current example I'm working with is module T3 where ps3 :: Num a => a -> a -> a ps3 = (+) ps4 :: Num a => a -> a -> a ps4 = _ Which should of course include (+) as a suggestion. However, when it checks for (+), it does not report it as a match. What could be going wrong here? Could someone more familiar with the underlying machinery give some guidance on what could be going wrong here? Dumping the traceTc (i.e. running ./inplace/bin/ghc-stage2 -o test t3.hs -ddump-tc-trace) gives the following relevant output in the dump: Checking for substitution + parent:Num imported from ‘Prelude’ at t3.hs:1:8-9 (and originally defined in ‘GHC.Num’) tcSubType_NC an expression type signature forall a. Num a => a -> a -> a a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_tc_type (general case) ty_actual = forall a. Num a => a -> a -> a ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tcSkolemise tc_sub_type_ds ty_actual = forall a. Num a => a -> a -> a ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] instCallConstraints [$dNum_a4eI] Instantiating all tyvars? True origin arising from a type equality forall a. Num a => a -> a -> a ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] type forall a. Num a => a -> a -> a theta [Num a_a19t] leave_bndrs [] with [a_a4eH[tau:3]] theta: [Num a0_a4eH[tau:3]] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] -> a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] -> a_a1D1[sk:2] tc_sub_type_ds ty_actual = a0_a4eH[tau:3] ty_expected = a_a1D1[sk:2] u_tys tclvl 3 a0_a4eH[tau:3] ~ a_a1D1[sk:2] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys tclvl 3 * ~ * arising from a kind equality arising from a0_a4eH[tau:3] ~ a_a1D1[sk:2] u_tys tclvl 3 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a4eH[tau:3] ~ a_a1D1[sk:2] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a4eH[tau:3] :: * := a_a1D1[sk:2] u_tys yields no coercion tc_sub_tc_type (general case) ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] tcSkolemise tc_sub_type_ds ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] u_tys tclvl 3 a_a1D1[sk:2] ~ a0_a4eH[tau:3] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys yields no coercion tc_sub_tc_type (general case) ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] tcSkolemise tc_sub_type_ds ty_actual = a_a1D1[sk:2] ty_expected = a0_a4eH[tau:3] u_tys tclvl 3 a_a1D1[sk:2] ~ a0_a4eH[tau:3] arising from a type equality a0_a4eH[tau:3] -> a0_a4eH[tau:3] -> a0_a4eH[tau:3] ~ a_a1D1[sk:2] -> a_a1D1[sk:2] -> a_a1D1[sk:2] u_tys yields no coercion newTcEvBinds unique = a4eJ solveWanteds { WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical)} solveSimpleWanteds { {[WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical)} ----------------------------- Start solver pipeline { work item = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) inerts = {Unsolved goals = 0} rest of worklist = WL {} runStage canonicalization { workitem = [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) canonicalize (non-canonical) [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] (CNonCanonical) canEvNC:cls Num [a0_a4eH[tau:3]] flatten_many { a0_a4eH[tau:3] Following filled tyvar a_a4eH[tau:3] = a_a1D1[sk:2] Unfilled tyvar a_a1D1[sk:2] flatten } a_a1D1[sk:2] canClass [WD] $dNum_a4eI {0}:: Num a0_a4eH[tau:3] Num a_a1D1[sk:2] ContinueWith [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] end stage canonicalization } runStage interact with inerts { workitem = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) end stage interact with inerts } runStage top-level reactions { workitem = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) doTopReact [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) matchClassInst pred = Num a_a1D1[sk:2] { matchClass not matching dict Num a_a1D1[sk:2] } matchClassInst result NoInstance try_fundeps [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) end stage top-level reactions } insertInertCan { Trying to insert new non-eq inert item: [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) addInertCan } Step 1[l:2,d:0] Kept as inert: [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] End solver pipeline (kept as inert) } final_item = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan) getUnsolvedInerts tv eqs = {} fun eqs = {} insols = {} others = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} implics = {} Unflattening {Funeqs = Tv eqs =} Unflattening 1 {} Unflattening 2 {} Unflattening 3 {} Unflattening done {} zonkSimples done: {} solveSimpleWanteds end } iterations = 1 residual = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} expandSuperClasses { End expandSuperClasses no-op } solveWanteds middle simples1 = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} simples2 = {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} solveWanteds } final wc = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan)} current evbinds = {} zonkSimples done: {[WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan(psc))} zonkSimples done: {} applyDefaultingRules { wanteds = WC {wc_simple = [WD] $dNum_a4eI {0}:: Num a_a1D1[sk:2] (CDictCan(psc))} groups = [] info = ([Integer, Double], (False, False)) applyDefaultingRules } [] Constraint solver steps = 1 -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Thu May 18 13:21:09 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 18 May 2017 09:21:09 -0400 Subject: Getting valid substitutions to work for subsumption In-Reply-To: References: Message-ID: <1C75ABDC-7A09-4F3E-8FC6-A8D4B69C1AC1@cs.brynmawr.edu> Hi Matthías, This is going to be challenging to fix, I'm afraid. When GHC sees a definition with a polymorphic type signature, it *skolemizes* the signature before ever looking at the definition. In this context, skolemizing means that GHC will fix the type variable a (in your trace, it becomes the skolem a_a1D1[sk:2]; the "sk" there means skolem) and assume `Num a`. (This action takes place in TcBinds.tcPolyCheck.) GHC then goes about trying to typecheck the definition against the skolemized type. That's why the "expected types" in your trace just mention skolems, with no `Num a_a1D1` in sight. The way that GHC assumes a constraint is this: it typechecks the code over which the constraint is assumed, producing some residual WantedConstraints. GHC then builds an implication over these WantedConstraints, where the implication marks the assumed constraint as a Given. This action is in TcUnify.checkConstraints and buildImplication. Note that tcPolyCheck calls checkConstraints. The problem is that it seems you need to access the assumed constraints even before you're done typechecking the enclosed expression. GHC simply isn't set up for that. I think your best bet is to modify CHoleCan or make a new constructor of Ct (in TcRnTypes) that stores the information you need to produce the output you would like. Then, in your tcSubsumes, you will still need to emit any residual wanteds, all the way to the top level. Then GHC will run the solver, and TcErrors can format suggestions appropriately. I hope this makes some sense! Richard From syd.kerckhove at gmail.com Thu May 18 12:39:38 2017 From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove) Date: Thu, 18 May 2017 14:39:38 +0200 Subject: Type class instances in scope Message-ID: <20170518123938.GA3096@septus.localdomain> Dear GHC Devs. I am trying to use the GHC API as part of the work that I am doing for my thesis. Currently I am looking for a way to find all the type class instances that are in scope in a given module. Here's what I've tried: ``` getInstancesFromTcmodule :: GhcMonad m => TypecheckedModule -> m () getInstancesFromTcmodule tmod = do let (tcenv, md) = tm_internals_ tmod let insts = tcg_insts tcenv getInsts >>= printO printO $ modInfoInstances $ tm_checked_module_info tmod printO insts printO $ md_insts md printO $ tcg_inst_env tcenv printO :: (GhcMonad m, Outputable a) => a -> m () printO a = showGHC a >>= (liftIO . putStrLn) ``` Unfortunately the output that I get is empty: ``` ([], []) [] [] [] [] ``` For the record, I ran this on the following module: ``` {-# LANGUAGE NoImplicitPrelude #-} module Ints where import Prelude (Int, (+), (-)) f :: Int -> Int f x = x + 1 g :: Int -> Int g x = x - 1 double :: Int -> Int double x = x + x zero :: Int zero = 0 ``` Because I'm using '+' and '-', I definitely expect the instances of 'Num' to be available, but I am also expecting to find ALL the other instances that are available for type checking. Is there any documentation on this matter? Failing that, is there anyone who is willing to help me with this problem? Thank you for your time. -- Tom Sydney Kerckhove -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From simonpj at microsoft.com Thu May 18 21:27:47 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 May 2017 21:27:47 +0000 Subject: Getting valid substitutions to work for subsumption In-Reply-To: <1C75ABDC-7A09-4F3E-8FC6-A8D4B69C1AC1@cs.brynmawr.edu> References: <1C75ABDC-7A09-4F3E-8FC6-A8D4B69C1AC1@cs.brynmawr.edu> Message-ID: | This is going to be challenging to fix, I'm afraid. I don't agree. If you call (tcSubsumes hole_ty ty) with closed types hole_ty, ty, it should return True if ty is more polymorphic than hole_ty. For example tcSubsumes (forall a. [a] -> [a]) (forall b. b -> b) should return True. Ditto tcSubsumes (Int -> Int) (forall a. [a] -> [a]) And tcSubsumes (forall a. Ord a => a -> a) (forall b. Eq b => b -> b) I'm not sure what arguments you are actually giving it. S | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard | Eisenberg | Sent: 18 May 2017 14:21 | To: Matthías Páll Gissurarson | Cc: ghc-devs at haskell.org | Subject: Re: Getting valid substitutions to work for subsumption | | Hi Matthías, | | This is going to be challenging to fix, I'm afraid. | | When GHC sees a definition with a polymorphic type signature, it | *skolemizes* the signature before ever looking at the definition. In this | context, skolemizing means that GHC will fix the type variable a (in your | trace, it becomes the skolem a_a1D1[sk:2]; the "sk" there means skolem) | and assume `Num a`. (This action takes place in TcBinds.tcPolyCheck.) GHC | then goes about trying to typecheck the definition against the skolemized | type. That's why the "expected types" in your trace just mention skolems, | with no `Num a_a1D1` in sight. | | The way that GHC assumes a constraint is this: it typechecks the code | over which the constraint is assumed, producing some residual | WantedConstraints. GHC then builds an implication over these | WantedConstraints, where the implication marks the assumed constraint as | a Given. This action is in TcUnify.checkConstraints and buildImplication. | Note that tcPolyCheck calls checkConstraints. | | The problem is that it seems you need to access the assumed constraints | even before you're done typechecking the enclosed expression. GHC simply | isn't set up for that. I think your best bet is to modify CHoleCan or | make a new constructor of Ct (in TcRnTypes) that stores the information | you need to produce the output you would like. Then, in your tcSubsumes, | you will still need to emit any residual wanteds, all the way to the top | level. Then GHC will run the solver, and TcErrors can format suggestions | appropriately. | | I hope this makes some sense! | Richard | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C8149f8440a30449d9f4a08d49df | 0d915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636307105156540750&sda | ta=OadpZcPB44wsFF6A93YpftNR5364BN7SleqhsMuNCeo%3D&reserved=0 From ezyang at mit.edu Fri May 19 00:41:13 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 18 May 2017 20:41:13 -0400 Subject: Type class instances in scope In-Reply-To: <20170518123938.GA3096@septus.localdomain> References: <20170518123938.GA3096@septus.localdomain> Message-ID: <1495154299-sup-4598@sabre> Hi Tom, The problem is that GHC lazily loads non-orphan instances, so they won't be in the environment until you load the interface which would have caused the instance to come into scope. I'm not sure exactly what you are actually trying to do. But if you really need all instances, you will have to first arrange to load the interfaces of ALL modules transitively imported by your module. Edward Excerpts from Tom Sydney Kerckhove's message of 2017-05-18 14:39:38 +0200: > Dear GHC Devs. > > I am trying to use the GHC API as part of the work that I am doing for > my thesis. Currently I am looking for a way to find all the type class > instances that are in scope in a given module. > > Here's what I've tried: > > ``` > getInstancesFromTcmodule > :: GhcMonad m > => TypecheckedModule -> m () > getInstancesFromTcmodule tmod = do > let (tcenv, md) = tm_internals_ tmod > let insts = tcg_insts tcenv > getInsts >>= printO > printO $ modInfoInstances $ tm_checked_module_info tmod > printO insts > printO $ md_insts md > printO $ tcg_inst_env tcenv > > printO > :: (GhcMonad m, Outputable a) > => a -> m () > printO a = showGHC a >>= (liftIO . putStrLn) > ``` > > Unfortunately the output that I get is empty: > > ``` > ([], []) > [] > [] > [] > [] > ``` > > For the record, I ran this on the following module: > > ``` > {-# LANGUAGE NoImplicitPrelude #-} > module Ints where > > import Prelude (Int, (+), (-)) > > f :: Int -> Int > f x = x + 1 > > g :: Int -> Int > g x = x - 1 > > double :: Int -> Int > double x = x + x > > zero :: Int > zero = 0 > ``` > > Because I'm using '+' and '-', I definitely expect the instances of > 'Num' to be available, but I am also expecting to find ALL the other > instances that are available for type checking. > > Is there any documentation on this matter? > Failing that, is there anyone who is willing to help me with this > problem? > > Thank you for your time. > From rae at cs.brynmawr.edu Fri May 19 00:59:48 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 18 May 2017 20:59:48 -0400 Subject: Getting valid substitutions to work for subsumption In-Reply-To: References: <1C75ABDC-7A09-4F3E-8FC6-A8D4B69C1AC1@cs.brynmawr.edu> Message-ID: > On May 18, 2017, at 5:27 PM, Simon Peyton Jones wrote: > > I don't agree. If you call (tcSubsumes hole_ty ty) with closed types > hole_ty, ty, it should return True if I agree here. But it looks like Matthías's function gets the expected type as pushed down by bidirectional typechecking. This type will always be deeply skolemized before tcSubsumes can get a hold of it, so it won't be closed. Richard From syd.kerckhove at gmail.com Fri May 19 09:05:17 2017 From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove) Date: Fri, 19 May 2017 11:05:17 +0200 Subject: Type class instances in scope In-Reply-To: <1495154299-sup-4598@sabre> References: <20170518123938.GA3096@septus.localdomain> <1495154299-sup-4598@sabre> Message-ID: <20170519090516.GB3538@septus.localdomain> On 18-05-17 20:41:13, Edward Z. Yang wrote: > Hi Tom, Hi Edward, > The problem is that GHC lazily loads non-orphan instances, so they won't > be in the environment until you load the interface which would have > caused the instance to come into scope. Oh, that's annoying. I have a feeling there is room for an optimisation here. ... or maybe this was already an optimisation, I don't really know. > I'm not sure exactly what you are actually trying to do. More concretely, I need to generate a line of code for every 'Arbitrary' instance in scope. Later I'll also need to use other instances but this is the first part. > But if you > really need all instances, you will have to first arrange to load > the interfaces of ALL modules transitively imported by your module. I don't really mind the time it takes to do this, but that's annoying to write. Thank you for your help! I will look into it. > Edward > > Excerpts from Tom Sydney Kerckhove's message of 2017-05-18 14:39:38 +0200: > > Dear GHC Devs. > > > > I am trying to use the GHC API as part of the work that I am doing for > > my thesis. Currently I am looking for a way to find all the type class > > instances that are in scope in a given module. > > > > Here's what I've tried: > > > > ``` > > getInstancesFromTcmodule > > :: GhcMonad m > > => TypecheckedModule -> m () > > getInstancesFromTcmodule tmod = do > > let (tcenv, md) = tm_internals_ tmod > > let insts = tcg_insts tcenv > > getInsts >>= printO > > printO $ modInfoInstances $ tm_checked_module_info tmod > > printO insts > > printO $ md_insts md > > printO $ tcg_inst_env tcenv > > > > printO > > :: (GhcMonad m, Outputable a) > > => a -> m () > > printO a = showGHC a >>= (liftIO . putStrLn) > > ``` > > > > Unfortunately the output that I get is empty: > > > > ``` > > ([], []) > > [] > > [] > > [] > > [] > > ``` > > > > For the record, I ran this on the following module: > > > > ``` > > {-# LANGUAGE NoImplicitPrelude #-} > > module Ints where > > > > import Prelude (Int, (+), (-)) > > > > f :: Int -> Int > > f x = x + 1 > > > > g :: Int -> Int > > g x = x - 1 > > > > double :: Int -> Int > > double x = x + x > > > > zero :: Int > > zero = 0 > > ``` > > > > Because I'm using '+' and '-', I definitely expect the instances of > > 'Num' to be available, but I am also expecting to find ALL the other > > instances that are available for type checking. > > > > Is there any documentation on this matter? > > Failing that, is there anyone who is willing to help me with this > > problem? > > > > Thank you for your time. > > -- Tom Sydney Kerckhove -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alberto at toscat.net Fri May 19 09:33:36 2017 From: alberto at toscat.net (Alberto Valverde) Date: Fri, 19 May 2017 11:33:36 +0200 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi, I'm trying to build an app with the new release candidate and I'm running into a couple of issues, some which I can fix or workaround, some are worrisome and others are blocking me. I'm using Nix, if that matters. The fixable --------------- - The expected too strict version bounds. Worked around using doJailbreak, will send PRs to the respective packages with relaxed bounds. - A weird kind error when using ConstraintKinds in a propietary package which didn't manifest itself with ghc < 8.2: src/Sigym4/Propag/Types.hs:1071:4: error: • Expected a type, but ‘(PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a)’ has kind ‘Constraint’ • In the type ‘((PropagIOConstraint l a, Missing (PropagIOVector l) (PropagIONullable l a), Elem (PropagIONullable l a) ~ a))’ In the type declaration for ‘CanSerialize’ | 1071 | (( PropagIOConstraint l a | ^^^^^^^^^^^^^^^^^^^^^^^^... src/Sigym4/Propag/Types.hs:1077:4: error: • Expected a constraint, but ‘(CanSerialize l Double, CanSerialize l Int16)’ has kind ‘*’ • In the type ‘(CanSerialize l Double, CanSerialize l Int16)’ In the type declaration for ‘CanSerializePropagTypes’ | 1077 | ( CanSerialize l Double | ^^^^^^^^^^^^^^^^^^^^^^^... I cannot link to the source for this package since it belongs to my employer but I think that the interesting code is: type CanSerialize l a = ( PropagIOConstraint l a , Missing (PropagIOVector l) (PropagIONullable l a) , Elem (PropagIONullable l a) ~ a ) where PropagIOConstraint, PropagIONullable and PropagIOVector are "standalone" type families and Elem is an associated type family (not from IsList) Both errors disappear if I give an explicit kind signature like this: "type CanSerialize l a = (..... :: Constraint)". Is this expected behaviour? Should I try to isolate and open a ticket? The worrisome -------------------- - I had to disable the tests for two packages since they seem to "hang" (ie: they never finish running and don't seem to consume any CPU time). These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix environmental issue, I'm not sure. Can anyone reproduce this? The blockers ----------------- - I can't manage to install several packages which include executables (namely, update-nix-fetchgit and snap-server, for the moment) because Cabal says that it cannot find the source for the main module of the executables: "Setup: can't find source for Main in ." It seems that the "hs-source-dir" directive in the .cabal file is not being honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on how can I fix it? Thanks very much for GHC, btw :) Alberto On Tue, May 16, 2017 at 4:47 AM, Ben Gamari wrote: > > Hello everyone, > > The GHC team is very pleased to announce the second candidate of the > 8.2.1 release of the Glasgow Haskell Compiler. Source and binary > distributions are available at > > https://downloads.haskell.org/~ghc/8.2.1-rc2/ > > This is the second of what will likely be either two or three release > candidates leading up the final 8.2.1 release. This release will > feature, > > * A new type-indexed Typeable implementation > > * The long awaited Backpack > > * Deriving strategies for disambiguating DeriveAnyClass, > GeneralizedNewtypeDeriving, and stock mechanisms > > * Overloaded record fields > > * Improved compiler performance > > * Better code generation through more robust tracking of join points > > * Compact regions for more efficient garbage collection and serialization > > * Better support for machines with non-uniform memory architectures > > * More robust support for levity (e.g. RuntimeRep) polymorphism > > * A simple interface for streaming eventlog data from live processes > > * Further refinement of DWARF support > > This candidate fixes most of the issues present in release candidate > one including, > > * #13233: typePrimRep panic while compiling GHC with profiling enabled > * #13509: type error involving unboxed tuples > * #13426: compile-time memory-usage regression > * #13560: Windows binary distributions carry absolute paths to toolchain > * #13585: Control.Lens.Wrapped.ala causes compiler panic > * #13623: Join points produce bad code for stream fusion > > As always, please let us know if you have difficulty. Thanks to everyone > who has contributed! > > Happy testing, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri May 19 12:35:32 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 19 May 2017 08:35:32 -0400 Subject: Type class instances in scope In-Reply-To: <20170519090516.GB3538@septus.localdomain> References: <20170518123938.GA3096@septus.localdomain> <1495154299-sup-4598@sabre> <20170519090516.GB3538@septus.localdomain> Message-ID: <1495197224-sup-1352@sabre> Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200: > Oh, that's annoying. > I have a feeling there is room for an optimisation here. > ... or maybe this was already an optimisation, I don't really know. It's an optimization. Without, we would have to eagerly load every interface you transitively import, even if you didn't end up using them. That would be really slow. > > I'm not sure exactly what you are actually trying to do. > > More concretely, I need to generate a line of code for every 'Arbitrary' > instance in scope. > > Later I'll also need to use other instances but this is the first part. OK... > > But if you > > really need all instances, you will have to first arrange to load > > the interfaces of ALL modules transitively imported by your module. > > I don't really mind the time it takes to do this, but that's annoying to > write. > > Thank you for your help! I will look into it. Another possibility is, if you can programatically list the types that you are interested in, you can load all of those, and then the instances for those types will be ready. From ryan.gl.scott at gmail.com Fri May 19 16:16:17 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 19 May 2017 09:16:17 -0700 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 Message-ID: Hi Alberto. Thanks for the very detailed report! > - A weird kind error when using ConstraintKinds in a propietary package > which didn't manifest itself with ghc < 8.2: > > ... > > Is this expected behaviour? > Should I try to isolate and open a ticket? This looks like a proper bug to me. Can you minimize the example a submit a bug report at https://ghc.haskell.org/trac/ghc/newticket for this? Thanks! > - I had to disable the tests for two packages since they seem to "hang" > (ie: they never finish running and don't seem to consume any CPU time). > These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix > environmental issue, I'm not sure. Can anyone reproduce this? The fact that the lens tests run forever sounds unusual to me, as the lens repo has been running regression tests with GHC 8.2 for a while with no observed slowdowns. I'll double-check soon just to be sure, though. However, I can confirm that the fingertree tests appear to loop forever at runtime with GHC 8.2 (as opposed to GHC 8.0, where they finish in about 7.5 seconds). This is certainly not a good thing, so I'll try to investigate this more. Thanks for noticing this. > - I can't manage to install several packages which include executables > (namely, update-nix-fetchgit and snap-server, for the moment) because Cabal > says that it cannot find the source for the main module of the executables: > > "Setup: can't find source for Main in ." > > It seems that the "hs-source-dir" directive in the .cabal file is not being > honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on > how can I fix it? I can't reproduce this issue, at least with update-nix-fetchgit-0.1.0.0 (by using `cabal install` to install it). Can you give more detailed instructions on how to trigger this error? Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri May 19 17:39:34 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 19 May 2017 10:39:34 -0700 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: Message-ID: A follow-up: * The fact that the fingertree test suite doesn't terminate is an occurrence of a known bug, GHC Trac #13429 [1]. * I just ran the lens test suite with GHC 8.2, and it terminated [2]. It does take a while, though, sound it's understandable that one would think it loops forever if you don't have the patience to let it finish :) Again, I'm not able to reproduce the ConstraintKinds or Cabal regressions you reported, so it would be tremendously helpful if you could submit bug reports explaining how to trigger those issues. Thanks! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13429#comment:16 [2] https://travis-ci.org/ekmett/lens/jobs/231611970 On Fri, May 19, 2017 at 9:16 AM, Ryan Scott wrote: > Hi Alberto. Thanks for the very detailed report! > > > - A weird kind error when using ConstraintKinds in a propietary package > > which didn't manifest itself with ghc < 8.2: > > > > ... > > > > Is this expected behaviour? > > Should I try to isolate and open a ticket? > > This looks like a proper bug to me. Can you minimize the example a submit > a bug report at https://ghc.haskell.org/trac/ghc/newticket for this? > Thanks! > > > - I had to disable the tests for two packages since they seem to "hang" > > (ie: they never finish running and don't seem to consume any CPU time). > > These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix > > environmental issue, I'm not sure. Can anyone reproduce this? > > The fact that the lens tests run forever sounds unusual to me, as the lens > repo has been running regression tests with GHC 8.2 for a while with no > observed slowdowns. I'll double-check soon just to be sure, though. > > However, I can confirm that the fingertree tests appear to loop forever at > runtime with GHC 8.2 (as opposed to GHC 8.0, where they finish in about 7.5 > seconds). This is certainly not a good thing, so I'll try to investigate > this more. Thanks for noticing this. > > > - I can't manage to install several packages which include executables > > (namely, update-nix-fetchgit and snap-server, for the moment) because > Cabal > > says that it cannot find the source for the main module of the > executables: > > > > "Setup: can't find source for Main in ." > > > > It seems that the "hs-source-dir" directive in the .cabal file is not > being > > honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on > > how can I fix it? > > I can't reproduce this issue, at least with update-nix-fetchgit-0.1.0.0 > (by using `cabal install` to install it). Can you give more detailed > instructions on how to trigger this error? > > Ryan S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syd.kerckhove at gmail.com Fri May 19 21:00:41 2017 From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove) Date: Fri, 19 May 2017 23:00:41 +0200 Subject: Type class instances in scope In-Reply-To: <1495197224-sup-1352@sabre> References: <20170518123938.GA3096@septus.localdomain> <1495154299-sup-4598@sabre> <20170519090516.GB3538@septus.localdomain> <1495197224-sup-1352@sabre> Message-ID: <20170519210041.GC5621@quintus.localdomain> On 19-05-17 08:35:32, Edward Z. Yang wrote: > Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200: > > > But if you > > > really need all instances, you will have to first arrange to load > > > the interfaces of ALL modules transitively imported by your module. > > > > I don't really mind the time it takes to do this, but that's annoying to > > write. > > > > Thank you for your help! I will look into it. > > Another possibility is, if you can programatically list the types that > you are interested in, you can load all of those, and then the instances > for those types will be ready. That's probably the most feasible approach. Then I'd have to find all the types in scope, and find their interfaces. I know how to get all the TyThing's in scope, so it should be easy-ish to get started. Thanks! -- Tom Sydney Kerckhove -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mail at joachim-breitner.de Sat May 20 16:56:56 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 20 May 2017 12:56:56 -0400 Subject: How lose can we be with strictness Message-ID: <1495299416.8781.3.camel@joachim-breitner.de> Hi, I just observed that GHC optimizes fun (n::Int) = n == 0 + n to essentially fun (n::Int) = n `seq` True I am wondering under what circumstances we would be happy to transform this further to fun _ = True Clearly, we do not want to drop `seq`s in general. But is there some commonly accepted rule about which strictness we generally allow the compiler to get rid of, if it turns out that the compiler can do without? Or are all such transformations out of bounds for GHC? Greetings, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cma at bitemyapp.com Sat May 20 17:07:29 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 20 May 2017 12:07:29 -0500 Subject: How lose can we be with strictness In-Reply-To: <1495299416.8781.3.camel@joachim-breitner.de> References: <1495299416.8781.3.camel@joachim-breitner.de> Message-ID: Correct me if I'm wrong here, but it's preserving the effect of (==) forcing its arguments. This makes the optimization less surprising, in my opinion. Is there a benefit to not doing this? On Sat, May 20, 2017 at 11:56 AM, Joachim Breitner wrote: > Hi, > > I just observed that GHC optimizes > > fun (n::Int) = n == 0 + n > > to essentially > > fun (n::Int) = n `seq` True > > > I am wondering under what circumstances we would be happy to transform > this further to > > fun _ = True > > > Clearly, we do not want to drop `seq`s in general. But is there some > commonly accepted rule about which strictness we generally allow the > compiler to get rid of, if it turns out that the compiler can do > without? Or are all such transformations out of bounds for GHC? > > Greetings, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Sat May 20 17:13:43 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 20 May 2017 13:13:43 -0400 Subject: How lose can we be with strictness In-Reply-To: References: <1495299416.8781.3.camel@joachim-breitner.de> Message-ID: <1495300423.8781.5.camel@joachim-breitner.de> Hi, yes, of course. What GHC is doing now is correct, safe and what an (exprienced) programmer expects. Especially if he is using `x==x` to deeply force x… But then I presume that there are many uses of code like this where the effect of `==` forcing its arguments is a necessary side effect of deciding the equality, and if the compiler finds a different way of deciding the equality, e.g. statically, the programmer would be happy to have `n` as dead code, with all the advantages this provides. And I am wondering if there is a way for GHC to discriminate between these two options somehow… Joachim Am Samstag, den 20.05.2017, 12:07 -0500 schrieb Christopher Allen: > Correct me if I'm wrong here, but it's preserving the effect of (==) > forcing its arguments. This makes the optimization less surprising, > in > my opinion. > > Is there a benefit to not doing this? > > On Sat, May 20, 2017 at 11:56 AM, Joachim Breitner > wrote: > > Hi, > > > > I just observed that GHC optimizes > > > > fun (n::Int) = n == 0 + n > > > > to essentially > > > > fun (n::Int) = n `seq` True > > > > > > I am wondering under what circumstances we would be happy to > > transform > > this further to > > > > fun _ = True > > > > > > Clearly, we do not want to drop `seq`s in general. But is there > > some > > commonly accepted rule about which strictness we generally allow > > the > > compiler to get rid of, if it turns out that the compiler can do > > without? Or are all such transformations out of bounds for GHC? > > > > Greetings, > > Joachim > > > > -- > > Joachim Breitner > >   mail at joachim-breitner.de > >   http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Sat May 20 17:20:07 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 20 May 2017 13:20:07 -0400 Subject: 8.2 and earlier build times In-Reply-To: <87a86bdytz.fsf@ben-laptop.smart-cactus.org> References: <87a86bdytz.fsf@ben-laptop.smart-cactus.org> Message-ID: <8737bzo37c.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: snip > > The "normal" and "profiled" build metrics are the +RTS -t lines extract > from Cabal's profiled and unprofiled GHC invocations. I believe the > RTS timings for 8.0.2 are broken due to a (fixed) RTS bug, although I > can't come up with a reference at the moment. > > I tried this again with regex-tdfa-1.2.2 and indeed I was able to reproduce Herbert's result, 8.0.2 normal: <> profiled: <> 8.2.1-rc2: normal: <> profiled: <> We'll need to look at what is going on here as this is a pretty significant regression. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From syd.kerckhove at gmail.com Mon May 22 03:20:37 2017 From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove) Date: Mon, 22 May 2017 05:20:37 +0200 Subject: Type class instances in scope In-Reply-To: <20170519210041.GC5621@quintus.localdomain> References: <20170518123938.GA3096@septus.localdomain> <1495154299-sup-4598@sabre> <20170519090516.GB3538@septus.localdomain> <1495197224-sup-1352@sabre> <20170519210041.GC5621@quintus.localdomain> Message-ID: <20170522032037.GA15657@quintus.localdomain> Hi Edward, I'm sorry to have to bother you with this again, but I seem to be stuck with this approach. I think I don't really understand what 'load the interfaces' means. Here's what I tried: ``` Haskell getInstancesFromTcmodule :: GhcMonad m => TypecheckedModule -> m () getInstancesFromTcmodule tmod = do let (tcenv, md) = tm_internals_ tmod let insts = tcg_insts tcenv printO insts printO $ md_insts md printO $ tcg_inst_env tcenv graph <- depanal [] True printO graph forM_ graph $ \mod_ -> do forM_ (ms_textual_imps mod_) $ \(_, imp) -> do let modname = unLoc imp addTarget (Target { targetId = TargetModule modname , targetAllowObjCode = True , targetContents = Nothing }) loadSuccessfully $ LoadUpTo modname getModSummary (unLoc imp) >>= printO tcmod <- parseModule mod_ >>= typecheckModule >>= loadModule let (tcenv', md') = tm_internals_ tcmod printO $ tcg_insts tcenv' printO $ md_insts md' printO $ tcg_inst_env tcenv' ``` I just wanted to see if I could find all the relevant instances. I do find all the instances in the current `TypecheckedModle`, but none of the others because at `loadSuccessfully $ loadUpTo modname`, I get an error saying that `Test.QuickCheck a package module`. I think that means that it's not locally defined, but rather part of a package that I'm using. Unfortunately that means that I don't really understand how I can load it to find the instances. Would you please hint me at the next step? Thank you for your time. On 19-05-17 23:00:41, Tom Sydney Kerckhove wrote: > On 19-05-17 08:35:32, Edward Z. Yang wrote: > > Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200: > > > > But if you > > > > really need all instances, you will have to first arrange to load > > > > the interfaces of ALL modules transitively imported by your module. > > > > > > I don't really mind the time it takes to do this, but that's annoying to > > > write. > > > > > > Thank you for your help! I will look into it. > > > > Another possibility is, if you can programatically list the types that > > you are interested in, you can load all of those, and then the instances > > for those types will be ready. > > That's probably the most feasible approach. > Then I'd have to find all the types in scope, and find their interfaces. > > I know how to get all the TyThing's in scope, so it should be easy-ish > to get started. > > Thanks! > > -- > Tom Sydney Kerckhove -- Tom Sydney Kerckhove -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alberto at toscat.net Mon May 22 07:33:23 2017 From: alberto at toscat.net (Alberto Valverde) Date: Mon, 22 May 2017 09:33:23 +0200 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: Message-ID: Hi Ryan, I hope to be able to reproduce the ConstraintKinds bug in a minimal example later today. I believe that the cabal bug might be something to do with my nix setup so will investigate more to see how nix installs Haskell packages under the hood. Will follow-up as soon as I can. Thanks! Alberto On Fri, May 19, 2017 at 7:39 PM, Ryan Scott wrote: > A follow-up: > > * The fact that the fingertree test suite doesn't terminate is an > occurrence of a known bug, GHC Trac #13429 [1]. > * I just ran the lens test suite with GHC 8.2, and it terminated [2]. It > does take a while, though, sound it's understandable that one would think > it loops forever if you don't have the patience to let it finish :) > > Again, I'm not able to reproduce the ConstraintKinds or Cabal regressions > you reported, so it would be tremendously helpful if you could submit bug > reports explaining how to trigger those issues. Thanks! > > Ryan S. > ----- > [1] https://ghc.haskell.org/trac/ghc/ticket/13429#comment:16 > [2] https://travis-ci.org/ekmett/lens/jobs/231611970 > > On Fri, May 19, 2017 at 9:16 AM, Ryan Scott > wrote: > >> Hi Alberto. Thanks for the very detailed report! >> >> > - A weird kind error when using ConstraintKinds in a propietary package >> > which didn't manifest itself with ghc < 8.2: >> > >> > ... >> > >> > Is this expected behaviour? >> > Should I try to isolate and open a ticket? >> >> This looks like a proper bug to me. Can you minimize the example a submit >> a bug report at https://ghc.haskell.org/trac/ghc/newticket for this? >> Thanks! >> >> > - I had to disable the tests for two packages since they seem to "hang" >> > (ie: they never finish running and don't seem to consume any CPU time). >> > These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix >> > environmental issue, I'm not sure. Can anyone reproduce this? >> >> The fact that the lens tests run forever sounds unusual to me, as the >> lens repo has been running regression tests with GHC 8.2 for a while with >> no observed slowdowns. I'll double-check soon just to be sure, though. >> >> However, I can confirm that the fingertree tests appear to loop forever >> at runtime with GHC 8.2 (as opposed to GHC 8.0, where they finish in about >> 7.5 seconds). This is certainly not a good thing, so I'll try to >> investigate this more. Thanks for noticing this. >> >> > - I can't manage to install several packages which include executables >> > (namely, update-nix-fetchgit and snap-server, for the moment) because >> Cabal >> > says that it cannot find the source for the main module of the >> executables: >> > >> > "Setup: can't find source for Main in ." >> > >> > It seems that the "hs-source-dir" directive in the .cabal file is not >> being >> > honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas on >> > how can I fix it? >> >> I can't reproduce this issue, at least with update-nix-fetchgit-0.1.0.0 >> (by using `cabal install` to install it). Can you give more detailed >> instructions on how to trigger this error? >> >> Ryan S. >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 22 15:52:38 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 May 2017 15:52:38 +0000 Subject: How lose can we be with strictness In-Reply-To: <1495300423.8781.5.camel@joachim-breitner.de> References: <1495299416.8781.3.camel@joachim-breitner.de> <1495300423.8781.5.camel@joachim-breitner.de> Message-ID: | And I am wondering if there is a way for GHC to discriminate between | these two options somehow… Not that I know of. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim | Breitner | Sent: 20 May 2017 18:14 | To: ghc-devs at haskell.org | Subject: Re: How lose can we be with strictness | | Hi, | | yes, of course. What GHC is doing now is correct, safe and what an | (exprienced) programmer expects. Especially if he is using `x==x` to | deeply force x… | | But then I presume that there are many uses of code like this where the | effect of `==` forcing its arguments is a necessary side effect of | deciding the equality, and if the compiler finds a different way of | deciding the equality, e.g. statically, the programmer would be happy to | have `n` as dead code, with all the advantages this provides. | | And I am wondering if there is a way for GHC to discriminate between | these two options somehow… | | Joachim | | | Am Samstag, den 20.05.2017, 12:07 -0500 schrieb Christopher Allen: | > Correct me if I'm wrong here, but it's preserving the effect of (==) | > forcing its arguments. This makes the optimization less surprising, in | > my opinion. | > | > Is there a benefit to not doing this? | > | > On Sat, May 20, 2017 at 11:56 AM, Joachim Breitner | > wrote: | > > Hi, | > > | > > I just observed that GHC optimizes | > > | > > fun (n::Int) = n == 0 + n | > > | > > to essentially | > > | > > fun (n::Int) = n `seq` True | > > | > > | > > I am wondering under what circumstances we would be happy to | > > transform this further to | > > | > > fun _ = True | > > | > > | > > Clearly, we do not want to drop `seq`s in general. But is there some | > > commonly accepted rule about which strictness we generally allow the | > > compiler to get rid of, if it turns out that the compiler can do | > > without? Or are all such transformations out of bounds for GHC? | > > | > > Greetings, | > > Joachim | > > | > > -- | > > Joachim Breitner | > >   mail at joachim-breitner.de | > > | > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. | > > joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4840 | > > 85dababa49deee5c08d49fa3a18a%7C72f988bf86f141af91ab2d7cd011db47%7C1% | > > 7C0%7C636308972543295456&sdata=mCYy2wGpdTvnCofPEBiVsYfRggxxUd9m3SPEu | > > fTQAJg%3D&reserved=0 | > > | > > _______________________________________________ | > > ghc-devs mailing list | > > ghc-devs at haskell.org | > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail | > > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01% | > > 7Csimonpj%40microsoft.com%7C484085dababa49deee5c08d49fa3a18a%7C72f98 | > > 8bf86f141af91ab2d7cd011db47%7C1%7C0%7C636308972543295456&sdata=XdESs | > > wIFC2EByMcyYyhVcq40Q0SPEujNKgY8Oqv%2Ff3Q%3D&reserved=0 | > > | > | > | > | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C484085dababa49dee | e5c08d49fa3a18a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636308972543 | 295456&sdata=mCYy2wGpdTvnCofPEBiVsYfRggxxUd9m3SPEufTQAJg%3D&reserved=0 From alberto at toscat.net Mon May 22 16:40:21 2017 From: alberto at toscat.net (Alberto Valverde) Date: Mon, 22 May 2017 18:40:21 +0200 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: Message-ID: I've manage to reproduce the CK bug without any external dependencies and opened a ticket with an attached module that fails to compile with 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2. https://ghc.haskell.org/trac/ghc/ticket/13742 The lens problem was a false alarm and a lack of patience from me... they indeed finish and pass if you give them enough time. Sorry for the noise. Will hopefully follow up soon with the Cabal issues I'm experiencing Alberto On Mon, May 22, 2017 at 9:33 AM, Alberto Valverde wrote: > Hi Ryan, > > I hope to be able to reproduce the ConstraintKinds bug in a minimal > example later today. I believe that the cabal bug might be something to do > with my nix setup so will investigate more to see how nix installs Haskell > packages under the hood. Will follow-up as soon as I can. > > Thanks! > > Alberto > > On Fri, May 19, 2017 at 7:39 PM, Ryan Scott > wrote: > >> A follow-up: >> >> * The fact that the fingertree test suite doesn't terminate is an >> occurrence of a known bug, GHC Trac #13429 [1]. >> * I just ran the lens test suite with GHC 8.2, and it terminated [2]. It >> does take a while, though, sound it's understandable that one would think >> it loops forever if you don't have the patience to let it finish :) >> >> Again, I'm not able to reproduce the ConstraintKinds or Cabal regressions >> you reported, so it would be tremendously helpful if you could submit bug >> reports explaining how to trigger those issues. Thanks! >> >> Ryan S. >> ----- >> [1] https://ghc.haskell.org/trac/ghc/ticket/13429#comment:16 >> [2] https://travis-ci.org/ekmett/lens/jobs/231611970 >> >> On Fri, May 19, 2017 at 9:16 AM, Ryan Scott >> wrote: >> >>> Hi Alberto. Thanks for the very detailed report! >>> >>> > - A weird kind error when using ConstraintKinds in a propietary package >>> > which didn't manifest itself with ghc < 8.2: >>> > >>> > ... >>> > >>> > Is this expected behaviour? >>> > Should I try to isolate and open a ticket? >>> >>> This looks like a proper bug to me. Can you minimize the example a >>> submit a bug report at https://ghc.haskell.org/trac/ghc/newticket for >>> this? Thanks! >>> >>> > - I had to disable the tests for two packages since they seem to "hang" >>> > (ie: they never finish running and don't seem to consume any CPU >>> time). >>> > These packages are lens-4.15.1 and fingertree-0.1.1.0. Maybe it's a Nix >>> > environmental issue, I'm not sure. Can anyone reproduce this? >>> >>> The fact that the lens tests run forever sounds unusual to me, as the >>> lens repo has been running regression tests with GHC 8.2 for a while with >>> no observed slowdowns. I'll double-check soon just to be sure, though. >>> >>> However, I can confirm that the fingertree tests appear to loop forever >>> at runtime with GHC 8.2 (as opposed to GHC 8.0, where they finish in about >>> 7.5 seconds). This is certainly not a good thing, so I'll try to >>> investigate this more. Thanks for noticing this. >>> >>> > - I can't manage to install several packages which include executables >>> > (namely, update-nix-fetchgit and snap-server, for the moment) because >>> Cabal >>> > says that it cannot find the source for the main module of the >>> executables: >>> > >>> > "Setup: can't find source for Main in ." >>> > >>> > It seems that the "hs-source-dir" directive in the .cabal file is not >>> being >>> > honored. Maybe a Nix-only issue? Can anyone reproduce this? Any ideas >>> on >>> > how can I fix it? >>> >>> I can't reproduce this issue, at least with update-nix-fetchgit-0.1.0.0 >>> (by using `cabal install` to install it). Can you give more detailed >>> instructions on how to trigger this error? >>> >>> Ryan S. >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 22 16:46:02 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 May 2017 16:46:02 +0000 Subject: 8.2 and earlier build times In-Reply-To: <8737bzo37c.fsf@ben-laptop.smart-cactus.org> References: <87a86bdytz.fsf@ben-laptop.smart-cactus.org> <8737bzo37c.fsf@ben-laptop.smart-cactus.org> Message-ID: | We'll need to look at what is going on here as this is a pretty | significant regression. Make a ticket with repro instructions? s | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 20 May 2017 18:20 | To: Herbert Valerio Riedel ; Simon Peyton Jones | | Cc: ghc-devs at haskell.org | Subject: Re: 8.2 and earlier build times | | Ben Gamari writes: | | snip | > | > The "normal" and "profiled" build metrics are the +RTS -t lines | > extract from Cabal's profiled and unprofiled GHC invocations. I | > believe the RTS timings for 8.0.2 are broken due to a (fixed) RTS | bug, | > although I can't come up with a reference at the moment. | > | > | I tried this again with regex-tdfa-1.2.2 and indeed I was able to | reproduce Herbert's result, | | | 8.0.2 | normal: <> | profiled: <> | | 8.2.1-rc2: | normal: <> | profiled: <> | | We'll need to look at what is going on here as this is a pretty | significant regression. | | Cheers, | | - Ben From ekmett at gmail.com Mon May 22 16:49:16 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 22 May 2017 12:49:16 -0400 Subject: How lose can we be with strictness In-Reply-To: <1495300423.8781.5.camel@joachim-breitner.de> References: <1495299416.8781.3.camel@joachim-breitner.de> <1495300423.8781.5.camel@joachim-breitner.de> Message-ID: <0209FB84-A9F8-4018-9904-1197D3A9548F@gmail.com> Sent from my iPad > On May 20, 2017, at 1:13 PM, Joachim Breitner wrote: > > Hi, > > yes, of course. What GHC is doing now is correct, safe and what an > (exprienced) programmer expects. Especially if he is using `x==x` to > deeply force x… Well, deeply force until it runs into a Float that happens to be a NaN. ;) From ben at smart-cactus.org Mon May 22 22:11:34 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 22 May 2017 18:11:34 -0400 Subject: 8.2 and earlier build times In-Reply-To: References: <87a86bdytz.fsf@ben-laptop.smart-cactus.org> <8737bzo37c.fsf@ben-laptop.smart-cactus.org> Message-ID: <87shjwmtih.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > | We'll need to look at what is going on here as this is a pretty > | significant regression. > > Make a ticket with repro instructions? > https://ghc.haskell.org/trac/ghc/ticket/13745 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From juhpetersen at gmail.com Tue May 23 08:58:00 2017 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 23 May 2017 17:58:00 +0900 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> References: <87fug5frgq.fsf@ben-laptop.smart-cactus.org> Message-ID: Thanks for RC2! I built it for Fedora in my Copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.2.1. While I haven't tested it yet, I note that the builds take rather long: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.2.1/build/555495/ A perf build with the testsuite takes up to 3 hours! I am building with 8.2.1 if it matters... I don't know if anything changed in the copr build system but for RC1 the same build take no more than 96 min! So it is quite a noticeable change. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Tue May 23 16:28:00 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Tue, 23 May 2017 09:28:00 -0700 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 Message-ID: Alberto, > I've manage to reproduce the CK bug without any external dependencies and > opened a ticket with an attached module that fails to compile with > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2. Thanks for doing this! > Will hopefully follow up soon with the Cabal issues I'm experiencing One thing that might be useful to do is to invoke Cabal with high verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised if Nix was passing some uncommonly used flags that have regressed in recent versions of Cabal. Ryan S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed May 24 12:51:50 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 24 May 2017 08:51:50 -0400 Subject: Type class instances in scope In-Reply-To: <20170522032037.GA15657@quintus.localdomain> References: <20170518123938.GA3096@septus.localdomain> <1495154299-sup-4598@sabre> <20170519090516.GB3538@septus.localdomain> <1495197224-sup-1352@sabre> <20170519210041.GC5621@quintus.localdomain> <20170522032037.GA15657@quintus.localdomain> Message-ID: <1495629699-sup-3005@sabre> Hi Tom, Here is what I was thinking when I made the suggestion: 1. Determine the transitive set of 'Module' that you need to load 2. Load each one using 'loadInterface' So, there are a few problems with your code below: - For external packages, it's sufficient to use 'loadInterface' to load a module, since this will suck the module's interface (and instances) into the EPS. - But you are not looking at the EPS. You need to use something like tcGetInstEnvs (that is in the wrong monad; but you can still look at this code) to get instances from the EPS. - But to run 'loadInterface', you need a 'Module', not a 'ModuleName' as in your code below. You should read off the 'Module' from the dependencies and usages of the module interface: look at 'ModIface'. - By looking at only imports of your local modules, you will only get the immediate set of imports, not the transitive closure. So you need to recursively do this for each 'ModIface' you load. Edward Excerpts from Tom Sydney Kerckhove's message of 2017-05-22 05:20:37 +0200: > Hi Edward, > > I'm sorry to have to bother you with this again, but I seem to be stuck > with this approach. > I think I don't really understand what 'load the interfaces' means. > > Here's what I tried: > > ``` Haskell > getInstancesFromTcmodule :: GhcMonad m => TypecheckedModule -> m () > getInstancesFromTcmodule tmod = do > let (tcenv, md) = tm_internals_ tmod > let insts = tcg_insts tcenv > printO insts > printO $ md_insts md > printO $ tcg_inst_env tcenv > graph <- depanal [] True > printO graph > forM_ graph $ \mod_ -> do > forM_ (ms_textual_imps mod_) $ \(_, imp) -> do > let modname = unLoc imp > addTarget > (Target > { targetId = TargetModule modname > , targetAllowObjCode = True > , targetContents = Nothing > }) > loadSuccessfully $ LoadUpTo modname > getModSummary (unLoc imp) >>= printO > tcmod <- parseModule mod_ >>= typecheckModule >>= loadModule > let (tcenv', md') = tm_internals_ tcmod > printO $ tcg_insts tcenv' > printO $ md_insts md' > printO $ tcg_inst_env tcenv' > ``` > > I just wanted to see if I could find all the relevant instances. > > I do find all the instances in the current `TypecheckedModle`, but none > of the others because at `loadSuccessfully $ loadUpTo modname`, I get an > error saying that `Test.QuickCheck a package module`. > I think that means that it's not locally defined, but rather part of a > package that I'm using. > Unfortunately that means that I don't really understand how I can load > it to find the instances. > > Would you please hint me at the next step? > > Thank you for your time. > > On 19-05-17 23:00:41, Tom Sydney Kerckhove wrote: > > On 19-05-17 08:35:32, Edward Z. Yang wrote: > > > Excerpts from Tom Sydney Kerckhove's message of 2017-05-19 11:05:17 +0200: > > > > > But if you > > > > > really need all instances, you will have to first arrange to load > > > > > the interfaces of ALL modules transitively imported by your module. > > > > > > > > I don't really mind the time it takes to do this, but that's annoying to > > > > write. > > > > > > > > Thank you for your help! I will look into it. > > > > > > Another possibility is, if you can programatically list the types that > > > you are interested in, you can load all of those, and then the instances > > > for those types will be ready. > > > > That's probably the most feasible approach. > > Then I'd have to find all the types in scope, and find their interfaces. > > > > I know how to get all the TyThing's in scope, so it should be easy-ish > > to get started. > > > > Thanks! > > > > -- > > Tom Sydney Kerckhove > From alan.zimm at gmail.com Wed May 24 21:52:07 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 24 May 2017 23:52:07 +0200 Subject: Trees that Grow in the hsSyn AST Message-ID: Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu May 25 22:48:47 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 May 2017 22:48:47 +0000 Subject: Trees that Grow in the hsSyn AST In-Reply-To: References: Message-ID: Folks Do take a look at this: · We propose to re-engineer HsSyn itself. This will touch a lot of code. · But it’s very neat, and will bring big long-term advantages · And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs. Alan has done a prototype first step, which worked out rather well. Rather than having HsExpr Id (which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have HsExpr GhcTc meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney. Please ask questions etc. Alan and Shayan can record the answers in the wiki. I’m inclined to go ahead with this, so yell soon if you disagree. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 24 May 2017 22:52 To: ghc-devs at haskell.org Subject: Trees that Grow in the hsSyn AST Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Fri May 26 00:11:06 2017 From: david at well-typed.com (David Feuer) Date: Thu, 25 May 2017 20:11:06 -0400 Subject: Trees that Grow in the hsSyn AST Message-ID: <20170525234824.D0A27BC963@haskell.org> I haven't looked in detail yet, but there seem to be good ideas. I have two questions: 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs Date: 5/25/17 6:48 PM (GMT-05:00) To: Alan & Kim Zimmerman , ghc-devs at haskell.org Subject: RE: Trees that Grow in the hsSyn AST Folks Do take a look at this: ·        We propose to re-engineer HsSyn itself.  This will touch a lot of code. ·        But it’s very neat, and will bring big long-term advantages ·        And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process.  But I’d value the opinion of other GHC devs. Alan has done a prototype first step, which worked out rather well.  Rather than having                HsExpr Id (which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have                HsExpr GhcTc meaning “HsExpr after GHC’s Tc pass”.   In some ways this is quite superficial, but it unlocks the Trees That Grow machiney. Please ask questions etc.  Alan and Shayan can record the answers in the wiki.  I’m inclined to go ahead with this, so yell soon if you disagree. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 24 May 2017 22:52 To: ghc-devs at haskell.org Subject: Trees that Grow in the hsSyn AST Hi all You may be aware that Shayan Najd presented the paper  "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached).  Wiki page, describe goals, design, > approach.  Point to prototype implementation.  Seek comments.   You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards   Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh.najd at gmail.com Fri May 26 02:00:10 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 26 May 2017 04:00:10 +0200 Subject: Trees that Grow in the hsSyn AST In-Reply-To: <20170525234824.D0A27BC963@haskell.org> References: <20170525234824.D0A27BC963@haskell.org> Message-ID: Hi David, Which is better to start with: HsSyn or Core? Intuition suggests this sort > of thing could be very helpful for making zapping more reliable and > ensuring its efficiency, but there may be better reasons to start with > HsSyn. - Why not making Core growable as well? We just have not considered making Core AST growable so far, though it is entirely doable if needed. Specially, if you have some motivating examples that a growable Core AST "could be very helpful" like for "making zapping more reliable and ensuring its efficiency", let us know; we can consider making Core growable as well (possibly as an independent project). - Why not making Core growable first? Here the idea is to make HsSyn AST growable for the long-term goals stated on the wiki page, like getting rid of the multiple representations of Haskell syntax (i.e., HsSyn, Template Haskell, and Haskell-Src-Exts). I imagine making Core AST growable does not get us closer to our current long-term goals (except maybe as an experiment to study the impact of such AST changes on GHC, like we did in D3609) 2. If we're making intrusive changes to representations, would now be a > sensible era to consider switching to a different variable representation > (unbound, bound, abt, etc)? - While we are at it, can we consider improving some bits of the AST? For the first few steps, I really hope to keep the changes to representations as little as possible, at least to ease the reviewing process and to avoid introducing bugs (provided the large scale of the changes). For the next steps, we can indeed consider such improvements. (We do so for source locations, at least) Do you have some specific changes in mind? Specially the ones that may overlap with our work? Thanks. /Shayan On Fri, May 26, 2017 at 2:11 AM, David Feuer wrote: > I haven't looked in detail yet, but there seem to be good ideas. I have > two questions: > > 1. Which is better to start with: HsSyn or Core? Intuition suggests this > sort of thing could be very helpful for making zapping more reliable and > ensuring its efficiency, but there may be better reasons to start with > HsSyn. > > 2. If we're making intrusive changes to representations, would now be a > sensible era to consider switching to a different variable representation > (unbound, bound, abt, etc)? > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Simon Peyton Jones via ghc-devs > Date: 5/25/17 6:48 PM (GMT-05:00) > To: Alan & Kim Zimmerman , ghc-devs at haskell.org > Subject: RE: Trees that Grow in the hsSyn AST > > Folks > > Do take a look at this: > > > · We propose to re-engineer HsSyn itself. This will touch a lot of > code. > > · But it’s very neat, and will bring big long-term advantages > > · And we can do it a bit at a time > > The wiki page https://ghc.haskell.org/trac/ghc/wiki/ > ImplementingTreesThatGrow has the details. > > It’s entirely an internal change, not a change to GHC’s specification, so > it’s independent of the GHC proposals process. But I’d value the opinion > of other GHC devs. > > Alan has done a prototype first step, which worked out rather well. > Rather than having > HsExpr Id > (which we all know means “HsExpr after the typechecker” but tha’s a bit > inexplicit, we have > HsExpr GhcTc > meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite > superficial, but it unlocks the Trees That Grow machiney. > > Please ask questions etc. Alan and Shayan can record the answers in the > wiki. I’m inclined to go ahead with this, so yell soon if you disagree. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & > Kim Zimmerman > Sent: 24 May 2017 22:52 > To: ghc-devs at haskell.org > Subject: Trees that Grow in the hsSyn AST > > Hi all > > You may be aware that Shayan Najd presented the paper "Trees that > Grow"[1] at HIW last year. > Based on the following mandate > > As in my previous email to Shayan (attached). Wiki page, describe > goals, design, > > approach. Point to prototype implementation. Seek comments. You can > say that > >I am supportive! > > > > Simon > > We have set up a Wiki page at [2] describing a prototype implementation of > the first stage of this for the hsSyn AST, which is to change the > polymorphic variable from one of RdrName / Name / Id to an index type. This > is presented as a fabricator diff at [3]. > Please take a look and provide feedback. > Regards > Alan > > > [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_ > 0042_0062_najd.pdf outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1% > 2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf&data=02% > 7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8% > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243&sdata= > fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D&reserved=0> > [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow > [3] https://phabricator.haskell.org/D3609 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 26 08:54:50 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 May 2017 08:54:50 +0000 Subject: HsParTy Message-ID: Alan Do you know why HsTypes.ppr_mono_ty contains any uses of 'maybeParen'? Shouldn't the parens all be put in by HsParTy? I tripped over this when I mistakenly added what I thought were missing maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by a test in tests/printer. So why are there /any/ maybeParen calls? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 26 09:03:15 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 May 2017 09:03:15 +0000 Subject: Trees that Grow in the hsSyn AST In-Reply-To: <38e18954-f13a-4a6c-8a81-8f76750cd40a@BL2NAM06FT006.Eop-nam06.prod.protection.outlook.com> References: <38e18954-f13a-4a6c-8a81-8f76750cd40a@BL2NAM06FT006.Eop-nam06.prod.protection.outlook.com> Message-ID: 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering. Simon From: David Feuer [mailto:david at well-typed.com] Sent: 26 May 2017 01:11 To: Simon Peyton Jones ; Alan & Kim Zimmerman ; ghc-devs at haskell.org Subject: RE: Trees that Grow in the hsSyn AST I haven't looked in detail yet, but there seem to be good ideas. I have two questions: 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? David Feuer Well-Typed, LLP -------- Original message -------- From: Simon Peyton Jones via ghc-devs > Date: 5/25/17 6:48 PM (GMT-05:00) To: Alan & Kim Zimmerman >, ghc-devs at haskell.org Subject: RE: Trees that Grow in the hsSyn AST Folks Do take a look at this: · We propose to re-engineer HsSyn itself. This will touch a lot of code. · But it’s very neat, and will bring big long-term advantages · And we can do it a bit at a time The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow has the details. It’s entirely an internal change, not a change to GHC’s specification, so it’s independent of the GHC proposals process. But I’d value the opinion of other GHC devs. Alan has done a prototype first step, which worked out rather well. Rather than having HsExpr Id (which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have HsExpr GhcTc meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney. Please ask questions etc. Alan and Shayan can record the answers in the wiki. I’m inclined to go ahead with this, so yell soon if you disagree. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 24 May 2017 22:52 To: ghc-devs at haskell.org Subject: Trees that Grow in the hsSyn AST Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say that >I am supportive! > > Simon We have set up a Wiki page at [2] describing a prototype implementation of the first stage of this for the hsSyn AST, which is to change the polymorphic variable from one of RdrName / Name / Id to an index type. This is presented as a fabricator diff at [3]. Please take a look and provide feedback. Regards Alan [1] http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf> [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [3] https://phabricator.haskell.org/D3609 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto at toscat.net Fri May 26 09:11:05 2017 From: alberto at toscat.net (Alberto Valverde) Date: Fri, 26 May 2017 11:11:05 +0200 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: Message-ID: Hi Ryan, Some preogress... The cabal issues I reported seem more of a nix issue but I'm not sure what is causing them. FWIW, nix does not use cabal-install at all but instead compiles the Setup.hs script and runs that. The weird thing is that i'm trying to reproduce what the nix haskell-package builder [1] does and the problem I described (no Main.hs could be found) does not occur but instead the Main.hs module fails to compile due to an unrelated error. So it seems that, somehow, the unrelated compile error is being mistaken by a lack of module. Even weirder is that the snap-server.cabal says that the failing executables should only be built when flags are enabled (which are disabled by default) but they are being built anyway when nix calls Setup, even when I explicitly disable them via nix. The nix build log [2] even says that the flags (build-pong and build-testserver) are disabled! However, If I manually execute Setup the configure flags are honored. I'll continue to investigate to try and make some sense of this but I think it's not cabal's fault so feel free to ignore me for the meantime. I'll chime back if/when I find it is an issue with the new Cabal. Thanks, Alberto [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/generic-builder.nix [2] https://gist.github.com/albertov/eee8af04eeca9f946ab107d416256a05#file-gistfile1-txt-L21 On Tue, May 23, 2017 at 6:28 PM, Ryan Scott wrote: > Alberto, > > > I've manage to reproduce the CK bug without any external dependencies and > > opened a ticket with an attached module that fails to compile with > > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2. > > Thanks for doing this! > > > Will hopefully follow up soon with the Cabal issues I'm experiencing > > One thing that might be useful to do is to invoke Cabal with high > verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised > if Nix was passing some uncommonly used flags that have regressed in recent > versions of Cabal. > > Ryan S. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri May 26 11:14:13 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 26 May 2017 13:14:13 +0200 Subject: HsParTy In-Reply-To: References: Message-ID: When I was working through the ppr to use HsParTy everywhere it was not clear whether there were any usages that required maybeParen, so I left it in. I can try to strip then all out and see what happens. Alan On 26 May 2017 at 10:54, Simon Peyton Jones wrote: > Alan > > Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’? > Shouldn’t the parens all be put in by HsParTy? > > I tripped over this when I mistakenly added what I thought were missing > maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error > by a test in tests/printer. > > So why are there /any/ maybeParen calls? > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 26 11:32:44 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 May 2017 11:32:44 +0000 Subject: HsParTy In-Reply-To: References: Message-ID: I can try to strip then all out and see what happens. That’d be good! With a Note to explain why… We still need ctxt_prec, I think, to pass to the ordinary type pretty-printer, when we have HsCoreTy. Simon From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] Sent: 26 May 2017 12:14 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: HsParTy When I was working through the ppr to use HsParTy everywhere it was not clear whether there were any usages that required maybeParen, so I left it in. I can try to strip then all out and see what happens. Alan On 26 May 2017 at 10:54, Simon Peyton Jones > wrote: Alan Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’? Shouldn’t the parens all be put in by HsParTy? I tripped over this when I mistakenly added what I thought were missing maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by a test in tests/printer. So why are there /any/ maybeParen calls? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto at toscat.net Fri May 26 13:41:43 2017 From: alberto at toscat.net (Alberto Valverde) Date: Fri, 26 May 2017 15:41:43 +0200 Subject: [ANNOUNCE] GHC 8.2.1 release candidate 2 In-Reply-To: References: Message-ID: It's most certainly not a Cabal issue. The problem only manifests itself on packages which I have applied Nix's "doJailbreak", which mangles the .cabal file in order to remove bounds. Maybe the format of the .cabal has changed slightly and the parser it uses trips up? Anyway, sorry for the noise On Fri, May 26, 2017 at 11:11 AM, Alberto Valverde wrote: > Hi Ryan, > > Some preogress... The cabal issues I reported seem more of a nix issue but > I'm not sure what is causing them. FWIW, nix does not use cabal-install at > all but instead compiles the Setup.hs script and runs that. > > The weird thing is that i'm trying to reproduce what the nix > haskell-package builder [1] does and the problem I described (no Main.hs > could be found) does not occur but instead the Main.hs module fails to > compile due to an unrelated error. So it seems that, somehow, the unrelated > compile error is being mistaken by a lack of module. > > Even weirder is that the snap-server.cabal says that the failing > executables should only be built when flags are enabled (which are disabled > by default) but they are being built anyway when nix calls Setup, even when > I explicitly disable them via nix. The nix build log [2] even says that the > flags (build-pong and build-testserver) are disabled! However, If I > manually execute Setup the configure flags are honored. > > I'll continue to investigate to try and make some sense of this but I > think it's not cabal's fault so feel free to ignore me for the meantime. > I'll chime back if/when I find it is an issue with the new Cabal. > > Thanks, > Alberto > > [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/ > development/haskell-modules/generic-builder.nix > [2] https://gist.github.com/albertov/eee8af04eeca9f946ab107d416256a > 05#file-gistfile1-txt-L21 > > On Tue, May 23, 2017 at 6:28 PM, Ryan Scott > wrote: > >> Alberto, >> >> > I've manage to reproduce the CK bug without any external dependencies >> and >> > opened a ticket with an attached module that fails to compile with >> > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2. >> >> Thanks for doing this! >> >> > Will hopefully follow up soon with the Cabal issues I'm experiencing >> >> One thing that might be useful to do is to invoke Cabal with high >> verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised >> if Nix was passing some uncommonly used flags that have regressed in recent >> versions of Cabal. >> >> Ryan S. >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat May 27 08:01:55 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 27 May 2017 17:01:55 +0900 Subject: Status of ircbfowse Message-ID: Dear devs, Does anyone know about the operational status of ircbrowse[1]? Recently, it has been stopped all the time. Did that useful service end? [1]: http://ircbrowse.net/ Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto at toscat.net Sat May 27 08:29:14 2017 From: alberto at toscat.net (Alberto Valverde) Date: Sat, 27 May 2017 10:29:14 +0200 Subject: Cross-compiling Template Haskell via -fexternal-interpreter and IPC In-Reply-To: <87vaynpojc.fsf@smart-cactus.org> References: <87furmit8n.fsf@smart-cactus.org> <87vaynpojc.fsf@smart-cactus.org> Message-ID: Hi Ben, I've just found this email from almost a year ago. Sorry for ignoring it until now. Given the date it was sent I think I missed it when it was fresh while I was on vacation. Regarding the question, I have abandoned the work I was doing on getting cross-compilation for Windows to work since my employer decided a Windows build for the app we were developing could wait some time and tasked me we something else. However, I see that Moritz is working on cross-compilation right now so I'll try get some time to see if I can get his approach to work for our use-case and give some feedback or help in any way. Alberto On Fri, Aug 26, 2016 at 4:56 PM, Ben Gamari wrote: > Alberto Valverde writes: > > > On Thu, Jul 7, 2016 at 9:30 AM, Simon Marlow wrote: > > > >> I agree, named pipes are probably a better plan, perhaps a better > solution > >> overall than the way we currently pass FD numbers on the command line. > Do > >> named pipes work work as expected through wine? We would have to be > >> careful to clean them up again afterwards. > >> > > > > I've implemented IPC with named pipes and it appeared to work through > wine > > but now I'm investigating an issue which causes GHC to "freeze" when > > talking to the external interpreter when it is not running on a TTY (ie: > in > > a build process) > > Hi Alterto, > > What ever happened to this? Is there any way I can be of assistance? It > would be great to get this merged. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Sat May 27 08:51:26 2017 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Sat, 27 May 2017 16:51:26 +0800 Subject: Cross-compiling Template Haskell via -fexternal-interpreter and IPC In-Reply-To: References: <87furmit8n.fsf@smart-cactus.org> <87vaynpojc.fsf@smart-cactus.org> Message-ID: Hi Alberto, let me know if I can be of help. As you likely saw I’ve been writing this all up on https://medium.com/@zw3rk. With the outstanding diffs[1], this should hopefully just work. As I haven’t used windows or know the linker on windows, I’m not perfectly sure about the implications. It could *just work* though. Maybe you can even use the GHCSlave’s Slave.hs[2] for the Raspberry Pi for windows, as it doesn’t encode any Raspberry Pi specifics. All you would need is to run GHCSlave on wine / or a windows system with some form of network interface, so that the iserv-proxy and GHCSlave can communicate. Cheers, Moritz [1]: you can just use the my-ghc branch from https://github.com/zw3rk/ghc [2]: https://github.com/zw3rk/ghc-slave/blob/master/RPi/Slave.hs > On May 27, 2017, at 4:29 PM, Alberto Valverde wrote: > > Hi Ben, > > I've just found this email from almost a year ago. Sorry for ignoring it until now. Given the date it was sent I think I missed it when it was fresh while I was on vacation. > > Regarding the question, I have abandoned the work I was doing on getting cross-compilation for Windows to work since my employer decided a Windows build for the app we were developing could wait some time and tasked me we something else. > > However, I see that Moritz is working on cross-compilation right now so I'll try get some time to see if I can get his approach to work for our use-case and give some feedback or help in any way. > > Alberto > > On Fri, Aug 26, 2016 at 4:56 PM, Ben Gamari wrote: > Alberto Valverde writes: > > > On Thu, Jul 7, 2016 at 9:30 AM, Simon Marlow wrote: > > > >> I agree, named pipes are probably a better plan, perhaps a better solution > >> overall than the way we currently pass FD numbers on the command line. Do > >> named pipes work work as expected through wine? We would have to be > >> careful to clean them up again afterwards. > >> > > > > I've implemented IPC with named pipes and it appeared to work through wine > > but now I'm investigating an issue which causes GHC to "freeze" when > > talking to the external interpreter when it is not running on a TTY (ie: in > > a build process) > > Hi Alterto, > > What ever happened to this? Is there any way I can be of assistance? It > would be great to get this merged. > > Cheers, > > - Ben > From ben at smart-cactus.org Sat May 27 17:01:03 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 27 May 2017 13:01:03 -0400 Subject: Status of ircbfowse In-Reply-To: References: Message-ID: <87h906z12o.fsf@ben-laptop.smart-cactus.org> Takenobu Tani writes: > Dear devs, > > Does anyone know about the operational status of ircbrowse[1]? > Recently, it has been stopped all the time. > Did that useful service end? > I suspect it sadly fell victim to Chris Done's slight retreat from open source projects due to injury. I agree that it was a fantastic service and I'm sure he would be happy if someone stepped up to help maintain it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From michal.terepeta at gmail.com Sat May 27 17:58:11 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sat, 27 May 2017 17:58:11 +0000 Subject: Removing Hoopl dependency? Message-ID: Hi all, I was looking at removing the `BlockId` type synonym in favor of Hoopl's `Label` (there was already a TODO and it is a bit confusing). But once I've started making the changes, I've realized that in a bunch of places this makes the code *less* readable. Mostly because of `CLabel` (sounds similar but is something quite different and having to rename local variables from `label` to `clabel` is not great). I started to look at alternatives and noticed that in general the interface between GHC and Hoopl is quite noisy and confusing: - Hoopl has `Label` which is GHC's `BlockId` but different than GHC's `CLabel` - Hoopl has `Unique` which is different than GHC's `Unique` - Hoopl has `Unique{Map,Set}` which are different than GHC's `Uniq{FM,Set}` - GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is needed just to filter the exposed functions (filter out some of the Hoopl's and add the GHC ones). - Working in `cmm/` requires constant switching between GHC code and Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC, the actual implementation of `Block`/`Graph` are defined in Hoopl, etc.) GHC is actually using only a small subset of Hoopl (e.g., the fixpoint computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was wondering - maybe it's worth to simply drop the dependency on Hoopl? (and copy the code that is actually necessary in GHC) I've done an experiment in [1] (to see how much we'd need to actually copy) and I really like the result: - We can remove one external dependency and git submodule at the cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4 modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer needed) - We should be able to fix all of the above issues and make the code easier to understand (less code, everything in one repo, fewer concepts). - It's going to be easier to change things since we don't need to worry about changing the public interface of Hoopl (it's a standalone package on Hackage and other people already depend on the current behavior). What do you think? Does anyone think we shouldn't do this? Thanks, Michal [1] Branch: https://github.com/michalt/ghc/tree/hoopl/no-hoopl Diff: https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hoopl For now I just copied the code/updated imports and didn't do any cleanups, but I'd be happy to do them in subsequent PRs -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sat May 27 18:28:09 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 27 May 2017 20:28:09 +0200 Subject: Removing Hoopl dependency? In-Reply-To: (Michal Terepeta's message of "Sat, 27 May 2017 17:58:11 +0000") References: Message-ID: <87y3tiduiu.fsf@gmail.com> On 2017-05-27 at 19:58:11 +0200, Michal Terepeta wrote: [...] > I've done an experiment in [1] (to see how much we'd need to actually > copy) and I really like the result: > - We can remove one external dependency and git submodule at the > cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4 > modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer > needed) > - We should be able to fix all of the above issues and make the code > easier to understand (less code, everything in one repo, fewer > concepts). > - It's going to be easier to change things since we don't need to > worry about changing the public interface of Hoopl (it's a > standalone package on Hackage and other people already depend on the > current behavior). > > What do you think? Does anyone think we shouldn't do this? It appears to me that in this case, the benefits in gained flexibility outweight the cost of independent development and potential loss of synergies. So I'm +1 on this. From ben at smart-cactus.org Sat May 27 19:09:13 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 27 May 2017 15:09:13 -0400 Subject: Removing Hoopl dependency? In-Reply-To: References: Message-ID: <87bmqeyv52.fsf@ben-laptop.smart-cactus.org> Michal Terepeta writes: > Hi all, > ... > > What do you think? Does anyone think we shouldn't do this? > I think this seems quite reasonable. Given that hoopl will need changes to be truly useful to GHC, it seems quite reasonable to take the parts we need and iterate independently on the rest. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mle+hs at mega-nerd.com Sat May 27 22:51:41 2017 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 28 May 2017 08:51:41 +1000 Subject: Removing Hoopl dependency? In-Reply-To: References: Message-ID: <20170528085141.ec81f3eb3a76f9d8420472c6@mega-nerd.com> Michal Terepeta wrote: > What do you think? Does anyone think we shouldn't do this? Makes sense. I'm +1 on this. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From takenobu.hs at gmail.com Sun May 28 01:35:01 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 28 May 2017 10:35:01 +0900 Subject: Status of ircbfowse In-Reply-To: <87h906z12o.fsf@ben-laptop.smart-cactus.org> References: <87h906z12o.fsf@ben-laptop.smart-cactus.org> Message-ID: Hi Ben, Thank you very much for your kind explanation. I understood the situation. I hope there are people who can help in this field. Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sun May 28 10:55:18 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 28 May 2017 12:55:18 +0200 Subject: HsParTy In-Reply-To: References: Message-ID: See 3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e On 26 May 2017 at 13:32, Simon Peyton Jones wrote: > I can try to strip then all out and see what happens. > > That’d be good! With a Note to explain why… > > > > We still need ctxt_prec, I think, to pass to the ordinary type > pretty-printer, when we have HsCoreTy. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Sun May 28 15:52:28 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sun, 28 May 2017 17:52:28 +0200 Subject: Finding out if a binding is externally visible Message-ID: Hi all, I'm tinkering around with GHCs Call Arity Analysis and Demand Analysis as part of my Master's thesis. The usage analysis part is what I'm interested in in particular. After quite some time spent debugging absent errors, I noticed that certain top-level bindings aren't exported, but still visible in other modules through generated RULE pragmas (e.g. through class instance specialization). These bindings were considered absent in my combined analysis, explaining the very sporadic absent errors I was getting. Is there some function that tells me if an identifier is 'externally visible' in that sense? I think https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what I'm after, but I want to be sure. Does that function already work when the Ids are still local? Greetings, Sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Sun May 28 16:01:46 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sun, 28 May 2017 18:01:46 +0200 Subject: Finding out if a binding is externally visible In-Reply-To: References: Message-ID: I just stumbled over Note [ExportFlag on binders] in Var.hs, which indicates this might be a bug, right? On Sun, May 28, 2017 at 5:52 PM, Sebastian Graf wrote: > Hi all, > > I'm tinkering around with GHCs Call Arity Analysis and Demand Analysis as > part of my Master's thesis. The usage analysis part is what I'm interested > in in particular. > > After quite some time spent debugging absent errors, I noticed that > certain top-level bindings aren't exported, but still visible in other > modules through generated RULE pragmas (e.g. through class instance > specialization). These bindings were considered absent in my combined > analysis, explaining the very sporadic absent errors I was getting. > > Is there some function that tells me if an identifier is 'externally > visible' in that sense? I think https://downloads. > haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/GHC. > html#v:isExternalName is what I'm after, but I want to be sure. Does that > function already work when the Ids are still local? > > Greetings, > Sebastian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sun May 28 17:39:07 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 28 May 2017 17:39:07 +0000 Subject: Removing Hoopl dependency? In-Reply-To: <20170528085141.ec81f3eb3a76f9d8420472c6@mega-nerd.com> References: <20170528085141.ec81f3eb3a76f9d8420472c6@mega-nerd.com> Message-ID: Cool, thanks for quick replies! I've sent out https://phabricator.haskell.org/D3616 Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun May 28 20:33:47 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 28 May 2017 16:33:47 -0400 Subject: Finding out if a binding is externally visible In-Reply-To: References: Message-ID: <1496003627.12459.0.camel@joachim-breitner.de> Hi Sebastian, welcome on this list! Am Sonntag, den 28.05.2017, 17:52 +0200 schrieb Sebastian Graf: > Is there some function that tells me if an identifier is 'externally > visible' in that sense? I think https://downloads.haskell.org/~ghc/8. > 0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what > I'm after, but I want to be sure. Does that function already work > when the Ids are still local? I would expect isExportedId :: Var -> Bool to do precisely that. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Sun May 28 21:01:06 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 28 May 2017 21:01:06 +0000 Subject: [commit: ghc] master: Fix test output after 'Some tidying up of type pretty-printing' (09d5c99) In-Reply-To: <20170527144501.BC4AE3A585@ghc.haskell.org> References: <20170527144501.BC4AE3A585@ghc.haskell.org> Message-ID: Sorry about this. I carefully fixed all these and validated...thanks for fixing Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 27 May 2017 15:45 | To: ghc-commits at haskell.org | Subject: [commit: ghc] master: Fix test output after 'Some tidying up of | type pretty-printing' (09d5c99) | | Repository : ssh://git at 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%2F09d5c993aae208e3d34a9e715297922b6ea42b3 | f%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2a237b8dabd42f3684f08d4 | a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311& | sdata=VM04DE0U1RBSmJjbV6vCwu8LPvyqwqfo2K1I03W1cW4%3D&reserved=0 | | >--------------------------------------------------------------- | | commit 09d5c993aae208e3d34a9e715297922b6ea42b3f | Author: Bartosz Nitka | Date: Sat May 27 07:42:26 2017 -0700 | | Fix test output after 'Some tidying up of type pretty-printing' | | Most are cosmetic. There's an interesting change in T7861, | but the error is still accurate. | | | >--------------------------------------------------------------- | | 09d5c993aae208e3d34a9e715297922b6ea42b3f | testsuite/tests/typecheck/should_run/T7861.stderr | 6 +----- | testsuite/tests/typecheck/should_run/Typeable1.stderr | 2 +- | testsuite/tests/typecheck/should_run/tcrun045.stderr | 6 +++--- | 3 files changed, 5 insertions(+), 9 deletions(-) | | diff --git a/testsuite/tests/typecheck/should_run/T7861.stderr | b/testsuite/tests/typecheck/should_run/T7861.stderr | index e9ee5e9..4a1c030 100644 | --- a/testsuite/tests/typecheck/should_run/T7861.stderr | +++ b/testsuite/tests/typecheck/should_run/T7861.stderr | @@ -1,9 +1,5 @@ | T7861: T7861.hs:10:5: error: | - • Couldn't match type ‘a’ with ‘[a]’ | - ‘a’ is a rigid type variable bound by | - the type signature for: | - f :: forall a. (forall b. a) -> a | - at T7861.hs:9:1-23 | + • Occurs check: cannot construct the infinite type: a ~ [a] | Expected type: (forall b. a) -> a | Actual type: (forall b. a) -> [a] | • In the expression: doA | diff --git a/testsuite/tests/typecheck/should_run/Typeable1.stderr | b/testsuite/tests/typecheck/should_run/Typeable1.stderr | index 9a7d3b7..65f6fd4 100644 | --- a/testsuite/tests/typecheck/should_run/Typeable1.stderr | +++ b/testsuite/tests/typecheck/should_run/Typeable1.stderr | @@ -7,7 +7,7 @@ Typeable1.hs:22:5: error: | App :: forall k2 (t :: k2). | () => | forall k1 (a :: k1 -> k2) (b :: k1). | - t ~ a b => | + (t ~ a b) => | TypeRep a -> TypeRep b -> TypeRep t, | in a pattern binding in | 'do' block | diff --git a/testsuite/tests/typecheck/should_run/tcrun045.stderr | b/testsuite/tests/typecheck/should_run/tcrun045.stderr | index 19fca10..f6b1652 100644 | --- a/testsuite/tests/typecheck/should_run/tcrun045.stderr | +++ b/testsuite/tests/typecheck/should_run/tcrun045.stderr | @@ -1,18 +1,18 @@ | | tcrun045.hs:11:10: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking an instance declaration | In the instance declaration for ‘C Int’ | | tcrun045.hs:24:1: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking the super-classes of class ‘D’ | In the class declaration for ‘D’ | | tcrun045.hs:27:10: error: | • Illegal implicit parameter ‘?imp::Int’ | - • In the context: (?imp::Int) | + • In the context: ?imp::Int | While checking an instance declaration | In the instance declaration for ‘D Int’ | | _______________________________________________ | ghc-commits mailing list | ghc-commits at 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%7Ca2a237b8dabd42f3684f08d4 | a50ef9ad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636314931129891311& | sdata=MYdcDMAQcDnFVFlc0aNT1NXPHFa%2FT%2FSpNiDIu4hrvOY%3D&reserved=0 From simonpj at microsoft.com Sun May 28 21:30:11 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sun, 28 May 2017 21:30:11 +0000 Subject: Removing Hoopl dependency? In-Reply-To: References: Message-ID: Is there really a compelling case for forking Hoopl? I was talking to Kavon last week about doing exactly the opposite: using Hoopl more wholeheartedly! Before going ahead with this, let’s remember the downsides · If we fork Hoopl, improvements in one place will not be seen in the other. GHC originally used its own containers library but now uses ‘containers’, most of which is irrelevant to GHC, just to pick up the work that has been done to make ‘containers’ fast. Similarly, GHC has a clone of ‘pretty’, but someone is working (I think) to make GHC use ‘pretty’. · It’s not clear to me why GHC has a clone of parts of Hoopl. Would it not be better just to make Hoopl faster? If anything I ‘d like to use Hoopl more in Cmm optimisation passes in GHC, so we may want to use more of Hoopl’s facilities. The main reason you suggest for forking is that there are some awkward name clashes. Surely we could resolve these? e.g we could change CLabel in GHC; or agree with Hoopl maintainers that BlockId would be more helpful than Label. You mention that Hoopl uses Unique set/map. Why not use ‘containers’ for that? (Like GHC!) Let’s discuss this a bit more before executing I’m also interested to know: · who is actively working on Hoopl (Michael, Sophie, …)? · how are you using it (within GHC, or somewhere else)? It’d be good to review and update https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup. Are there any other improvements planned? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michal Terepeta Sent: 27 May 2017 18:58 To: ghc-devs Subject: Removing Hoopl dependency? Hi all, I was looking at removing the `BlockId` type synonym in favor of Hoopl's `Label` (there was already a TODO and it is a bit confusing). But once I've started making the changes, I've realized that in a bunch of places this makes the code *less* readable. Mostly because of `CLabel` (sounds similar but is something quite different and having to rename local variables from `label` to `clabel` is not great). I started to look at alternatives and noticed that in general the interface between GHC and Hoopl is quite noisy and confusing: - Hoopl has `Label` which is GHC's `BlockId` but different than GHC's `CLabel` - Hoopl has `Unique` which is different than GHC's `Unique` - Hoopl has `Unique{Map,Set}` which are different than GHC's `Uniq{FM,Set}` - GHC has its own specialized copy of `Dataflow`, so `cmm/Hoopl` is needed just to filter the exposed functions (filter out some of the Hoopl's and add the GHC ones). - Working in `cmm/` requires constant switching between GHC code and Hoopl (`CmmNode`/`CmmGraph`/`CmmBlock` and dataflow stuff is in GHC, the actual implementation of `Block`/`Graph` are defined in Hoopl, etc.) GHC is actually using only a small subset of Hoopl (e.g., the fixpoint computation is copied/specialized: `cmm/Hoopl/Dataflow`). So I was wondering - maybe it's worth to simply drop the dependency on Hoopl? (and copy the code that is actually necessary in GHC) I've done an experiment in [1] (to see how much we'd need to actually copy) and I really like the result: - We can remove one external dependency and git submodule at the cost of only 5 new modules in `cmm/Hoopl` (net gain of only 4 modules: we add 5 new but can remove `cmm/Hoopl`, which is no longer needed) - We should be able to fix all of the above issues and make the code easier to understand (less code, everything in one repo, fewer concepts). - It's going to be easier to change things since we don't need to worry about changing the public interface of Hoopl (it's a standalone package on Hackage and other people already depend on the current behavior). What do you think? Does anyone think we shouldn't do this? Thanks, Michal [1] Branch: https://github.com/michalt/ghc/tree/hoopl/no-hoopl Diff: https://github.com/ghc/ghc/compare/master...michalt:hoopl/no-hoopl For now I just copied the code/updated imports and didn't do any cleanups, but I'd be happy to do them in subsequent PRs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Sun May 28 21:53:37 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sun, 28 May 2017 23:53:37 +0200 Subject: Finding out if a binding is externally visible In-Reply-To: <1496003627.12459.0.camel@joachim-breitner.de> References: <1496003627.12459.0.camel@joachim-breitner.de> Message-ID: > welcome on this list! Thanks :) isExportedId :: Var -> Bool That's what I have been using so far, but I found that said RULE pragmas mentioned non-exported identifiers. Or maybe it was just some temporary build system mess-up, I'll work on a reproduction... On Sun, May 28, 2017 at 10:33 PM, Joachim Breitner wrote: > Hi Sebastian, > > welcome on this list! > > Am Sonntag, den 28.05.2017, 17:52 +0200 schrieb Sebastian Graf: > > Is there some function that tells me if an identifier is 'externally > > visible' in that sense? I think https://downloads.haskell.org/~ghc/8. > > 0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what > > I'm after, but I want to be sure. Does that function already work > > when the Ids are still local? > > I would expect > > isExportedId :: Var -> Bool > > to do precisely that. > > Greetings, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Mon May 29 08:40:44 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 29 May 2017 10:40:44 +0200 Subject: Finding out if a binding is externally visible In-Reply-To: References: <1496003627.12459.0.camel@joachim-breitner.de> Message-ID: OK, I attached an example for a specialization of Show for a special case of a custom type, like Ratio in GHC.Real . My invokation with a custom GHC (8.0-based) was like this: $ Module.hs -ddump-simpl -O -fforce-recomp At the begin of the log, I listed all exported top-level identifiers, the only interesting of which is `$fShowRatio :: Show a => Show (Ratio a)`, the default implementation. Note that at the bottom, there are RULEs stating the specialization for `Show Integer`, but that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)` isn't otherwise reachable from any exported top-level identifier. Same goes for any of the specialized dictionary methods. Now consider what happens if we request a `Show (Ratio Integer)` dictionary in another module: GHC finds the exported default dictionary `$fShowRatio :: Show a => Show (Ratio a)`, but then applies a specialization RULE that will effectively use the presumably absent `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)`. In my case, my custom GHC would substitute away the `showString " % "` for an `absentError "lvl [Char]"` and crash in subtle ways. The only reason this isn't happening for GHC master is that DmdAnal does consider all top-level arguments to be used, instead of only the exported ones (which is what CallArity does). On Sun, May 28, 2017 at 11:53 PM, Sebastian Graf wrote: > > welcome on this list! > > > Thanks :) > > isExportedId :: Var -> Bool > > > That's what I have been using so far, but I found that said RULE pragmas > mentioned non-exported identifiers. Or maybe it was just some temporary > build system mess-up, I'll work on a reproduction... > > On Sun, May 28, 2017 at 10:33 PM, Joachim Breitner < > mail at joachim-breitner.de> wrote: > >> Hi Sebastian, >> >> welcome on this list! >> >> Am Sonntag, den 28.05.2017, 17:52 +0200 schrieb Sebastian Graf: >> > Is there some function that tells me if an identifier is 'externally >> > visible' in that sense? I think https://downloads.haskell.org/~ghc/8. >> > 0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what >> > I'm after, but I want to be sure. Does that function already work >> > when the Ids are still local? >> >> I would expect >> >> isExportedId :: Var -> Bool >> >> to do precisely that. >> >> Greetings, >> Joachim >> >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- exported ids: [r7 :-> $tcRatio, ra :-> $trModule, rc :-> $tc'MkRatio, rt :-> $fShowRatio] [1 of 1] Compiling Module ( Module.hs, Module.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 195, types: 233, coercions: 0} -- RHS size: {terms: 2, types: 3, coercions: 0} Module.$fShowRatio1 :: [Char] [GblId, Str=x] Module.$fShowRatio1 = Control.Exception.Base.absentError @ 'GHC.Types.PtrRepLifted @ [Char] "lvl [Char]"# -- RHS size: {terms: 17, types: 14, coercions: 0} Module.$w$s$cshowsPrec [InlPrag=[0]] :: Integer -> Integer -> String -> (# Char, [Char] #) [GblId, Arity=3, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0 0] 130 0}] Module.$w$s$cshowsPrec = \ (ww_s15t :: Integer) (ww1_s15u :: Integer) (w_s15q :: String) -> GHC.Show.$w$cshowsPrec1 0# ww_s15t (++ @ Char Module.$fShowRatio1 (case GHC.Show.$w$cshowsPrec1 0# ww1_s15u w_s15q of { (# ww3_a12Z, ww4_a130 #) -> GHC.Types.: @ Char ww3_a12Z ww4_a130 })) -- RHS size: {terms: 15, types: 18, coercions: 0} Module.$fShowRatio_$s$cshowsPrec [InlPrag=INLINE[0]] :: Int -> Ratio Integer -> ShowS [GblId, Arity=3, Str=m2, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] (w1_s15p [Occ=Once!] :: Ratio Integer) (w2_s15q [Occ=Once] :: String) -> case w1_s15p of { MkRatio ww1_s15t [Occ=Once] ww2_s15u [Occ=Once] -> case Module.$w$s$cshowsPrec ww1_s15t ww2_s15u w2_s15q of { (# ww4_s15T [Occ=Once], ww5_s15U [Occ=Once] #) -> GHC.Types.: @ Char ww4_s15T ww5_s15U } }}] Module.$fShowRatio_$s$cshowsPrec = \ _ [Occ=Dead] (w1_s15p :: Ratio Integer) (w2_s15q :: String) -> case w1_s15p of { MkRatio ww1_s15t ww2_s15u -> case Module.$w$s$cshowsPrec ww1_s15t ww2_s15u w2_s15q of { (# ww4_s15T, ww5_s15U #) -> GHC.Types.: @ Char ww4_s15T ww5_s15U } } -- RHS size: {terms: 14, types: 17, coercions: 0} lvl_r175 :: Ratio Integer -> String -> [Char] [GblId, Arity=2, Str=m2] lvl_r175 = \ (w_s15p :: Ratio Integer) (w1_s15q [OS=OneShot] :: String) -> case w_s15p of { MkRatio ww1_s15t ww2_s15u -> case Module.$w$s$cshowsPrec ww1_s15t ww2_s15u w1_s15q of { (# ww4_s15T, ww5_s15U #) -> GHC.Types.: @ Char ww4_s15T ww5_s15U } } -- RHS size: {terms: 6, types: 6, coercions: 0} Module.$fShowRatio_$s$cshowList :: [Ratio Integer] -> ShowS [GblId, Arity=2, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (ls_a11u [Occ=Once] :: [Ratio Integer]) (s_a11v [Occ=Once] :: String) -> GHC.Show.showList__ @ (Ratio Integer) (Module.$fShowRatio_$s$cshowsPrec GHC.Show.shows21) ls_a11u s_a11v}] Module.$fShowRatio_$s$cshowList = \ (ls_a11u :: [Ratio Integer]) (s_a11v :: String) -> GHC.Show.showList__ @ (Ratio Integer) lvl_r175 ls_a11u s_a11v -- RHS size: {terms: 13, types: 17, coercions: 0} Module.$fShowRatio_$s$cshow :: Ratio Integer -> String [GblId, Arity=1, Str=m2, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x_a11A [Occ=Once] :: Ratio Integer) -> Module.$fShowRatio_$s$cshowsPrec GHC.Show.shows21 x_a11A (GHC.Types.[] @ Char)}] Module.$fShowRatio_$s$cshow = \ (x_a11A :: Ratio Integer) -> case x_a11A of { MkRatio ww1_s15t ww2_s15u -> case Module.$w$s$cshowsPrec ww1_s15t ww2_s15u (GHC.Types.[] @ Char) of { (# ww4_s15T, ww5_s15U #) -> GHC.Types.: @ Char ww4_s15T ww5_s15U } } -- RHS size: {terms: 4, types: 2, coercions: 0} Module.$fShowRatio_$s$fShowRatio [InlPrag=CONLIKE] :: Show (Ratio Integer) [GblId, Str=m, Unf=DFun: \ -> GHC.Show.C:Show TYPE: Ratio Integer Module.$fShowRatio_$s$cshowsPrec Module.$fShowRatio_$s$cshow Module.$fShowRatio_$s$cshowList] Module.$fShowRatio_$s$fShowRatio = GHC.Show.C:Show @ (Ratio Integer) Module.$fShowRatio_$s$cshowsPrec Module.$fShowRatio_$s$cshow Module.$fShowRatio_$s$cshowList -- RHS size: {terms: 2, types: 0, coercions: 0} Module.$trModule2 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] Module.$trModule2 = GHC.Types.TrNameS "main"# -- RHS size: {terms: 2, types: 0, coercions: 0} Module.$trModule1 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 40 20}] Module.$trModule1 = GHC.Types.TrNameS "Module"# -- RHS size: {terms: 3, types: 0, coercions: 0} Module.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] Module.$trModule = GHC.Types.Module Module.$trModule2 Module.$trModule1 -- RHS size: {terms: 2, types: 0, coercions: 0} Module.$tc'MkRatio1 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 40 20}] Module.$tc'MkRatio1 = GHC.Types.TrNameS "'MkRatio"# -- RHS size: {terms: 5, types: 0, coercions: 0} Module.$tc'MkRatio :: GHC.Types.TyCon [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] Module.$tc'MkRatio = GHC.Types.TyCon 17366225934913587629## 4537871616602442082## Module.$trModule Module.$tc'MkRatio1 -- RHS size: {terms: 2, types: 0, coercions: 0} Module.$tcRatio1 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=m1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 40 20}] Module.$tcRatio1 = GHC.Types.TrNameS "Ratio"# -- RHS size: {terms: 5, types: 0, coercions: 0} Module.$tcRatio :: GHC.Types.TyCon [GblId, Caf=NoCafRefs, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] Module.$tcRatio = GHC.Types.TyCon 8023108143494670257## 8265606921531866646## Module.$trModule Module.$tcRatio1 -- RHS size: {terms: 2, types: 0, coercions: 0} Module.$fShowRatio2 :: [Char] [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Module.$fShowRatio2 = GHC.CString.unpackCString# " % "# -- RHS size: {terms: 20, types: 14, coercions: 0} Module.$w$cshowsPrec [InlPrag=[0]] :: forall a. Show a => a -> a -> ShowS [GblId, Arity=3, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [60 0 0] 180 60}] Module.$w$cshowsPrec = \ (@ a_s15A) (w_s15B :: Show a) (ww_s15G [OS=OneShot] :: a) (ww1_s15H [OS=OneShot] :: a) -> let { f_a11l :: String -> String [LclId] f_a11l = showsPrec @ a w_s15B GHC.Show.shows21 ww_s15G } in let { g_X12m :: String -> String [LclId] g_X12m = showsPrec @ a w_s15B GHC.Show.shows21 ww1_s15H } in \ (x_X12r :: String) -> f_a11l (++ @ Char Module.$fShowRatio2 (g_X12m x_X12r)) -- RHS size: {terms: 11, types: 12, coercions: 0} Module.$fShowRatio_$cshowsPrec [InlPrag=INLINE[0]] :: forall a. Show a => Int -> Ratio a -> ShowS [GblId, Arity=3, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_s15A) (w_s15B [Occ=Once] :: Show a) _ [Occ=Dead] (w2_s15D [Occ=Once!] :: Ratio a) -> case w2_s15D of { MkRatio ww1_s15G [Occ=Once] ww2_s15H [Occ=Once] -> Module.$w$cshowsPrec @ a w_s15B ww1_s15G ww2_s15H }}] Module.$fShowRatio_$cshowsPrec = \ (@ a_s15A) (w_s15B :: Show a) _ [Occ=Dead] (w2_s15D :: Ratio a) -> case w2_s15D of { MkRatio ww1_s15G ww2_s15H -> Module.$w$cshowsPrec @ a w_s15B ww1_s15G ww2_s15H } -- RHS size: {terms: 15, types: 10, coercions: 0} Module.$w$cshow [InlPrag=[0]] :: forall a. Show a => a -> a -> String [GblId, Arity=3, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [60 0 0] 130 0}] Module.$w$cshow = \ (@ a_s15K) (w_s15L :: Show a) (ww_s15P [OS=OneShot] :: a) (ww1_s15Q [OS=OneShot] :: a) -> showsPrec @ a w_s15L GHC.Show.shows21 ww_s15P (++ @ Char Module.$fShowRatio2 (showsPrec @ a w_s15L GHC.Show.shows21 ww1_s15Q (GHC.Types.[] @ Char))) -- RHS size: {terms: 10, types: 11, coercions: 0} Module.$fShowRatio_$cshow [InlPrag=INLINE[0]] :: forall a. Show a => Ratio a -> String [GblId, Arity=2, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_s15K) (w_s15L [Occ=Once] :: Show a) (w1_s15M [Occ=Once!] :: Ratio a) -> case w1_s15M of { MkRatio ww1_s15P [Occ=Once] ww2_s15Q [Occ=Once] -> Module.$w$cshow @ a w_s15L ww1_s15P ww2_s15Q }}] Module.$fShowRatio_$cshow = \ (@ a_s15K) (w_s15L :: Show a) (w1_s15M :: Ratio a) -> case w1_s15M of { MkRatio ww1_s15P ww2_s15Q -> Module.$w$cshow @ a w_s15L ww1_s15P ww2_s15Q } -- RHS size: {terms: 15, types: 17, coercions: 0} Module.$fShowRatio_$cshowList :: forall a. Show a => [Ratio a] -> ShowS [GblId, Arity=3, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=3,unsat_ok=True,boring_ok=False) Tmpl= \ (@ a_a103) ($dShow_a104 [Occ=Once] :: Show a) (ls_a11u [Occ=Once] :: [Ratio a]) (s_a11v [Occ=Once] :: String) -> GHC.Show.showList__ @ (Ratio a) (Module.$fShowRatio_$cshowsPrec @ a $dShow_a104 GHC.Show.shows21) ls_a11u s_a11v}] Module.$fShowRatio_$cshowList = \ (@ a_a103) ($dShow_a104 :: Show a) (ls_a11u :: [Ratio a]) (s_a11v :: String) -> GHC.Show.showList__ @ (Ratio a) (\ (w_s15D :: Ratio a) -> case w_s15D of { MkRatio ww1_s15G ww2_s15H -> Module.$w$cshowsPrec @ a $dShow_a104 ww1_s15G ww2_s15H }) ls_a11u s_a11v -- RHS size: {terms: 9, types: 9, coercions: 0} Module.$fShowRatio [InlPrag=CONLIKE] :: forall a. Show a => Show (Ratio a) [GblId[DFunId], Arity=1, Str=m, ArgUsg=w*U(w*C^w(C^1(U)),A,A),w*U,w*U.., Unf=DFun: \ (@ a_aAM) (v_B1 :: Show a) -> GHC.Show.C:Show TYPE: Ratio a Module.$fShowRatio_$cshowsPrec @ a v_B1 Module.$fShowRatio_$cshow @ a v_B1 Module.$fShowRatio_$cshowList @ a v_B1] Module.$fShowRatio = \ (@ a_a103) ($dShow_a104 :: Show a) -> GHC.Show.C:Show @ (Ratio a) (Module.$fShowRatio_$cshowsPrec @ a $dShow_a104) (Module.$fShowRatio_$cshow @ a $dShow_a104) (Module.$fShowRatio_$cshowList @ a $dShow_a104) ------ Local rules for imported ids -------- "SPEC $cshowsPrec" forall ($dShow_a108 :: Show Integer). Module.$fShowRatio_$cshowsPrec @ Integer $dShow_a108 = Module.$fShowRatio_$s$cshowsPrec "SPEC $cshow" forall ($dShow_a108 :: Show Integer). Module.$fShowRatio_$cshow @ Integer $dShow_a108 = Module.$fShowRatio_$s$cshow "SPEC $cshowList" forall ($dShow_a108 :: Show Integer). Module.$fShowRatio_$cshowList @ Integer $dShow_a108 = Module.$fShowRatio_$s$cshowList "SPEC $fShowRatio" forall ($dShow_a108 :: Show Integer). Module.$fShowRatio @ Integer $dShow_a108 = Module.$fShowRatio_$s$fShowRatio -------------- next part -------------- A non-text attachment was scrubbed... Name: Module.hs Type: application/octet-stream Size: 222 bytes Desc: not available URL: From sgraf1337 at gmail.com Mon May 29 08:43:50 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 29 May 2017 10:43:50 +0200 Subject: Finding out if a binding is externally visible In-Reply-To: References: <1496003627.12459.0.camel@joachim-breitner.de> Message-ID: Also I should add that this is probably not just happening for ids mentioned by RULEs, but also for Unfoldings. E.g. although wrappers are exported, associated workers are not, but still visible through unfoldings. It's not as bad as with RULEs since they are still reachable, but it might make for weird results... And also contradicts Note [ExportFlag on binders] in Var.hs as I understand it. On Mon, May 29, 2017 at 10:40 AM, Sebastian Graf wrote: > OK, I attached an example for a specialization of Show for a special case > of a custom type, like Ratio in GHC.Real > . > My invokation with a custom GHC (8.0-based) was like this: > > $ Module.hs -ddump-simpl -O -fforce-recomp > > At the begin of the log, I listed all exported top-level identifiers, the > only interesting of which is `$fShowRatio :: Show a => Show (Ratio a)`, the > default implementation. Note that at the bottom, there are RULEs stating > the specialization for `Show Integer`, but that the specialized dictionary > `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)` isn't otherwise > reachable from any exported top-level identifier. Same goes for any of the > specialized dictionary methods. > > Now consider what happens if we request a `Show (Ratio Integer)` > dictionary in another module: GHC finds the exported default dictionary > `$fShowRatio :: Show a => Show (Ratio a)`, but then applies a > specialization RULE that will effectively use the presumably absent > `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)`. > > In my case, my custom GHC would substitute away the `showString " % "` for > an `absentError "lvl [Char]"` and crash in subtle ways. The only reason > this isn't happening for GHC master is that DmdAnal does consider all > top-level arguments to be used, instead of only the exported ones (which is > what CallArity does). > > On Sun, May 28, 2017 at 11:53 PM, Sebastian Graf > wrote: > >> >> welcome on this list! >> >> >> Thanks :) >> >> isExportedId :: Var -> Bool >> >> >> That's what I have been using so far, but I found that said RULE pragmas >> mentioned non-exported identifiers. Or maybe it was just some temporary >> build system mess-up, I'll work on a reproduction... >> >> On Sun, May 28, 2017 at 10:33 PM, Joachim Breitner < >> mail at joachim-breitner.de> wrote: >> >>> Hi Sebastian, >>> >>> welcome on this list! >>> >>> Am Sonntag, den 28.05.2017, 17:52 +0200 schrieb Sebastian Graf: >>> > Is there some function that tells me if an identifier is 'externally >>> > visible' in that sense? I think https://downloads.haskell.org/~ghc/8. >>> > 0.1/docs/html/libraries/ghc-8.0.1/GHC.html#v:isExternalName is what >>> > I'm after, but I want to be sure. Does that function already work >>> > when the Ids are still local? >>> >>> I would expect >>> >>> isExportedId :: Var -> Bool >>> >>> to do precisely that. >>> >>> Greetings, >>> Joachim >>> >>> -- >>> Joachim “nomeata” Breitner >>> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >>> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >>> Debian Developer: nomeata at debian.org >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Mon May 29 11:52:44 2017 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Mon, 29 May 2017 11:52:44 +0000 Subject: Removing Hoopl dependency? In-Reply-To: References: Message-ID: On Sun, May 28, 2017 at 11:30 PM Simon Peyton Jones wrote: > Is there really a compelling case for forking Hoopl? I was talking to > Kavon last week about doing exactly the opposite: using Hoopl more > wholeheartedly! > > > > Before going ahead with this, let’s remember the downsides > > · If we fork Hoopl, improvements in one place will not be seen in > the other. GHC originally used its own containers library but now uses > ‘containers’, most of which is irrelevant to GHC, just to pick up the work > that has been done to make ‘containers’ fast. Similarly, GHC has a clone > of ‘pretty’, but someone is working (I think) to make GHC use ‘pretty’. > > · It’s not clear to me why GHC has a clone of parts of Hoopl. > Would it not be better just to make Hoopl faster? > > > > If anything I ‘d like to use Hoopl more in Cmm optimisation passes in GHC, > so we may want to use more of Hoopl’s facilities. > > > > The main reason you suggest for forking is that there are some awkward > name clashes. Surely we could resolve these? e.g we could change CLabel in > GHC; or agree with Hoopl maintainers that BlockId would be more helpful > than Label. > > > > You mention that Hoopl uses Unique set/map. Why not use ‘containers’ for > that? (Like GHC!) > > > > Let’s discuss this a bit more before executing > > > > I’m also interested to know: > > · who is actively working on Hoopl (Michael, Sophie, …)? > > · how are you using it (within GHC, or somewhere else)? > > > > It’d be good to review and update > https://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup. Are there any other > improvements planned? > > Simon > Hi Simon, Thanks for chiming in! Let me try to clarify the current situation and the motivation for my changes. 1) Initial fork of Hoopl Note that what I’m actually advocating is to *finish* forking Hoopl. The fork really started in ~2012 when the “new Cmm backend” was being finished. IIRC the main reason was the unacceptable performance and it seems that even Simon Marlow had trouble making it run fast enough: https://plus.google.com/107890464054636586545/posts/dBbewpRfw6R https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HooplPerformance The end result is pretty sad: GHC has its own forked/specialized `Hoopl.Dataflow` module and is using Hoopl only for definitions of `Block`/`Graph` and maps/sets (if you look at my commit, it’s pretty clear what I’m copying). In particular it’s not using *any* of dataflow analysis or rewriting capabilities of the Hoopl package. 2) Reasons to finish forking The reasons I listed in my previous email already assumed the we have the forked `Hoopl.Dataflow` module in GHC. But if we want to discuss what are reasons for forking in general, then apart from the performance (as noted above), there’s the issue of Hoopl’s interface. IMHO the node-oriented approach taken by Hoopl is both not flexible enough and it makes it harder to optimize it. That’s why I’ve already changed GHC’s `Hoopl.Dataflow` module to operate “block-at-a-time” (https://github.com/ghc/ghc/commit/679ccd1c8860f1ef4b589c9593b74d04c97ae836) Some concrete examples: - For proc-point analysis it was necessary to introduce a hack to GHC’s `Dataflow` module to expose a separate analysis function that *ignores* the middle nodes (since for proc-points they’re irrelevant). My change to go “block-at-a-time” allowed us to remove that hack. - I’m trying to fix non-linearity of `CmmLayoutStack` in (https://phabricator.haskell.org/D3586) and again the block-oriented interface is useful - I want to do different rewrites based on which block is being considered (whether it’s a proc-point or not). This is not easily possible if I don’t know which block I’m in (which is the case for the node-oriented interface). I also don’t think that name clashes and the tension between Hoopl’s interface and GHC are easy to solve. Hoopl is a public, stand-alone package, so we can’t just change things without considering compatibility. For instance, we can’t use GHC’s `Unique` in Hoopl. But should we switch all of GHC to use Hoopl’s? Also having closely related concepts spread around GHC and Hoopl is not helping when trying to understand what’s happening. Finally, any changes to both GHC & Hoopl have much higher overhead than just changing GHC. In general, it really seems to me that Hoopl has been released simply too early, with not enough real-world usage and testing. When you say that we should “just fix Hoopl”, it sounds to me that we’d really need to rewrite it from scratch. And it’s much easier to do that if we can just experiment within GHC without worrying about breaking other existing Hoopl users. Only once we’re happy with the result, we should be considering separating it into a stand-alone package. 3) Difference between pretty/containers and Hoopl I also think that the situation with pretty/containers is quite different than Hoopl. They are much more general-purpose libraries, *far* more widely used and with more contributors. Take containers - the package is still very actively developed and constantly improved. Whereas Hoopl hasn’t really seen much activity in the last 5 years. So the benefit-cost ratio is much better - yes there is some cost in having containers as a dependency, but the benefits from the regular stream of improvements easily outweigh it. I don’t think that’s the case for Hoopl. Does this help understand my motivation? Let me know if anything is still unclear! Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon May 29 15:08:10 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 May 2017 11:08:10 -0400 Subject: Finding out if a binding is externally visible In-Reply-To: References: <1496003627.12459.0.camel@joachim-breitner.de> Message-ID: <1496070490.16326.1.camel@joachim-breitner.de> Hi, Am Montag, den 29.05.2017, 10:40 +0200 schrieb Sebastian Graf: > Note that at the bottom, > there are RULEs stating the specialization for `Show Integer`, but > that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show > (Ratio Integer)` isn't otherwise reachable from any exported top- > level identifier. Same goes for any of the specialized dictionary > methods. At least the Occurrence Analyzer keeps things referenced from RULES alive:     initial_uds = addManyOccsSet emptyDetails                             (rulesFreeVars imp_rules `unionVarSet`                              vectsFreeVars vects `unionVarSet`                              vectVars)     -- The RULES and VECTORISE declarations keep things alive! So maybe the isExportedId is not the full truths that we are looking for here… which would mean that CallArity might be buggy in that respect. This does not contradict Note [ExportFlag on binders] – these IDs do not need to be marked Exported, as they are kept alive by the RULE. Would we drop, for whatever reason, the RULE, we would drop the id. > In my case, my custom GHC would substitute away the `showString " % > "` for an `absentError "lvl [Char]"` and crash in subtle ways. The > only reason this isn't happening for GHC master is that DmdAnal does > consider all top-level arguments to be used, instead of only the > exported ones (which is what CallArity does). It seems that CallArity is wrong here, and DmdAnal is right. The way out is probably to have CallArity take RULES properly into account. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sgraf1337 at gmail.com Mon May 29 15:28:39 2017 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 29 May 2017 17:28:39 +0200 Subject: Finding out if a binding is externally visible In-Reply-To: <1496070490.16326.1.camel@joachim-breitner.de> References: <1496003627.12459.0.camel@joachim-breitner.de> <1496070490.16326.1.camel@joachim-breitner.de> Message-ID: > > Occurrence Analyzer Ahh, good thinking. Do Unfoldings qualify in the same way? Currently, workers all get usage C^w(C^1(...(U))) instead of U in the combined analysis, because they are also not regarded 'externally visible'. There are a lot more one-shot lambdas as a consequence, some of which might not be intuitive: As I understand, the simplifier may inline and share an eta-reduced version of an unfolding from another module at any point. This will not produce incorrect code, but it's a decision that should be made consciously and documented appropriately. So, what binders do I have to consider as 'roots' apart from exports, RULEs, VECTORISE and possibly Unfoldings? That should be pretty much everything relevant, if the occurence analyser gets away with it, right? On Mon, May 29, 2017 at 5:08 PM, Joachim Breitner wrote: > Hi, > > Am Montag, den 29.05.2017, 10:40 +0200 schrieb Sebastian Graf: > > Note that at the bottom, > > there are RULEs stating the specialization for `Show Integer`, but > > that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show > > (Ratio Integer)` isn't otherwise reachable from any exported top- > > level identifier. Same goes for any of the specialized dictionary > > methods. > > At least the Occurrence Analyzer keeps things referenced from RULES > alive: > > initial_uds = addManyOccsSet emptyDetails > (rulesFreeVars imp_rules `unionVarSet` > vectsFreeVars vects `unionVarSet` > vectVars) > -- The RULES and VECTORISE declarations keep things alive! > > So maybe the isExportedId is not the full truths that we are looking > for here… which would mean that CallArity might be buggy in that > respect. > > This does not contradict Note [ExportFlag on binders] – these IDs do > not need to be marked Exported, as they are kept alive by the RULE. > Would we drop, for whatever reason, the RULE, we would drop the id. > > > In my case, my custom GHC would substitute away the `showString " % > > "` for an `absentError "lvl [Char]"` and crash in subtle ways. The > > only reason this isn't happening for GHC master is that DmdAnal does > > consider all top-level arguments to be used, instead of only the > > exported ones (which is what CallArity does). > > It seems that CallArity is wrong here, and DmdAnal is right. The way > out is probably to have CallArity take RULES properly into account. > > Greetings, > Joachim > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon May 29 17:33:08 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 May 2017 13:33:08 -0400 Subject: Finding out if a binding is externally visible In-Reply-To: References: <1496003627.12459.0.camel@joachim-breitner.de> <1496070490.16326.1.camel@joachim-breitner.de> Message-ID: <1496079188.16326.4.camel@joachim-breitner.de> Hi, Am Montag, den 29.05.2017, 17:28 +0200 schrieb Sebastian Graf: > > Occurrence Analyzer > Ahh, good thinking.  > > Do Unfoldings qualify in the same way? Unfoldings are kept alive together with the thing they unfold (so that you can remove an unfolding together with its Id should that get unused). And for most analyses, it makes sense to consider them an alternative RHS, so if you have f [Unfolding = \x -> bar x] f = \x -> foo x then that is a bit like f x = case coinToss of True -> bar x False -> foo x > So, what binders do I have to consider as 'roots' apart from exports, > RULEs, VECTORISE and possibly Unfoldings? That should be pretty much > everything relevant, if the occurence analyser gets away with it, > right? If the occurence analyser gets away with it, then so do you :-) But Unfoldings are not roots; they are referenced by the ID they unfold. (I wonder if the same can be said for non-orphan RULES, but maybe that is just too much a corner case.) Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From alberto at toscat.net Tue May 30 10:16:07 2017 From: alberto at toscat.net (Alberto Valverde) Date: Tue, 30 May 2017 12:16:07 +0200 Subject: Cross-compiling Template Haskell via -fexternal-interpreter and IPC In-Reply-To: References: <87furmit8n.fsf@smart-cactus.org> <87vaynpojc.fsf@smart-cactus.org> Message-ID: Hi Moritz, Sounds like it should be pretty straightforward to run GHCSlave on wine, so it might just work indeed. I'll build a nix environment for my app using your GHC branch and report back ASAP. However, what might block me won't be related to the cross-compilation per-se but to the migration to post 8.2.1 ghc since I'm still slowly making progress with all the dependencies but not there yet. Cheers, Alberto On Sat, May 27, 2017 at 10:51 AM, Moritz Angermann wrote: > Hi Alberto, > > let me know if I can be of help. As you likely saw I’ve been writing this > all up on https://medium.com/@zw3rk. With the outstanding diffs[1], this > should hopefully just work. As I haven’t used windows or know the linker > on windows, I’m not perfectly sure about the implications. It could *just > work* though. Maybe you can even use the GHCSlave’s Slave.hs[2] for the > Raspberry Pi for windows, as it doesn’t encode any Raspberry Pi specifics. > > All you would need is to run GHCSlave on wine / or a windows system with > some form of network interface, so that the iserv-proxy and GHCSlave can > communicate. > > Cheers, > Moritz > > [1]: you can just use the my-ghc branch from https://github.com/zw3rk/ghc > [2]: https://github.com/zw3rk/ghc-slave/blob/master/RPi/Slave.hs > > > On May 27, 2017, at 4:29 PM, Alberto Valverde > wrote: > > > > Hi Ben, > > > > I've just found this email from almost a year ago. Sorry for ignoring it > until now. Given the date it was sent I think I missed it when it was fresh > while I was on vacation. > > > > Regarding the question, I have abandoned the work I was doing on getting > cross-compilation for Windows to work since my employer decided a Windows > build for the app we were developing could wait some time and tasked me we > something else. > > > > However, I see that Moritz is working on cross-compilation right now so > I'll try get some time to see if I can get his approach to work for our > use-case and give some feedback or help in any way. > > > > Alberto > > > > On Fri, Aug 26, 2016 at 4:56 PM, Ben Gamari wrote: > > Alberto Valverde writes: > > > > > On Thu, Jul 7, 2016 at 9:30 AM, Simon Marlow > wrote: > > > > > >> I agree, named pipes are probably a better plan, perhaps a better > solution > > >> overall than the way we currently pass FD numbers on the command > line. Do > > >> named pipes work work as expected through wine? We would have to be > > >> careful to clean them up again afterwards. > > >> > > > > > > I've implemented IPC with named pipes and it appeared to work through > wine > > > but now I'm investigating an issue which causes GHC to "freeze" when > > > talking to the external interpreter when it is not running on a TTY > (ie: in > > > a build process) > > > > Hi Alterto, > > > > What ever happened to this? Is there any way I can be of assistance? It > > would be great to get this merged. > > > > Cheers, > > > > - Ben > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue May 30 18:43:17 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 30 May 2017 14:43:17 -0400 Subject: Haskell Implementors' Workshop Call for Talks Message-ID: <89244F5C-058B-426D-84A4-4A4D62C2E880@cs.brynmawr.edu> Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://icfp17.sigplan.org/track/hiw-2017 Oxford, UK, 9 September, 2017 Co-located with ICFP 2017 http://www.icfpconference.org/icfp2017/ Important dates --------------- Proposal Deadline: Thursday, 6 July, 2017 Notification: Thursday, 20 July, 2017 Workshop: Saturday, 9 September, 2017 The 9th Haskell Implementors' Workshop is to be held alongside ICFP 2017 this year in Oxford. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2017. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw17.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Richard A. Eisenberg -- chair (Bryn Mawr College) * Adam Gundry (Well-Typed) * Bartosz Nitka (Facebook) * Wren Romano (X, formerly Google[x]) * Alejandro Serrano Mena (Utrecht University) * Jan Stolarek (University of Edinburgh) Contact ------- * Richard A. Eisenberg From david at well-typed.com Tue May 30 21:05:41 2017 From: david at well-typed.com (David Feuer) Date: Tue, 30 May 2017 17:05:41 -0400 Subject: Trees that Grow in the hsSyn AST In-Reply-To: References: <38e18954-f13a-4a6c-8a81-8f76750cd40a@BL2NAM06FT006.Eop-nam06.prod.protection.outlook.com> Message-ID: <1955891.vsXtF6osvv@squirrel> On Friday, May 26, 2017 9:03:15 AM EDT Simon Peyton Jones wrote: > 1. Which is better to start with: HsSyn or Core? Intuition suggests this sort of thing could be very helpful for making zapping more reliable and ensuring its efficiency, but there may be better reasons to start with HsSyn. > > Definitely HsSyn. It’s big, riddled with extra info, and has many purposes for different people. Core is small, tight, nailed down. I don’t want to mess with it. Don't get me wrong. I wasn't suggesting that Core should come first; I have absolutely no basis to make any suggestion in that regard. I was just wondering what led to the decision to start with HsSyn. Are you suggesting that Core wouldn't benefit from these ideas? I surely don't see why not. Information about arity and strictness, at least, is introduced in specific compiler phases. I believe that some information needed for join points is only valid/available between certain phases. Making such things explicit in the types seems like it can only help. > 2. If we're making intrusive changes to representations, would now be a sensible era to consider switching to a different variable representation (unbound, bound, abt, etc)? > > I don’t think so. The issues are quite orthogonal, and no one (to my knowledge) has proposed any vaguely plausible change to variable bindings that would scale to what GHC does. In contrast, this stuff is “just” re-engineering. All right; I figured it wouldn't hurt to ask. May I ask what sorts of scaling problems you mean? David From ryan.gl.scott at gmail.com Wed May 31 21:21:07 2017 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 31 May 2017 14:21:07 -0700 Subject: Hunting down a compilation performance regression involving type families Message-ID: Richard, In an effort to figure out why programs with lots of type families have become so much slower over the last few GHC releases, I've been looking at GHC Trac #12545 [1], which provides a very self-contained test case that became considerably slower to compile from GHC 7.10 to 8.0. Thanks to this test case, I found one of the sources of the slowdown: a single, very small commit of yours [2]. What's baffling, though, is that I can't figure out why that commit makes compilation so much slower. I tried making profiled builds of GHC before and after that commit and attaching SCCs to the new code, but to my surprise, their contribution to the overall compilation time was negligible. So I'm out of ideas on what might be causing this. The only hint I have is the output of -ddump-simpl-stats/-dshow-passes. Before that commit, there's a point where the terms, types, and coercions go up: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 20,769, types: 1,157,897, coercions: 3,635,961} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 44,081, types: 2,451,155, coercions: 9,802,016} But after that commit, the terms and types jump up considerably higher! *** Simplifier: Result size of Simplifier = {terms: 16,429, types: 864,761, coercions: 2,184,448} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} Here are the relevant bits from -ddump-simpl-stats. Before that commit: 150 PreInlineUnconditionally 40 PostInlineUnconditionally 220 UnfoldingDone 110 RuleFired 380 BetaReduction After that commit: 306 PreInlineUnconditionally 160 PostInlineUnconditionally 360 UnfoldingDone 308 RuleFired 1238 BetaReduction Does you know what might be going on here? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12545 [2] https://ghc.haskell.org/trac/ghc/changeset/1722fa106e10e63160bb2322e2ccb830fd5b9ab3/ghc -------------- next part -------------- An HTML attachment was scrubbed... URL: