From peter.d.podlovics at gmail.com Fri Mar 2 12:04:54 2018 From: peter.d.podlovics at gmail.com (Peter Podlovics) Date: Fri, 2 Mar 2018 13:04:54 +0100 Subject: Fwd: Type checking expressions In-Reply-To: References: Message-ID: Hello everyone, I would like to ask for some advice regarding the type checker part of GHC. My goal is to determine the type of every expression, pattern etc. in the syntax tree. Currently the compiler doesn't store this information, so I have to type check manually. One important aspect is that the program may be ill-typed, but I still want to extract as much information as possible. I tried using local type checking functions (eg.: tcInferSigma), but whenever I used it on an expression that had some "out-of-scope" names in it, it failed. > f xs = length xs The reason was that xs was not in the local environment. My question is: how could I provide the necessary local environment for these type checking functions? Also in the general case, is it possible to somehow annotate each expression with its type during the type checking? The motivation for this is that I want to implement a tool that automatically corrects ill-typed programs based heuristics. For that I need to know the types of certain AST nodes. Peter Podlovics -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Mar 2 12:43:54 2018 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 2 Mar 2018 13:43:54 +0100 Subject: Guarded Impredicativity implementation In-Reply-To: References: Message-ID: Hi Artem, It's great to see some interest about our work :) At this moment there are no plans of making it part of GHC -- some details about the integration with other features need further thought. If you are really interested in trying, we built a prototype at https://git.science.uu.nl/f100183/ghc-invariant, which incorporates some advances in the "backward compatibility" section of the paper, but not guarded impredicativity per se. Regards, Alejandro 2018-02-26 23:36 GMT+01:00 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > Alejandro may want to comment… > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Artem > Pelenitsyn > *Sent:* 26 February 2018 17:05 > *To:* ghc-devs at haskell.org > *Subject:* Guarded Impredicativity implementation > > > > Dear ghc-devs, > > Is there any work has been done on the latest (ttbomk) proposal for > impredicative types in Haskell: > > > Guarded impredicative polymorphism by Alejandro Serrano, Jurriaan Hage, > Dimitrios Vytiniotis, Simon Peyton Jones > https://www.microsoft.com/en-us/research/wp-content/ > uploads/2017/07/impredicative-Jul17.pdf > > > Or are there any plans to do so? I wasn't able to spot any mentions of > this in either of GHC's forums (this list, Trac, wiki, ghc-proposals repo). > > -- > > Best wishes, > > Artem Pelenitsyn > > _______________________________________________ > 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 simon.jakobi at googlemail.com Sat Mar 3 18:57:54 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Sat, 3 Mar 2018 19:57:54 +0100 Subject: Someone please delete my Trac report Message-ID: Hi! Could someone with the appropriate permissions please delete report #26 "Interesting" at https://ghc.haskell.org/trac/ghc/report? When I saved my query I didn't expect that it would be visible to everyone. Cheers, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Mar 3 20:06:54 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 03 Mar 2018 15:06:54 -0500 Subject: Someone please delete my Trac report In-Reply-To: References: Message-ID: <87r2p0q5yj.fsf@smart-cactus.org> Simon Jakobi via ghc-devs writes: > Hi! > > Could someone with the appropriate permissions please delete report #26 > "Interesting" at https://ghc.haskell.org/trac/ghc/report? > Done! 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 simon.jakobi at googlemail.com Mon Mar 5 07:06:34 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Mon, 5 Mar 2018 08:06:34 +0100 Subject: End of Windows Vista support in GHC-8.6? Message-ID: Hi! Given that Vista’s EOL was in April 2017 i assume that there’s no intention to keep supporting it in GHC-8.6!? I’m asking because I intend to use a function that requires Windows 7 or newer for #13362 . Ending Vista support would also allow us to remove some workarounds mostly in RTS. Best, Simon ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 5 08:44:10 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 08:44:10 +0000 Subject: Type checking expressions In-Reply-To: References: Message-ID: Peter My goal is to determine the type of every expression, pattern etc. in the syntax tree After type checking is complete, the syntax tree is liberally annotated with types. We do not yet have a function hsExprType :: HsExpr Id -> Type but we do have TcHsTyn.hsPatType :: Pat GhcTc -> Type and you or someone could readily make an equivalent for HsExpr. Most type errors are reported by adding an error constraint, but still returning an annotated tree. Some, I’m afraid, are still done in the old way, by throwing an exception – so you don’t get back an annotated tree in that case. But they are relatively rare. Others must have wanted something like this… Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Peter Podlovics Sent: 02 March 2018 12:05 To: ghc-devs at haskell.org Subject: Fwd: Type checking expressions Hello everyone, I would like to ask for some advice regarding the type checker part of GHC. My goal is to determine the type of every expression, pattern etc. in the syntax tree. Currently the compiler doesn't store this information, so I have to type check manually. One important aspect is that the program may be ill-typed, but I still want to extract as much information as possible. I tried using local type checking functions (eg.: tcInferSigma), but whenever I used it on an expression that had some "out-of-scope" names in it, it failed. > f xs = length xs The reason was that xs was not in the local environment. My question is: how could I provide the necessary local environment for these type checking functions? Also in the general case, is it possible to somehow annotate each expression with its type during the type checking? The motivation for this is that I want to implement a tool that automatically corrects ill-typed programs based heuristics. For that I need to know the types of certain AST nodes. Peter Podlovics -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 5 08:50:26 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 08:50:26 +0000 Subject: Perf for T5837 Message-ID: Ben Why did you revert this? commit 2756117bd26c2cb70d3f51954a88b7d7bdf3d3f2 Author: Ben Gamari Date: Thu Mar 1 14:06:04 2018 -0500 Revert "Better stats for T5837" This reverts commit d675a354e8db67d87d1f257c3d1d2bf2d58c2b3f. - (wordsize(64), 55813608, 7)]) + (wordsize(64), 51294232, 7)]) It's consistently 8% better for me, but I guess not for you. Does anyone else find this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 5 09:25:27 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 09:25:27 +0000 Subject: tigetnum etc -- help! Message-ID: My stage-1 build (from clean) has started failing thus (on Linux). Any ideas? It's pretty disabling because I can't build GHC any more. Simon make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds "/usr/local/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/ghc-pkg/dist/build -hidir utils/ghc-pkg/dist/build -stubdir utils/ghc-pkg/dist/build -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 -no-user-package-db -rtsopts utils/ghc-pkg/dist/build/Main.o utils/ghc-pkg/dist/build/Version.o /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6De_info: error: undefined reference to 'tigetnum' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6Df_info: error: undefined reference to 'tigetflag' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6Dg_info: error: undefined reference to 'tigetstr' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Gn_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Gb_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6I7_info: error: undefined reference to 'tparm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6JP_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6JA_info: error: undefined reference to 'setupterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Jn_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6KR_info: error: undefined reference to 'tputs' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o)(.data+0xdc8): error: undefined reference to 'del_curterm' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/ghc-pkg/ghc.mk:70: recipe for target 'utils/ghc-pkg/dist/build/tmp/ghc-pkg' failed make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj at cam-05-unx:~/5builds/HEAD-1$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Mar 5 09:34:58 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Mar 2018 04:34:58 -0500 Subject: tigetnum etc -- help! In-Reply-To: References: Message-ID: Do you have configure / build log output for the terminfo package? On Mon, Mar 5, 2018 at 4:25 AM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > My stage-1 build (from clean) has started failing thus (on Linux). Any > ideas? It’s pretty disabling because I can’t build GHC any more. > > Simon > > > > make > > ===--- building phase 0 > > make --no-print-directory -f ghc.mk phase=0 phase_0_builds > > make[1]: Nothing to be done for 'phase_0_builds'. > > ===--- building phase 1 > > make --no-print-directory -f ghc.mk phase=1 phase_1_builds > > "/usr/local/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi > -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db > libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. > -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build > -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen > -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h > -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id > binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id > containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id > filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 > -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 > -no-user-package-db -rtsopts -odir utils/ghc-pkg/dist/build -hidir > utils/ghc-pkg/dist/build -stubdir utils/ghc-pkg/dist/build -static -O0 > -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages > -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build > -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen > -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h > -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id > binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id > containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id > filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 > -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 > -no-user-package-db -rtsopts utils/ghc-pkg/dist/build/Main.o > utils/ghc-pkg/dist/build/Version.o > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):r6De_info: error: undefined > reference to 'tigetnum' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):r6Df_info: error: undefined > reference to 'tigetflag' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):r6Dg_info: error: undefined > reference to 'tigetstr' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6Gn_info: error: undefined > reference to 'set_curterm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6Gb_info: error: undefined > reference to 'set_curterm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6I7_info: error: undefined > reference to 'tparm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6JP_info: error: undefined > reference to 'set_curterm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6JA_info: error: undefined > reference to 'setupterm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6Jn_info: error: undefined > reference to 'set_curterm' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o):s6KR_info: error: undefined > reference to 'tputs' > > /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/ > build/libHSterminfo-0.4.1.1.a(Base.o)(.data+0xdc8): error: undefined > reference to 'del_curterm' > > collect2: error: ld returned 1 exit status > > `gcc' failed in phase `Linker'. (Exit code: 1) > > utils/ghc-pkg/ghc.mk:70: recipe for target 'utils/ghc-pkg/dist/build/tmp/ghc-pkg' > failed > > make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1 > > Makefile:122: recipe for target 'all' failed > > make: *** [all] Error 2 > > simonpj at cam-05-unx:~/5builds/HEAD-1$ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 5 09:53:00 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 09:53:00 +0000 Subject: tigetnum etc -- help! In-Reply-To: References: Message-ID: Thanks libraries/terminfo/config.log is attached. Does not look informative. Simon From: Brandon Allbery [mailto:allbery.b at gmail.com] Sent: 05 March 2018 09:35 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: tigetnum etc -- help! Do you have configure / build log output for the terminfo package? On Mon, Mar 5, 2018 at 4:25 AM, Simon Peyton Jones via ghc-devs > wrote: My stage-1 build (from clean) has started failing thus (on Linux). Any ideas? It’s pretty disabling because I can’t build GHC any more. Simon make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds "/usr/local/bin/ghc" -o utils/ghc-pkg/dist/build/tmp/ghc-pkg -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/ghc-pkg/dist/build -hidir utils/ghc-pkg/dist/build -stubdir utils/ghc-pkg/dist/build -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/ghc-pkg/. -iutils/ghc-pkg/dist/build -Iutils/ghc-pkg/dist/build -iutils/ghc-pkg/dist/build/ghc-pkg/autogen -Iutils/ghc-pkg/dist/build/ghc-pkg/autogen -optP-DWITH_TERMINFO -optP-include -optPutils/ghc-pkg/dist/build/ghc-pkg/autogen/cabal_macros.h -package-id Cabal-2.1.0.0 -package-id base-4.10.0.0 -package-id binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id process-1.6.1.0 -package-id terminfo-0.4.1.1 -package-id unix-2.7.2.2 -XHaskell2010 -no-user-package-db -rtsopts utils/ghc-pkg/dist/build/Main.o utils/ghc-pkg/dist/build/Version.o /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6De_info: error: undefined reference to 'tigetnum' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6Df_info: error: undefined reference to 'tigetflag' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):r6Dg_info: error: undefined reference to 'tigetstr' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Gn_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Gb_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6I7_info: error: undefined reference to 'tparm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6JP_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6JA_info: error: undefined reference to 'setupterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6Jn_info: error: undefined reference to 'set_curterm' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o):s6KR_info: error: undefined reference to 'tputs' /5playpen/simonpj/HEAD-1/libraries/terminfo/dist-boot/build/libHSterminfo-0.4.1.1.a(Base.o)(.data+0xdc8): error: undefined reference to 'del_curterm' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/ghc-pkg/ghc.mk:70: recipe for target 'utils/ghc-pkg/dist/build/tmp/ghc-pkg' failed make[1]: *** [utils/ghc-pkg/dist/build/tmp/ghc-pkg] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 simonpj at cam-05-unx:~/5builds/HEAD-1$ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log Type: application/octet-stream Size: 9772 bytes Desc: config.log URL: From simonpj at microsoft.com Mon Mar 5 10:57:11 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 10:57:11 +0000 Subject: tigetnum etc -- help! In-Reply-To: References: Message-ID: | just to check the obvious, have you made sure to `git submodule | update` everything? have you properly cleaned your build-tree? Thanks. I did clean; and I usually obsessively do git submodule update, but I may have forgotten this time. I think for cabal and hsc2hs. Trying again now... Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 05 March 2018 10:55 | To: Simon Peyton Jones | Subject: Re: tigetnum etc -- help! | | Hi Simon, | | just to check the obvious, have you made sure to `git submodule | update` everything? have you properly cleaned your build-tree? | | -- hvr From simonpj at microsoft.com Mon Mar 5 11:42:58 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 11:42:58 +0000 Subject: tigetnum etc -- help! In-Reply-To: References: Message-ID: I think that was it (submodule update). It's building away now. Sorry for the noise, everyone. Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 05 March 2018 10:57 | To: 'Herbert Valerio Riedel' | Cc: ghc-devs at haskell.org | Subject: RE: tigetnum etc -- help! | | | just to check the obvious, have you made sure to `git submodule | | update` everything? have you properly cleaned your build-tree? | | Thanks. | | I did clean; and I usually obsessively do git submodule update, but I | may have forgotten this time. I think for cabal and hsc2hs. | | Trying again now... | | Simon | | | -----Original Message----- | | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | | Sent: 05 March 2018 10:55 | | To: Simon Peyton Jones | | Subject: Re: tigetnum etc -- help! | | | | Hi Simon, | | | | just to check the obvious, have you made sure to `git submodule | | update` everything? have you properly cleaned your build-tree? | | | | -- hvr From simonpj at microsoft.com Mon Mar 5 12:03:49 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 12:03:49 +0000 Subject: ghcpkg05 Message-ID: ghcpkg05 is failing on my Linux box. Any ideas? This is a clean build. Simon =====> ghcpkg05(normal) 1 of 1 [0, 0, 0] cd "./ghcpkg05.run" && $MAKE -s --no-print-directory ghcpkg05 Actual stderr output differs from expected: diff -uw "./ghcpkg05.run/ghcpkg05.stderr.normalised" "./ghcpkg05.run/ghcpkg05.run.stderr.normalised" --- ./ghcpkg05.run/ghcpkg05.stderr.normalised 2018-03-05 12:02:14.828489599 +0000 +++ ./ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-03-05 12:02:14.828489599 +0000 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX-ghc.so","libtestpkg-2.0-XXX-ghc.dylib","testpkg-2.0-XXX-ghc.dll"] on library path +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/text/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/containers/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) Unexpected results from: TEST="ghcpkg05" SUMMARY for test run started at Mon Mar 5 12:02:14 2018 GMT 0:00:01 spent to go through 1 total tests, which gave rise to 1 test cases, of which 0 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: ghcpkg05.run ghcpkg05 [bad stderr] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From niteria at gmail.com Mon Mar 5 14:40:29 2018 From: niteria at gmail.com (Bartosz Nitka) Date: Mon, 5 Mar 2018 14:40:29 +0000 Subject: Perf for T5837 In-Reply-To: References: Message-ID: I commented on https://phabricator.haskell.org/rGHCd675a354e8db67d87d1f257c3d1d2bf2d58c2b3f that Harbormaster started failing after this. It reproduced locally for me. You can see here: https://phabricator.haskell.org/diffusion/GHC/history/master/ that the revert fixed the build. 2018-03-05 8:50 GMT+00:00 Simon Peyton Jones via ghc-devs : > Ben > > Why did you revert this? > > commit 2756117bd26c2cb70d3f51954a88b7d7bdf3d3f2 > > Author: Ben Gamari > > Date: Thu Mar 1 14:06:04 2018 -0500 > > > > Revert "Better stats for T5837" > > > > This reverts commit d675a354e8db67d87d1f257c3d1d2bf2d58c2b3f. > > > > - (wordsize(64), 55813608, 7)]) > > + (wordsize(64), 51294232, 7)]) > > > > It’s consistently 8% better for me, but I guess not for you. > > Does anyone else find this? > > Simon > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Mar 5 16:11:46 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Mar 2018 16:11:46 +0000 Subject: Type checking expressions In-Reply-To: References: Message-ID: Always cc ghc-devs! Bottle-necking on me may well yield a slow response! Or even Haskell-café. What is the type of (\x -> [x,y])? Where y is in scope with type y::a. Presumably something like a -> [a]? Or is it forall a. a -> [a]? And would your answer change if you had just (\x -> [x,x])? Generalisation is tricky, and for terms with non-closed types it is hard to know what you need in your use-case. A type like ‘a’ might be a very fine answer! A lot depends on precisely what you are trying to do. Simon From: Peter Podlovics [mailto:peter.d.podlovics at gmail.com] Sent: 05 March 2018 14:54 To: Simon Peyton Jones Subject: Re: Type checking expressions My main concern with that approach is that it might not give the correct type. For example the hsPatType function only gives unconstrained types, so it is incorrect for any numeric literal, since it gives "a" instead of "Num a => a". So the question is whether it is possible to retrieve the context of the type variables as well. Also this problem may arise in the case of expressions as well, that is why I scrapped that approach and tried to type check the AST with the TcM monad directly, but without any success. Could you give me any leads on how to solve this problem? Thanks in advance, Peter On Mon, Mar 5, 2018 at 9:44 AM, Simon Peyton Jones > wrote: Peter My goal is to determine the type of every expression, pattern etc. in the syntax tree After type checking is complete, the syntax tree is liberally annotated with types. We do not yet have a function hsExprType :: HsExpr Id -> Type but we do have TcHsTyn.hsPatType :: Pat GhcTc -> Type and you or someone could readily make an equivalent for HsExpr. Most type errors are reported by adding an error constraint, but still returning an annotated tree. Some, I’m afraid, are still done in the old way, by throwing an exception – so you don’t get back an annotated tree in that case. But they are relatively rare. Others must have wanted something like this… Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Peter Podlovics Sent: 02 March 2018 12:05 To: ghc-devs at haskell.org Subject: Fwd: Type checking expressions Hello everyone, I would like to ask for some advice regarding the type checker part of GHC. My goal is to determine the type of every expression, pattern etc. in the syntax tree. Currently the compiler doesn't store this information, so I have to type check manually. One important aspect is that the program may be ill-typed, but I still want to extract as much information as possible. I tried using local type checking functions (eg.: tcInferSigma), but whenever I used it on an expression that had some "out-of-scope" names in it, it failed. > f xs = length xs The reason was that xs was not in the local environment. My question is: how could I provide the necessary local environment for these type checking functions? Also in the general case, is it possible to somehow annotate each expression with its type during the type checking? The motivation for this is that I want to implement a tool that automatically corrects ill-typed programs based heuristics. For that I need to know the types of certain AST nodes. Peter Podlovics -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Mon Mar 5 16:25:54 2018 From: palotai.robin at gmail.com (Robin Palotai) Date: Mon, 5 Mar 2018 17:25:54 +0100 Subject: Type checking expressions In-Reply-To: References: Message-ID: I wondered if https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/defer-type-errors.html could help. I tried to click around in the GHC 8.2 tree of http://stuff.codereview.me/ghc/#ghc/compiler/typecheck/TcErrors.hs?corpus=ghc-8.2.1-rc2&signature&line=120, but it seems deferring type errors just reports via a different means, and doesn't change the type-checking behavior. But correct me if I'm wrong. 2018-03-05 17:11 GMT+01:00 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org>: > Always cc ghc-devs! Bottle-necking on me may well yield a slow > response! Or even Haskell-café. > > > > What is the type of (\x -> [x,y])? Where y is in scope with type y::a. > Presumably something like a -> [a]? Or is it forall a. a -> [a]? And > would your answer change if you had just (\x -> [x,x])? > > > > Generalisation is tricky, and for terms with non-closed types it is hard > to know what you need in your use-case. A type like ‘a’ might be a very > fine answer! > > > > A lot depends on precisely what you are trying to do. > > > > Simon > > > > *From:* Peter Podlovics [mailto:peter.d.podlovics at gmail.com] > *Sent:* 05 March 2018 14:54 > *To:* Simon Peyton Jones > *Subject:* Re: Type checking expressions > > > > My main concern with that approach is that it might not give the correct > type. For example the hsPatType function only gives unconstrained types, so > it is incorrect for any numeric literal, since it gives "a" instead of "Num > a => a". > > So the question is whether it is possible to retrieve the context of the > type variables as well. Also this problem may arise in the case of > expressions as well, that is why I scrapped that approach and tried to type > check the AST with the TcM monad directly, but without any success. > > Could you give me any leads on how to solve this problem? > > Thanks in advance, > > Peter > > > > On Mon, Mar 5, 2018 at 9:44 AM, Simon Peyton Jones > wrote: > > Peter > > > > My goal is to determine the type of every expression, pattern etc. in the > syntax tree > > > > After type checking is complete, the syntax tree is liberally annotated > with types. > > > > We do not yet have a function > > hsExprType :: HsExpr Id -> Type > > but we do have > > TcHsTyn.hsPatType :: Pat GhcTc -> Type > > and you or someone could readily make an equivalent for HsExpr. > > > > Most type errors are reported by adding an error constraint, but still > returning an annotated tree. > > Some, I’m afraid, are still done in the old way, by throwing an exception > – so you don’t get back an annotated tree in that case. But they are > relatively rare. > > > > Others must have wanted something like this… > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Peter > Podlovics > *Sent:* 02 March 2018 12:05 > *To:* ghc-devs at haskell.org > *Subject:* Fwd: Type checking expressions > > > > Hello everyone, > > I would like to ask for some advice regarding the type checker part of GHC. > My goal is to determine the type of every expression, pattern etc. in the > syntax tree. Currently the compiler doesn't store this information, so I > have > to type check manually. One important aspect is that the program may be > ill-typed, > but I still want to extract as much information as possible. > > I tried using local type checking functions (eg.: tcInferSigma), but > whenever > I used it on an expression that had some "out-of-scope" names in it, it > failed. > > > f xs = length xs > > The reason was that xs was not in the local environment. > > My question is: how could I provide the necessary local environment for > these > type checking functions? Also in the general case, is it possible to > somehow > annotate each expression with its type during the type checking? > > The motivation for this is that I want to implement a tool that > automatically > corrects ill-typed programs based heuristics. For that I need to know the > types > of certain AST nodes. > > Peter Podlovics > > > > > > _______________________________________________ > 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 Mon Mar 5 17:18:24 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Mar 2018 12:18:24 -0500 Subject: Perf for T5837 In-Reply-To: References: Message-ID: <87muzm4f1d.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > Ben > Why did you revert this? > As Bartosz mentioned, Harbormaster didn't reproduce the change. I've also not seen it locally. Admittedly, it possible that it does change on Harbormaster, just by a much different amount than what you observed. 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 peter.d.podlovics at gmail.com Mon Mar 5 17:21:22 2018 From: peter.d.podlovics at gmail.com (Peter Podlovics) Date: Mon, 5 Mar 2018 18:21:22 +0100 Subject: Type checking expressions In-Reply-To: References: Message-ID: Simon: I would like to keep the constraints as much as possible. So if x :: C a => a then [x] :: C a => [a]. Also in the case of patterns if I have f 5 = 5, then the pattern 5 should have type Num a => a, but currently the type is stored without the Num context (using hsPatType). I don't to imitate the complete type checking process, but is there a way to retrieve these context information as well? Robin: The current solution uses the feature you mentioned. This is needed in order to extract the incompletely typed AST from the compiler. The tool then would perform some transformations on the syntax tree to correct the type errors, but for that it must be able to type subexpressions as well. The -fdefer-type-errors flag doesn't help to solve this problem, it only enables us to extract the AST. Any advice on typing expressions using API functions and retrieving context information would help a great deal. On Mon, Mar 5, 2018 at 5:25 PM, Robin Palotai wrote: > I wondered if https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_ > guide/defer-type-errors.html could help. > > I tried to click around in the GHC 8.2 tree of http://stuff.codereview.me/ > ghc/#ghc/compiler/typecheck/TcErrors.hs?corpus=ghc-8.2.1- > rc2&signature&line=120, but it seems deferring type errors just reports > via a different means, and doesn't change the type-checking behavior. But > correct me if I'm wrong. > > 2018-03-05 17:11 GMT+01:00 Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org>: > >> Always cc ghc-devs! Bottle-necking on me may well yield a slow >> response! Or even Haskell-café. >> >> >> >> What is the type of (\x -> [x,y])? Where y is in scope with type >> y::a. Presumably something like a -> [a]? Or is it forall a. a -> >> [a]? And would your answer change if you had just (\x -> [x,x])? >> >> >> >> Generalisation is tricky, and for terms with non-closed types it is hard >> to know what you need in your use-case. A type like ‘a’ might be a very >> fine answer! >> >> >> >> A lot depends on precisely what you are trying to do. >> >> >> >> Simon >> >> >> >> *From:* Peter Podlovics [mailto:peter.d.podlovics at gmail.com] >> *Sent:* 05 March 2018 14:54 >> *To:* Simon Peyton Jones >> *Subject:* Re: Type checking expressions >> >> >> >> My main concern with that approach is that it might not give the correct >> type. For example the hsPatType function only gives unconstrained types, so >> it is incorrect for any numeric literal, since it gives "a" instead of "Num >> a => a". >> >> So the question is whether it is possible to retrieve the context of the >> type variables as well. Also this problem may arise in the case of >> expressions as well, that is why I scrapped that approach and tried to type >> check the AST with the TcM monad directly, but without any success. >> >> Could you give me any leads on how to solve this problem? >> >> Thanks in advance, >> >> Peter >> >> >> >> On Mon, Mar 5, 2018 at 9:44 AM, Simon Peyton Jones >> wrote: >> >> Peter >> >> >> >> My goal is to determine the type of every expression, pattern etc. in the >> syntax tree >> >> >> >> After type checking is complete, the syntax tree is liberally annotated >> with types. >> >> >> >> We do not yet have a function >> >> hsExprType :: HsExpr Id -> Type >> >> but we do have >> >> TcHsTyn.hsPatType :: Pat GhcTc -> Type >> >> and you or someone could readily make an equivalent for HsExpr. >> >> >> >> Most type errors are reported by adding an error constraint, but still >> returning an annotated tree. >> >> Some, I’m afraid, are still done in the old way, by throwing an exception >> – so you don’t get back an annotated tree in that case. But they are >> relatively rare. >> >> >> >> Others must have wanted something like this… >> >> >> >> Simon >> >> >> >> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Peter >> Podlovics >> *Sent:* 02 March 2018 12:05 >> *To:* ghc-devs at haskell.org >> *Subject:* Fwd: Type checking expressions >> >> >> >> Hello everyone, >> >> I would like to ask for some advice regarding the type checker part of >> GHC. >> My goal is to determine the type of every expression, pattern etc. in the >> syntax tree. Currently the compiler doesn't store this information, so I >> have >> to type check manually. One important aspect is that the program may be >> ill-typed, >> but I still want to extract as much information as possible. >> >> I tried using local type checking functions (eg.: tcInferSigma), but >> whenever >> I used it on an expression that had some "out-of-scope" names in it, it >> failed. >> >> > f xs = length xs >> >> The reason was that xs was not in the local environment. >> >> My question is: how could I provide the necessary local environment for >> these >> type checking functions? Also in the general case, is it possible to >> somehow >> annotate each expression with its type during the type checking? >> >> The motivation for this is that I want to implement a tool that >> automatically >> corrects ill-typed programs based heuristics. For that I need to know the >> types >> of certain AST nodes. >> >> Peter Podlovics >> >> >> >> >> >> _______________________________________________ >> 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 Mon Mar 5 17:23:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Mar 2018 12:23:45 -0500 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: References: Message-ID: <87inaa4esg.fsf@smart-cactus.org> Simon Jakobi via ghc-devs writes: > Hi! > > Given that Vista’s EOL was in April 2017 > > i assume that there’s no intention to keep supporting it in GHC-8.6!? > > I’m asking because I intend to use a function > > that requires Windows 7 or newer for #13362 > . > Given that it's EOL'd, dropping Vista sounds reasonable to me. Tamar, any objection? 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 lonetiger at gmail.com Mon Mar 5 17:29:01 2018 From: lonetiger at gmail.com (Phyx) Date: Mon, 05 Mar 2018 17:29:01 +0000 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: <87inaa4esg.fsf@smart-cactus.org> References: <87inaa4esg.fsf@smart-cactus.org> Message-ID: On Mon, Mar 5, 2018, 17:23 Ben Gamari wrote: > Simon Jakobi via ghc-devs writes: > > > Hi! > > > > Given that Vista’s EOL was in April 2017 > > < > https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support > > > > i assume that there’s no intention to keep supporting it in GHC-8.6!? > > > > I’m asking because I intend to use a function > > > > that requires Windows 7 or newer for #13362 > > . > > > Given that it's EOL'd, dropping Vista sounds reasonable to me. > > Tamar, any objection? > No objections, however do make sure to test both 32 and 64 bit builds of ghc when you use the API, it's new enough and rare enough that it may not be implemented in both mingw-64 tool chains (we've had similar issues before). Thanks, Tamar > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Mon Mar 5 19:21:02 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Mon, 5 Mar 2018 20:21:02 +0100 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: References: <87inaa4esg.fsf@smart-cactus.org> Message-ID: Thanks everyone! I have updated https://ghc.haskell.org/trac/ghc/wiki/Platforms/Windows accordingly. Cheers, Simon 2018-03-05 18:29 GMT+01:00 Phyx : > > > On Mon, Mar 5, 2018, 17:23 Ben Gamari wrote: > >> Simon Jakobi via ghc-devs writes: >> >> > Hi! >> > >> > Given that Vista’s EOL was in April 2017 >> > > vista-end-of-support> >> > i assume that there’s no intention to keep supporting it in GHC-8.6!? >> > >> > I’m asking because I intend to use a function >> > > > >> > that requires Windows 7 or newer for #13362 >> > . >> > >> Given that it's EOL'd, dropping Vista sounds reasonable to me. >> >> Tamar, any objection? >> > > No objections, however do make sure to test both 32 and 64 bit builds of > ghc when you use the API, it's new enough and rare enough that it may not > be implemented in both mingw-64 tool chains (we've had similar issues > before). > > Thanks, > Tamar > > >> Cheers, >> >> - Ben >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Mon Mar 5 21:53:28 2018 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 5 Mar 2018 21:53:28 +0000 Subject: FFI-free NaN checks? (isDoubleNan and friends) Message-ID: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> Hi, Recently at a client I was profiling some code and isDoubleNaN lit up. We were checking a lot of doubles for NaN as that's what customer would send in. I went to investigate and I found that FFI is used to achieve this. I was always under the impression that FFI costs a little. I had at the time replaced the code with a hack with great results: ``` isNaN' :: Double -> Bool isNaN' d = d /= d ``` While this worked and provided good speedup in my case, this fails catastrophically if the program is compiled with -ffast-math. This is expected. I have since reverted it. Seeking an alternative solution I have thought about re-implementing the C code with a native Haskell version: after all it just checks a few bits. Apparently unsafeCoerce# and friends were a big no-no but I found https://phabricator.haskell.org/D3358 . I have implemented the code at the bottom of this post. Obviously it's missing endianness (compile-time switch). This seems to be faster for smaller `mkInput` list than Prelude.isNaN but slower slightly on the one below. The `/=` version is the fastest but very fragile. My question to you all is whether implementing a version of this function in Haskell makes sense and if not, why not? The stgDoubleToWord64 is implemented in CMM and I don't know anything about the costs of that. * Is there a cheaper alternative to FFI way? * If yes, does anyone know how to write it such that it compiles to same code but without the call overhead? I must have failed below as it's slower on some inputs. Basically if a faster way exists for isNaN, something I have to do a lot, I'd love to hear about it. I leave you with basic code I managed to come up with. 8.4.x only. ``` {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-} module Main (main) where import GHC.Float import GHC.Prim isNaN' :: Double -> Bool isNaN' d = d /= d isNaNBits :: Double -> Bool isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of 1# -> case bits `and#` mantissaMask of 0## -> False _ -> True _ -> False where bits :: Word# bits = stgDoubleToWord64 d expMask, mantissaMask :: Word# expMask = 0x7FF0000000000000## mantissaMask = 0x000FFFFFFFFFFFFF## main :: IO () main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) `seq` pure () where nan :: Double nan = log (-1) mkInput :: Int -> [Double] mkInput n = take n $ cycle [1, nan] sumFilter :: (Double -> Bool) -> [Double] -> Double sumFilter p = Prelude.sum . Prelude.filter (not . p) ``` -- Mateusz K. From allbery.b at gmail.com Mon Mar 5 22:23:12 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Mar 2018 17:23:12 -0500 Subject: FFI-free NaN checks? (isDoubleNan and friends) In-Reply-To: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> References: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> Message-ID: If the FFI version is done with "safe", consider using "unsafe" instead. There are technical reasons why this is slightly incorrect, but unless you're fiddling with the CPU's FP control flags they're mostly irrelevant and you can treat isNaN as pure and non-side-effectful, significantly reducing the overhead. You may also be able to use "ccall" to take advantage of C compiler level optimizations, or simply to directly invoke a CPU-based test with asm(); but you'll need to hide that in a C preprocessor #define, so that it looks syntactically like a function call to the FFI. (One of the technical reasons is that various OSes have been known to introduce bugs in their FP register and state handling across system calls, in which case the "safe" version may turn "complete FP chaos" into merely "wrong answer". It's your call whether, or which side, of this bothers you.) On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk wrote: > Hi, > > Recently at a client I was profiling some code and isDoubleNaN lit up. > We were checking a lot of doubles for NaN as that's what customer would > send in. > > I went to investigate and I found that FFI is used to achieve this. I > was always under the impression that FFI costs a little. I had at the > time replaced the code with a hack with great results: > > ``` > isNaN' :: Double -> Bool > isNaN' d = d /= d > ``` > > While this worked and provided good speedup in my case, this fails > catastrophically if the program is compiled with -ffast-math. This is > expected. I have since reverted it. Seeking an alternative solution I > have thought about re-implementing the C code with a native Haskell > version: after all it just checks a few bits. Apparently unsafeCoerce# > and friends were a big no-no but I found > https://phabricator.haskell.org/D3358 . I have implemented the code at > the bottom of this post. Obviously it's missing endianness (compile-time > switch). > > This seems to be faster for smaller `mkInput` list than Prelude.isNaN > but slower slightly on the one below. The `/=` version is the fastest > but very fragile. > > My question to you all is whether implementing a version of this > function in Haskell makes sense and if not, why not? The > stgDoubleToWord64 is implemented in CMM and I don't know anything about > the costs of that. > > * Is there a cheaper alternative to FFI way? > * If yes, does anyone know how to write it such that it compiles to same > code but without the call overhead? I must have failed below as it's > slower on some inputs. > > Basically if a faster way exists for isNaN, something I have to do a > lot, I'd love to hear about it. > > I leave you with basic code I managed to come up with. 8.4.x only. > > > ``` > {-# LANGUAGE MagicHash #-} > {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-} > module Main (main) where > > import GHC.Float > import GHC.Prim > > isNaN' :: Double -> Bool > isNaN' d = d /= d > > isNaNBits :: Double -> Bool > isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of > 1# -> case bits `and#` mantissaMask of > 0## -> False > _ -> True > _ -> False > where > bits :: Word# > bits = stgDoubleToWord64 d > > expMask, mantissaMask :: Word# > expMask = 0x7FF0000000000000## > mantissaMask = 0x000FFFFFFFFFFFFF## > > main :: IO () > main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) > `seq` pure () > where > nan :: Double > nan = log (-1) > > mkInput :: Int -> [Double] > mkInput n = take n $ cycle [1, nan] > > sumFilter :: (Double -> Bool) -> [Double] -> Double > sumFilter p = Prelude.sum . Prelude.filter (not . p) > ``` > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Tue Mar 6 07:42:39 2018 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 06 Mar 2018 16:42:39 +0900 (JST) Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <87po4trmr3.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: <20180306.164239.1921474263241137833.kazu@iij.ad.jp> Hello Ben, > As always, do let us know if you encounter any trouble in the course of > testing. Thanks for your help! I tried GHC 8.4.1rc1 to understand how SemigroupMonoid and MonadFail proposals work. GHC 8.4.1rc1 surely detects Monoid data types if they are not instances of Semigroup. However, GHC users guide still says that both -Wcompat and -Wsemigroup are disabled by default. Should we update the document or am I missing something? GHC 8.4.1rc does not find Monad data types which define "fail" even with -Wcompat. Now I understand that -Wnoncanonical-monadfail-instances is necessary. Why doesn't -Wcampat include -Wnoncanonical-monadfail-instances? Anyway, I hope that the proposals will be updated with the concurete warning flag names so that I can understand them easily. --Kazu From fuuzetsu at fuuzetsu.co.uk Tue Mar 6 10:35:38 2018 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 6 Mar 2018 10:35:38 +0000 Subject: FFI-free NaN checks? (isDoubleNan and friends) In-Reply-To: References: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> Message-ID: <201e2f18-3ddf-7fe8-3968-5bea950ae03c@fuuzetsu.co.uk> On 03/05/2018 10:23 PM, Brandon Allbery wrote: > If the FFI version is done with "safe", consider using "unsafe" instead. > There are technical reasons why this is slightly incorrect, but unless > you're fiddling with the CPU's FP control flags they're mostly irrelevant > and you can treat isNaN as pure and non-side-effectful, significantly > reducing the overhead. You may also be able to use "ccall" to take > advantage of C compiler level optimizations, or simply to directly invoke a > CPU-based test with asm(); but you'll need to hide that in a C preprocessor > #define, so that it looks syntactically like a function call to the FFI. > > (One of the technical reasons is that various OSes have been known to > introduce bugs in their FP register and state handling across system calls, > in which case the "safe" version may turn "complete FP chaos" into merely > "wrong answer". It's your call whether, or which side, of this bothers you.) Perhaps I was a little unclear. The FFI-using isDoubleNaN is something GHC does! ``` libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN" isDoubleNaN :: Double -> Int ``` ``` HsInt isDoubleNaN(HsDouble d) { union stg_ieee754_dbl u; u.d = d; return ( u.ieee.exponent == 2047 /* 2^11 - 1 */ && /* Is the exponent all ones? */ (u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0) /* and the mantissa non-zero? */ ); } ``` My question is whether it could do better by not doing FFI and instead computing natively and if not, why not? > On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk > wrote: > >> Hi, >> >> Recently at a client I was profiling some code and isDoubleNaN lit up. >> We were checking a lot of doubles for NaN as that's what customer would >> send in. >> >> I went to investigate and I found that FFI is used to achieve this. I >> was always under the impression that FFI costs a little. I had at the >> time replaced the code with a hack with great results: >> >> ``` >> isNaN' :: Double -> Bool >> isNaN' d = d /= d >> ``` >> >> While this worked and provided good speedup in my case, this fails >> catastrophically if the program is compiled with -ffast-math. This is >> expected. I have since reverted it. Seeking an alternative solution I >> have thought about re-implementing the C code with a native Haskell >> version: after all it just checks a few bits. Apparently unsafeCoerce# >> and friends were a big no-no but I found >> https://phabricator.haskell.org/D3358 . I have implemented the code at >> the bottom of this post. Obviously it's missing endianness (compile-time >> switch). >> >> This seems to be faster for smaller `mkInput` list than Prelude.isNaN >> but slower slightly on the one below. The `/=` version is the fastest >> but very fragile. >> >> My question to you all is whether implementing a version of this >> function in Haskell makes sense and if not, why not? The >> stgDoubleToWord64 is implemented in CMM and I don't know anything about >> the costs of that. >> >> * Is there a cheaper alternative to FFI way? >> * If yes, does anyone know how to write it such that it compiles to same >> code but without the call overhead? I must have failed below as it's >> slower on some inputs. >> >> Basically if a faster way exists for isNaN, something I have to do a >> lot, I'd love to hear about it. >> >> I leave you with basic code I managed to come up with. 8.4.x only. >> >> >> ``` >> {-# LANGUAGE MagicHash #-} >> {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-} >> module Main (main) where >> >> import GHC.Float >> import GHC.Prim >> >> isNaN' :: Double -> Bool >> isNaN' d = d /= d >> >> isNaNBits :: Double -> Bool >> isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of >> 1# -> case bits `and#` mantissaMask of >> 0## -> False >> _ -> True >> _ -> False >> where >> bits :: Word# >> bits = stgDoubleToWord64 d >> >> expMask, mantissaMask :: Word# >> expMask = 0x7FF0000000000000## >> mantissaMask = 0x000FFFFFFFFFFFFF## >> >> main :: IO () >> main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) >> `seq` pure () >> where >> nan :: Double >> nan = log (-1) >> >> mkInput :: Int -> [Double] >> mkInput n = take n $ cycle [1, nan] >> >> sumFilter :: (Double -> Bool) -> [Double] -> Double >> sumFilter p = Prelude.sum . Prelude.filter (not . p) >> ``` >> >> -- >> Mateusz K. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- Mateusz K. From allbery.b at gmail.com Tue Mar 6 10:43:58 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 6 Mar 2018 05:43:58 -0500 Subject: FFI-free NaN checks? (isDoubleNan and friends) In-Reply-To: <201e2f18-3ddf-7fe8-3968-5bea950ae03c@fuuzetsu.co.uk> References: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> <201e2f18-3ddf-7fe8-3968-5bea950ae03c@fuuzetsu.co.uk> Message-ID: I'd in general expect good C code to optimize a little better; and in particular, decomposing an IEEE float is almost certainly more expensive in Haskell than in C, because unions let you cheat. (And I recall looking at the implementation of decodeFloat once; it's significantly longer than that C.) But I have to wonder if that code would be better done with something more native; the implementation may be a portable default, and you might be able to find something x86-specific that is faster. On Tue, Mar 6, 2018 at 5:35 AM, Mateusz Kowalczyk wrote: > On 03/05/2018 10:23 PM, Brandon Allbery wrote: > > If the FFI version is done with "safe", consider using "unsafe" instead. > > There are technical reasons why this is slightly incorrect, but unless > > you're fiddling with the CPU's FP control flags they're mostly irrelevant > > and you can treat isNaN as pure and non-side-effectful, significantly > > reducing the overhead. You may also be able to use "ccall" to take > > advantage of C compiler level optimizations, or simply to directly > invoke a > > CPU-based test with asm(); but you'll need to hide that in a C > preprocessor > > #define, so that it looks syntactically like a function call to the FFI. > > > > (One of the technical reasons is that various OSes have been known to > > introduce bugs in their FP register and state handling across system > calls, > > in which case the "safe" version may turn "complete FP chaos" into merely > > "wrong answer". It's your call whether, or which side, of this bothers > you.) > > Perhaps I was a little unclear. The FFI-using isDoubleNaN is something > GHC does! > > ``` > libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN" > isDoubleNaN :: Double -> Int > ``` > ``` > HsInt > isDoubleNaN(HsDouble d) > { > union stg_ieee754_dbl u; > > u.d = d; > > return ( > u.ieee.exponent == 2047 /* 2^11 - 1 */ && /* Is the exponent all > ones? */ > (u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0) > /* and the mantissa non-zero? */ > ); > } > ``` > > My question is whether it could do better by not doing FFI and instead > computing natively and if not, why not? > > > On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk < > fuuzetsu at fuuzetsu.co.uk> > > wrote: > > > >> Hi, > >> > >> Recently at a client I was profiling some code and isDoubleNaN lit up. > >> We were checking a lot of doubles for NaN as that's what customer would > >> send in. > >> > >> I went to investigate and I found that FFI is used to achieve this. I > >> was always under the impression that FFI costs a little. I had at the > >> time replaced the code with a hack with great results: > >> > >> ``` > >> isNaN' :: Double -> Bool > >> isNaN' d = d /= d > >> ``` > >> > >> While this worked and provided good speedup in my case, this fails > >> catastrophically if the program is compiled with -ffast-math. This is > >> expected. I have since reverted it. Seeking an alternative solution I > >> have thought about re-implementing the C code with a native Haskell > >> version: after all it just checks a few bits. Apparently unsafeCoerce# > >> and friends were a big no-no but I found > >> https://phabricator.haskell.org/D3358 . I have implemented the code at > >> the bottom of this post. Obviously it's missing endianness (compile-time > >> switch). > >> > >> This seems to be faster for smaller `mkInput` list than Prelude.isNaN > >> but slower slightly on the one below. The `/=` version is the fastest > >> but very fragile. > >> > >> My question to you all is whether implementing a version of this > >> function in Haskell makes sense and if not, why not? The > >> stgDoubleToWord64 is implemented in CMM and I don't know anything about > >> the costs of that. > >> > >> * Is there a cheaper alternative to FFI way? > >> * If yes, does anyone know how to write it such that it compiles to same > >> code but without the call overhead? I must have failed below as it's > >> slower on some inputs. > >> > >> Basically if a faster way exists for isNaN, something I have to do a > >> lot, I'd love to hear about it. > >> > >> I leave you with basic code I managed to come up with. 8.4.x only. > >> > >> > >> ``` > >> {-# LANGUAGE MagicHash #-} > >> {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm > #-} > >> module Main (main) where > >> > >> import GHC.Float > >> import GHC.Prim > >> > >> isNaN' :: Double -> Bool > >> isNaN' d = d /= d > >> > >> isNaNBits :: Double -> Bool > >> isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of > >> 1# -> case bits `and#` mantissaMask of > >> 0## -> False > >> _ -> True > >> _ -> False > >> where > >> bits :: Word# > >> bits = stgDoubleToWord64 d > >> > >> expMask, mantissaMask :: Word# > >> expMask = 0x7FF0000000000000## > >> mantissaMask = 0x000FFFFFFFFFFFFF## > >> > >> main :: IO () > >> main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) > >> `seq` pure () > >> where > >> nan :: Double > >> nan = log (-1) > >> > >> mkInput :: Int -> [Double] > >> mkInput n = take n $ cycle [1, nan] > >> > >> sumFilter :: (Double -> Bool) -> [Double] -> Double > >> sumFilter p = Prelude.sum . Prelude.filter (not . p) > >> ``` > >> > >> -- > >> Mateusz K. > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > > > > > > -- > Mateusz K. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue Mar 6 11:30:28 2018 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 6 Mar 2018 11:30:28 +0000 Subject: FFI-free NaN checks? (isDoubleNan and friends) In-Reply-To: References: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> <201e2f18-3ddf-7fe8-3968-5bea950ae03c@fuuzetsu.co.uk> Message-ID: <50d08b60-fc3e-034e-2f88-6f361dfd839c@fuuzetsu.co.uk> On 03/06/2018 10:43 AM, Brandon Allbery wrote: > I'd in general expect good C code to optimize a little better; and in > particular, decomposing an IEEE float is almost certainly more expensive in > Haskell than in C, because unions let you cheat. (And I recall looking at > the implementation of decodeFloat once; it's significantly longer than that > C.) But I have to wonder if that code would be better done with something > more native; the implementation may be a portable default, and you might be > able to find something x86-specific that is faster. There's a https://c9x.me/x86/html/file_module_x86_id_316.html that the ‘d /= d’ way compiles to. I suppose maybe I could just keep using that and fall back onto isDoubleNaN if __FAST_MATH__ is set… > On Tue, Mar 6, 2018 at 5:35 AM, Mateusz Kowalczyk > wrote: > >> On 03/05/2018 10:23 PM, Brandon Allbery wrote: >>> If the FFI version is done with "safe", consider using "unsafe" instead. >>> There are technical reasons why this is slightly incorrect, but unless >>> you're fiddling with the CPU's FP control flags they're mostly irrelevant >>> and you can treat isNaN as pure and non-side-effectful, significantly >>> reducing the overhead. You may also be able to use "ccall" to take >>> advantage of C compiler level optimizations, or simply to directly >> invoke a >>> CPU-based test with asm(); but you'll need to hide that in a C >> preprocessor >>> #define, so that it looks syntactically like a function call to the FFI. >>> >>> (One of the technical reasons is that various OSes have been known to >>> introduce bugs in their FP register and state handling across system >> calls, >>> in which case the "safe" version may turn "complete FP chaos" into merely >>> "wrong answer". It's your call whether, or which side, of this bothers >> you.) >> >> Perhaps I was a little unclear. The FFI-using isDoubleNaN is something >> GHC does! >> >> ``` >> libraries/base/GHC/Float.hs:foreign import ccall unsafe "isDoubleNaN" >> isDoubleNaN :: Double -> Int >> ``` >> ``` >> HsInt >> isDoubleNaN(HsDouble d) >> { >> union stg_ieee754_dbl u; >> >> u.d = d; >> >> return ( >> u.ieee.exponent == 2047 /* 2^11 - 1 */ && /* Is the exponent all >> ones? */ >> (u.ieee.mantissa0 != 0 || u.ieee.mantissa1 != 0) >> /* and the mantissa non-zero? */ >> ); >> } >> ``` >> >> My question is whether it could do better by not doing FFI and instead >> computing natively and if not, why not? >> >>> On Mon, Mar 5, 2018 at 4:53 PM, Mateusz Kowalczyk < >> fuuzetsu at fuuzetsu.co.uk> >>> wrote: >>> >>>> Hi, >>>> >>>> Recently at a client I was profiling some code and isDoubleNaN lit up. >>>> We were checking a lot of doubles for NaN as that's what customer would >>>> send in. >>>> >>>> I went to investigate and I found that FFI is used to achieve this. I >>>> was always under the impression that FFI costs a little. I had at the >>>> time replaced the code with a hack with great results: >>>> >>>> ``` >>>> isNaN' :: Double -> Bool >>>> isNaN' d = d /= d >>>> ``` >>>> >>>> While this worked and provided good speedup in my case, this fails >>>> catastrophically if the program is compiled with -ffast-math. This is >>>> expected. I have since reverted it. Seeking an alternative solution I >>>> have thought about re-implementing the C code with a native Haskell >>>> version: after all it just checks a few bits. Apparently unsafeCoerce# >>>> and friends were a big no-no but I found >>>> https://phabricator.haskell.org/D3358 . I have implemented the code at >>>> the bottom of this post. Obviously it's missing endianness (compile-time >>>> switch). >>>> >>>> This seems to be faster for smaller `mkInput` list than Prelude.isNaN >>>> but slower slightly on the one below. The `/=` version is the fastest >>>> but very fragile. >>>> >>>> My question to you all is whether implementing a version of this >>>> function in Haskell makes sense and if not, why not? The >>>> stgDoubleToWord64 is implemented in CMM and I don't know anything about >>>> the costs of that. >>>> >>>> * Is there a cheaper alternative to FFI way? >>>> * If yes, does anyone know how to write it such that it compiles to same >>>> code but without the call overhead? I must have failed below as it's >>>> slower on some inputs. >>>> >>>> Basically if a faster way exists for isNaN, something I have to do a >>>> lot, I'd love to hear about it. >>>> >>>> I leave you with basic code I managed to come up with. 8.4.x only. >>>> >>>> >>>> ``` >>>> {-# LANGUAGE MagicHash #-} >>>> {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm >> #-} >>>> module Main (main) where >>>> >>>> import GHC.Float >>>> import GHC.Prim >>>> >>>> isNaN' :: Double -> Bool >>>> isNaN' d = d /= d >>>> >>>> isNaNBits :: Double -> Bool >>>> isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of >>>> 1# -> case bits `and#` mantissaMask of >>>> 0## -> False >>>> _ -> True >>>> _ -> False >>>> where >>>> bits :: Word# >>>> bits = stgDoubleToWord64 d >>>> >>>> expMask, mantissaMask :: Word# >>>> expMask = 0x7FF0000000000000## >>>> mantissaMask = 0x000FFFFFFFFFFFFF## >>>> >>>> main :: IO () >>>> main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) >>>> `seq` pure () >>>> where >>>> nan :: Double >>>> nan = log (-1) >>>> >>>> mkInput :: Int -> [Double] >>>> mkInput n = take n $ cycle [1, nan] >>>> >>>> sumFilter :: (Double -> Bool) -> [Double] -> Double >>>> sumFilter p = Prelude.sum . Prelude.filter (not . p) >>>> ``` >>>> >>>> -- >>>> Mateusz K. >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >>> >> >> >> -- >> Mateusz K. >> > > > -- Mateusz K. From sylvain at haskus.fr Tue Mar 6 15:30:06 2018 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 6 Mar 2018 16:30:06 +0100 Subject: FFI-free NaN checks? (isDoubleNan and friends) In-Reply-To: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> References: <90e39a17-7c7c-ad27-773e-d062d0a552ab@fuuzetsu.co.uk> Message-ID: <473cbcfe-dca6-2479-f118-c33b5531daaf@haskus.fr> Hi, You can try with foreign primops, it should be faster than the FFI: In IsDoubleNanPrim.s: .global isDoubleNan_prim isDoubleNan_prim:    xor %rbx,%rbx    ucomisd %xmm1, %xmm1    lahf    testb $68, %ah    jnp .Lout    mov $1, %rbx .Lout:    jmp * (%rbp) In IsDoubleNan.hs: {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnliftedFFITypes #-} module Main where import GHC.Base foreign import prim "isDoubleNan_prim" isDoubleNan_prim :: Double# -> Int# isDoubleNan :: Double -> Bool isDoubleNan (D# d#) = case isDoubleNan_prim d# of    0# -> False    _  -> True main :: IO () main = do    let testNaN x = putStrLn $ "Testing " ++ show x ++ ": " ++ show (isDoubleNan x)    testNaN 10.3    testNaN (0/0) Compile with: ghc -Wall -O IsDoubleNan.hs IsDoubleNanPrim.s I haven't benchmarked this but I would be interested to see the comparison with the other versions on your benchmarks! Cheers, Sylvain On 05/03/2018 22:53, Mateusz Kowalczyk wrote: > Hi, > > Recently at a client I was profiling some code and isDoubleNaN lit up. > We were checking a lot of doubles for NaN as that's what customer would > send in. > > I went to investigate and I found that FFI is used to achieve this. I > was always under the impression that FFI costs a little. I had at the > time replaced the code with a hack with great results: > > ``` > isNaN' :: Double -> Bool > isNaN' d = d /= d > ``` > > While this worked and provided good speedup in my case, this fails > catastrophically if the program is compiled with -ffast-math. This is > expected. I have since reverted it. Seeking an alternative solution I > have thought about re-implementing the C code with a native Haskell > version: after all it just checks a few bits. Apparently unsafeCoerce# > and friends were a big no-no but I found > https://phabricator.haskell.org/D3358 . I have implemented the code at > the bottom of this post. Obviously it's missing endianness (compile-time > switch). > > This seems to be faster for smaller `mkInput` list than Prelude.isNaN > but slower slightly on the one below. The `/=` version is the fastest > but very fragile. > > My question to you all is whether implementing a version of this > function in Haskell makes sense and if not, why not? The > stgDoubleToWord64 is implemented in CMM and I don't know anything about > the costs of that. > > * Is there a cheaper alternative to FFI way? > * If yes, does anyone know how to write it such that it compiles to same > code but without the call overhead? I must have failed below as it's > slower on some inputs. > > Basically if a faster way exists for isNaN, something I have to do a > lot, I'd love to hear about it. > > I leave you with basic code I managed to come up with. 8.4.x only. > > > ``` > {-# LANGUAGE MagicHash #-} > {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-stg -ddump-to-file -ddump-asm #-} > module Main (main) where > > import GHC.Float > import GHC.Prim > > isNaN' :: Double -> Bool > isNaN' d = d /= d > > isNaNBits :: Double -> Bool > isNaNBits (D# d) = case (bits `and#` expMask) `eqWord#` expMask of > 1# -> case bits `and#` mantissaMask of > 0## -> False > _ -> True > _ -> False > where > bits :: Word# > bits = stgDoubleToWord64 d > > expMask, mantissaMask :: Word# > expMask = 0x7FF0000000000000## > mantissaMask = 0x000FFFFFFFFFFFFF## > > main :: IO () > main = sumFilter isNaN {-isNaN'-} {-isNaNBits-} (mkInput 100000000) > `seq` pure () > where > nan :: Double > nan = log (-1) > > mkInput :: Int -> [Double] > mkInput n = take n $ cycle [1, nan] > > sumFilter :: (Double -> Bool) -> [Double] -> Double > sumFilter p = Prelude.sum . Prelude.filter (not . p) > ``` > From simon.jakobi at googlemail.com Tue Mar 6 18:27:04 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Tue, 6 Mar 2018 19:27:04 +0100 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: References: <87inaa4esg.fsf@smart-cactus.org> Message-ID: 2018-03-05 18:29 GMT+01:00 Phyx : > > > No objections, however do make sure to test both 32 and 64 bit builds of > ghc when you use the API, it's new enough and rare enough that it may not > be implemented in both mingw-64 tool chains (we've had similar issues > before). > I've failed repeatedly to do a 32bit build via mingw32 on my 64bit Windows box and I don't have access to a 32bit Windows install. Is there CI for the 32bit Windows version that I could rely on? Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kili at outback.escape.de Tue Mar 6 22:06:37 2018 From: kili at outback.escape.de (Matthias Kilian) Date: Tue, 6 Mar 2018 23:06:37 +0100 Subject: ghc, OpenBSD and stack pointer checking In-Reply-To: <20180122205200.GA26895@nutty.outback.escape.de> References: <20180116201302.GB3762@nutty.outback.escape.de> <878tcvyqn2.fsf@smart-cactus.org> <20180122205200.GA26895@nutty.outback.escape.de> Message-ID: <20180306220637.GA1372@nutty.outback.escape.de> ho, On Mon, Jan 22, 2018 at 09:52:01PM +0100, Matthias Kilian wrote: > On Thu, Jan 18, 2018 at 01:21:27PM -0500, Ben Gamari wrote: > > > So, if the stack pointer checking diff to OpenBSD is correct, and > > > if I'm not running into a completely unrelated problem: does ghc > > > and/or the runtime library sometimes move the system stack pointer > > > to newly allocated/mapped memory? If so, where in the code? > > > > > As far as I know GHC shouldn't touch x86-64's $rsp at all; we > > specifically avoid using it for the STG stack to ease FFI. > > Thanks for the information. Little update, in case anyone is interested: with the latest version of the diff[1] to OpenBSD, out ghc port and all the hs-ports build and work fine. So, yes, bug in the early diff, or solar activity during my tests ;-) Ciao, Kili [1] https://marc.info/?l=openbsd-tech&m=152035796722258&w=2 From lonetiger at gmail.com Wed Mar 7 07:10:04 2018 From: lonetiger at gmail.com (Phyx) Date: Wed, 07 Mar 2018 07:10:04 +0000 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: References: <87inaa4esg.fsf@smart-cactus.org> Message-ID: No we have no CI for it. In my experience to get a 32 bit build you need to install the full 32bit msys2. Not just the 32bit compiler in the 64 bit msys2 (two installs can co-exist). Alternatively of you want when your patch is ready ping me (@Mistuke om phabricator) and I'll run a build for you then. On Tue, Mar 6, 2018, 18:27 Simon Jakobi wrote: > 2018-03-05 18:29 GMT+01:00 Phyx : >> >> >> No objections, however do make sure to test both 32 and 64 bit builds of >> ghc when you use the API, it's new enough and rare enough that it may not >> be implemented in both mingw-64 tool chains (we've had similar issues >> before). >> > > I've failed repeatedly to do a 32bit build via mingw32 on my 64bit Windows > box and I don't have access to a 32bit Windows install. > > Is there CI for the 32bit Windows version that I could rely on? > > Thanks, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Wed Mar 7 09:31:56 2018 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Wed, 7 Mar 2018 10:31:56 +0100 Subject: End of Windows Vista support in GHC-8.6? In-Reply-To: References: <87inaa4esg.fsf@smart-cactus.org> Message-ID: On Wed, Mar 7, 2018 at 8:10 AM, Phyx wrote: > In my experience to get a 32 bit build you need to > install the full 32bit msys2. Not just the 32bit compiler in the 64 bit > msys2 (two installs can co-exist). That's also my experience on appveyor (but I'm not compiling GHC itself): https://github.com/LambdaHack/LambdaHack/blob/master/appveyor.yml#L50 Both versions of msys2 are present and I need to set path to the 32 version to compile for 32bit. In this way I'm able to generate both 64bit and 32bit binaries in a single appveyor run. From ben at well-typed.com Wed Mar 7 15:55:21 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 07 Mar 2018 10:55:21 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <20180306.164239.1921474263241137833.kazu@iij.ad.jp> References: <87po4trmr3.fsf@smart-cactus.org> <20180306.164239.1921474263241137833.kazu@iij.ad.jp> Message-ID: <8760675198.fsf@smart-cactus.org> Kazu Yamamoto (山本和彦) writes: > Hello Ben, > Hi Kazu, >> As always, do let us know if you encounter any trouble in the course of >> testing. Thanks for your help! > > I tried GHC 8.4.1rc1 to understand how SemigroupMonoid and MonadFail > proposals work. > > GHC 8.4.1rc1 surely detects Monoid data types if they are not > instances of Semigroup. However, GHC users guide still says that both > -Wcompat and -Wsemigroup are disabled by default. Should we update the > document or am I missing something? > What you are seeing isn't a warning, it's an error. 8.4.1 throws errors for Monoids missing Semigroup instances not because of -Wsemigroup but rather because Semigroup is now a superclass of Monoid. -Wsemigroup will likely be deprecated in a future release now since we've reached phase 2 of the Semigroup/Monoid proposal. > GHC 8.4.1rc does not find Monad data types which define "fail" even > with -Wcompat. Now I understand that > -Wnoncanonical-monadfail-instances is necessary. Why doesn't -Wcampat > include -Wnoncanonical-monadfail-instances? My understanding is that the MonadFail proposal is in a bit of a state of limbo, so its preparatory warning flag hasn't yet been added to -Wcompat. 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 kazu at iij.ad.jp Thu Mar 8 02:05:38 2018 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Thu, 08 Mar 2018 11:05:38 +0900 (JST) Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <8760675198.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> <20180306.164239.1921474263241137833.kazu@iij.ad.jp> <8760675198.fsf@smart-cactus.org> Message-ID: <20180308.110538.870725703295634102.kazu@iij.ad.jp> Hi Ben, > What you are seeing isn't a warning, it's an error. > 8.4.1 throws errors for Monoids missing Semigroup instances not because > of -Wsemigroup but rather because Semigroup is now a superclass of > Monoid. > > -Wsemigroup will likely be deprecated in a future release now since > we've reached phase 2 of the Semigroup/Monoid proposal. Thank you for your explanation. It's now clear to me! >> GHC 8.4.1rc does not find Monad data types which define "fail" even >> with -Wcompat. Now I understand that >> -Wnoncanonical-monadfail-instances is necessary. Why doesn't -Wcampat >> include -Wnoncanonical-monadfail-instances? > > My understanding is that the MonadFail proposal is in a bit of a state > of limbo, so its preparatory warning flag hasn't yet been added to > -Wcompat. OK. I hope the proposal Wiki documents will be updated anyway. --Kazu From ben at well-typed.com Thu Mar 8 16:57:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 11:57:45 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released Message-ID: <87h8pq33p8.fsf@smart-cactus.org> The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From kili at outback.escape.de Thu Mar 8 20:05:02 2018 From: kili at outback.escape.de (Matthias Kilian) Date: Thu, 8 Mar 2018 21:05:02 +0100 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <20180308200502.GA56771@nutty.outback.escape.de> [including only the ghc-devs list in this reply] Hi, On Thu, Mar 08, 2018 at 11:57:45AM -0500, Ben Gamari wrote: > * While we typically strive to produce OpenBSD builds, the gcc shipped > with OpenBSD 6.1 is unfortunately too old to compile this release. Well, OpenBSD 6.1 is almost dead, 6.2 is the stable release at the moment, and 6.3 will probably be released in about two months. For 6.2 the default C compiler is clang-4.0.0, for 6.3, it will be at least clang-5.0.1 (at least on i386 and amd64 platforms). So, providing ghc binaries for 6.1 at all would be mostly pointless, anyway (there will be no support for 6.1 from the moment 6.3 has been released). Ciao, Kili ps: whoever is doing binary releases of ghc for OpenBSD (I only know about Karel Gardas pushing patches from our ports tree from time to time) could use a newer gcc or clang from ports/packages if it helps. Of course, if time permits (and as the defacto maintainer of lang/ghc on OpenBSD I know how time consuming this can be ;-)) From ben at well-typed.com Thu Mar 8 20:27:39 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 15:27:39 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> References: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> Message-ID: <878tb22tzb.fsf@smart-cactus.org> Apostolos Syropoulos via Glasgow-haskell-users writes: > Hello, > > I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and > compilation never starts because: > Can you try applying the attached patch? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-configure-Accept-version-suffix-in-solaris-name.patch Type: text/x-patch Size: 1295 bytes Desc: not available URL: From ben at well-typed.com Thu Mar 8 21:47:01 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 16:47:01 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <20180308200502.GA56771@nutty.outback.escape.de> References: <87h8pq33p8.fsf@smart-cactus.org> <20180308200502.GA56771@nutty.outback.escape.de> Message-ID: <877eqm2qb3.fsf@smart-cactus.org> Matthias Kilian writes: > [including only the ghc-devs list in this reply] > > Hi, > Hi, > On Thu, Mar 08, 2018 at 11:57:45AM -0500, Ben Gamari wrote: >> * While we typically strive to produce OpenBSD builds, the gcc shipped >> with OpenBSD 6.1 is unfortunately too old to compile this release. > > Well, OpenBSD 6.1 is almost dead, 6.2 is the stable release at the > moment, and 6.3 will probably be released in about two months. For > 6.2 the default C compiler is clang-4.0.0, for 6.3, it will be at > least clang-5.0.1 (at least on i386 and amd64 platforms). > > So, providing ghc binaries for 6.1 at all would be mostly pointless, > anyway (there will be no support for 6.1 from the moment 6.3 has > been released). Thanks for the clarification! This is very helpful. > ps: whoever is doing binary releases of ghc for OpenBSD (I only > know about Karel Gardas pushing patches from our ports tree from > time to time) could use a newer gcc or clang from ports/packages > if it helps. Of course, if time permits (and as the defacto maintainer > of lang/ghc on OpenBSD I know how time consuming this can be ;-)) Indeed that is me. There is a bit more to the story of why we have no OpenBSD builds: In short, I don't actually have a machine running OpenBSD. Usually I spin up a virtual machine locally to produce distributions for distributions which I don't myself run. However, this time I had quite some trouble bringing up an OpenBSD VM (the installation image appeared to hang shortly after booting when running on QEmu/kvm on both Intel and AMD hardware). Lacking any way to produce a build locally, I turned to AWS, which only has an AMI for OpenBSD 6.1. 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 svenpanne at gmail.com Fri Mar 9 09:23:18 2018 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 9 Mar 2018 10:23:18 +0100 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: 2018-03-08 17:57 GMT+01:00 Ben Gamari : > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. [...] Just a few tiny remarks regarding "base": * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries says that the shipped "base" has version 2.1, I guess that should be 4.11.0.0. * https://wiki.haskell.org/Base_package needs an update. * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. Yes, there is https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, but Hackage is somehow the more canonical place to look up the package docs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From metaniklas at gmail.com Fri Mar 9 11:35:46 2018 From: metaniklas at gmail.com (Niklas Larsson) Date: Fri, 9 Mar 2018 12:35:46 +0100 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: Hi! It says on the download page that the Windows versions is “excluding the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste error from the release that fixed the Windows 10 CU bug. Regards, Niklas > 8 mars 2018 kl. 17:57 skrev Ben Gamari : > > > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. Binary and source distributions can be found > at > > https://downloads.haskell.org/~ghc/8.4.1/ > > This is the third major release in the GHC 8 series. As such, the focus > of this release is performance, stability, and consolidation. > Consequently numerous cleanups can be seen throughout the compiler > including, > > * Further refinement of TypeInType, including significant improvements > in error messages. > > * Improvements in code generation resulting in noticable performance > improvements in some types of programs. > > * Core library improvements, including phase 2 of the Semigroup/Monoid > proposal > > * Many improvements to instance deriving > > * The resolution of nearly 300 other tickets > > A more thorough list of the changes in this release can be found in the > release notes, > > https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html > > There are a few changes in release-engineering matters that should be > noted, > > * This is GHC's first release on it's new, accelerated release > schedule. From now on GHC will produce one release every six months. > > * While we typically strive to produce OpenBSD builds, the gcc shipped > with OpenBSD 6.1 is unfortunately too old to compile this release. > > * FreeBSD builds are still in progress > > This release has been the result of approximately six months of work by > over one hundred code contributors. Thanks to everyone who has helped in > writing patches, testing, reporting bugs, and offering feedback over the > last year. > > As always, let us know if you encounter trouble. > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating efficient code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces. GHC is distributed under a BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://ghc.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://mail.haskell.org/cgi-bin/mailman/listinfo > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From ben at well-typed.com Fri Mar 9 13:47:30 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:47:30 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87k1ul1hu8.fsf@smart-cactus.org> Sven Panne writes: > 2018-03-08 17:57 GMT+01:00 Ben Gamari : > >> The GHC developers are very happy to announce the 8.4.1 release of >> Glasgow Haskell Compiler. [...] > > > Just a few tiny remarks regarding "base": > > * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries > > says that the shipped "base" has version 2.1, I guess that should be > 4.11.0.0. > Good catch; in principle this should now be automatically generated. I'll need to look at what has gone wrong here. I've opened #14906 to track this. > * https://wiki.haskell.org/Base_package needs an update. > Ahh, thanks; I've added this to the MakingReleases protocol [1] to ensure that this is done in the future. > * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. > Yes, there is > https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, > but Hackage is somehow the more canonical place to look up the package docs. Yes, the Hackage uploads have historically not been handled by me but rather Herbert. He know about the release and am certain has the task on his queue. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases -------------- 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 Fri Mar 9 13:50:25 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:50:25 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87h8pp1hpd.fsf@smart-cactus.org> Niklas Larsson writes: > Hi! > > It says on the download page that the Windows versions is “excluding > the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste > error from the release that fixed the Windows 10 CU bug. > Oh dear, yes. Thank you for noticing 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 ben at well-typed.com Fri Mar 9 17:15:13 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 12:15:13 -0500 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> <87h8pp1hpd.fsf@smart-cactus.org> Message-ID: <871sgt1883.fsf@smart-cactus.org> Vassil Ognyanov Keremidchiev writes: > I saw there is ARM Aarch64 build, which is pretty cool! But will there be a > ARMv7 (32bit build) as well? > I do hope so. There have been a number of false-starts but hopefully the build that is currently running will finish. Unfortunately getting a working ARMv7 build is rather tricky due to a number of linker bugs that bite under various circumstances. 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 takenobu.hs at gmail.com Sat Mar 10 02:48:17 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 10 Mar 2018 11:48:17 +0900 Subject: NumericUnderscores extension was added to Cabal for ghc 8.6 Message-ID: Dear devs, The `NumericUnderscores` extension was added to Cabal for ghc 8.6. [1] I'm sending this mail referring to `BlockArguments`. [2] [1] https://github.com/haskell/cabal/pull/5130 [2] https://mail.haskell.org/pipermail/ghc-devs/2018-February/015341.html Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at xuanruiqi.com Sat Mar 10 07:08:27 2018 From: me at xuanruiqi.com (Xuanrui Qi) Date: Sat, 10 Mar 2018 07:08:27 +0000 Subject: Questions about pointers in GHC Message-ID: Hi all, I have a few questions about heap-allocated memory pointers in GHC. Both code and data live in the heap, and both can have pointers to other objects. However, according to my understanding, most heap-allocated objects would be immutable. Moreover even if objects might be mutated, most pointers should not be updated. I have heard that the runtime system might implement several features by updating pointers, but I am not sure which features are they. My question is thus: (1) is there a way to trace mutations of heap objects (for instance by modifying the GC system code) [I don't need to know what is the change, all I want to know is what has been changed], and (2) is there a way where I could trace pointer updates [in this case I'd like to know both the old and objects, preferably by name]? More specifically, are these possible by annotating/changing the runtime system only (i.e. not touching code generation)? Thanks, Ray Department of Computer Science Tufts University -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Mar 10 18:42:38 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 10 Mar 2018 13:42:38 -0500 Subject: Questions about pointers in GHC In-Reply-To: References: Message-ID: <87po4bzs9w.fsf@smart-cactus.org> Xuanrui Qi writes: > Hi all, > Hi, > I have a few questions about heap-allocated memory pointers in GHC. > Both code and data live in the heap, and both can have pointers to > other objects. However, according to my understanding, most > heap-allocated objects would be immutable. Moreover even if objects > might be mutated, most pointers should not be updated. I have heard > that the runtime system might implement several features by updating > pointers, but I am not sure which features are they. > Code generally doesn't live on the dynamically-allocated heap. Rather, it is mmap'd immutably into the process's address space. However, closures, which can live in the heap, generally contain pointers to code and can indeed be mutated. > My question is thus: (1) is there a way to trace mutations of heap > objects (for instance by modifying the GC system code) [I don't need > to know what is the change, all I want to know is what has been > changed], Indeed it is possible. The RTS already tracks most mutations via a write barrier to ensure safety of its generational GC. See the recordMutable macro defined in Cmm.h. > and (2) is there a way where I could trace pointer updates > [in this case I'd like to know both the old and objects, preferably by > name]? More specifically, are these possible by annotating/changing > the runtime system only (i.e. not touching code generation)? > This will be a fair bit harder, requiring modification of the RTS's mutation operations (see PrimOps.cmm and Updates.cmm) at very least. 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 kavon at farvard.in Sat Mar 10 23:12:00 2018 From: kavon at farvard.in (Kavon Farvardin) Date: Sat, 10 Mar 2018 17:12:00 -0600 Subject: Questions about pointers in GHC In-Reply-To: <87po4bzs9w.fsf@smart-cactus.org> References: <87po4bzs9w.fsf@smart-cactus.org> Message-ID: <70EBF7A7-F0E0-40C3-8FE2-7B9D508C5ACA@farvard.in> I'll add that another place where mutation occurs is when demanding an unevaluated thunk (this acts like a read barrier). This once-written property of thunk objects is handled specially by the garbage collector [1]. [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2008/06/par-gc-ismm08.pdf (I believe this is current version in GHC's master branch) > On Mar 10, 2018, at 12:42 PM, Ben Gamari wrote: > > Xuanrui Qi writes: > >> Hi all, >> > Hi, > >> I have a few questions about heap-allocated memory pointers in GHC. >> Both code and data live in the heap, and both can have pointers to >> other objects. However, according to my understanding, most >> heap-allocated objects would be immutable. Moreover even if objects >> might be mutated, most pointers should not be updated. I have heard >> that the runtime system might implement several features by updating >> pointers, but I am not sure which features are they. >> > Code generally doesn't live on the dynamically-allocated heap. Rather, > it is mmap'd immutably into the process's address space. However, > closures, which can live in the heap, generally contain pointers to > code and can indeed be mutated. > >> My question is thus: (1) is there a way to trace mutations of heap >> objects (for instance by modifying the GC system code) [I don't need >> to know what is the change, all I want to know is what has been >> changed], > > Indeed it is possible. The RTS already tracks most mutations via a write > barrier to ensure safety of its generational GC. See the recordMutable > macro defined in Cmm.h. > >> and (2) is there a way where I could trace pointer updates >> [in this case I'd like to know both the old and objects, preferably by >> name]? More specifically, are these possible by annotating/changing >> the runtime system only (i.e. not touching code generation)? >> > This will be a fair bit harder, requiring modification of the RTS's > mutation operations (see PrimOps.cmm and Updates.cmm) at very least. > > Cheers, > > - 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 juhpetersen at gmail.com Wed Mar 14 09:51:48 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 14 Mar 2018 18:51:48 +0900 Subject: [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: On 9 March 2018 at 01:57, Ben Gamari wrote: > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. Thanks! I have built it for Fedora and EPEL7 in a copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.1/ Cheers, Jens From simonpj at microsoft.com Thu Mar 15 22:52:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 15 Mar 2018 22:52:47 +0000 Subject: The Haskell Report: who maintains it? Message-ID: Friends Does anyone know who, if anyone, feels responsible for committing updates to the Haskell 2010 Report? Who even has commit rights? There’s Frank’s pull request below, and I have another important typo to fix. Thanks Simon From: Frank Steffahn [mailto:notifications at github.com] Sent: 11 March 2018 17:03 To: haskell/haskell-report Cc: Subscribed Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4) Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / mistake. I’m not 100% sure if this is the right branch (or even in general the right place) to note this, but I hope it will get fixed ;-) This seems like it is an artifact of copy-and-pasting from “Semantics of Case Expressions, Part 1 (c)” without properly adapting the thing, especially in commit bc94554. ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/haskell/haskell-report/pull/4 Commit Summary * Fix a typo in: Semantics of Case Expressions, Part 3 (s) File Changes * M report/exps.verb (1) Patch Links: * https://github.com/haskell/haskell-report/pull/4.patch * https://github.com/haskell/haskell-report/pull/4.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Mar 15 22:57:13 2018 From: david.feuer at gmail.com (David Feuer) Date: Thu, 15 Mar 2018 18:57:13 -0400 Subject: [Haskell] The Haskell Report: who maintains it? In-Reply-To: References: Message-ID: We also have an inconsistency between the textual descriptions of accumArray and accum and their reference implementations. I recently changed GHC's implementations to better match the text (for efficiency reasons), but the reference implementations should be adjusted too. On Thu, Mar 15, 2018 at 6:52 PM, Simon Peyton Jones via Haskell < haskell at haskell.org> wrote: > Friends > > > > Does anyone know who, if anyone, feels responsible for committing updates > to the Haskell 2010 Report? > > > > Who even has commit rights? > > > > There’s Frank’s pull request below, and I have another important typo to > fix. > > > > Thanks > > > > Simon > > > > *From:* Frank Steffahn [mailto:notifications at github.com] > *Sent:* 11 March 2018 17:03 > *To:* haskell/haskell-report > *Cc:* Subscribed > *Subject:* [haskell/haskell-report] Fix a typo in: Semantics of Case > Expressions, Part 3 (s) (#4) > > > > Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / > mistake. I’m not 100% sure if this is the right branch (or even in general > the right place) to note this, but I hope it will get fixed ;-) > > This seems like it is an artifact of copy-and-pasting from “Semantics of > Case Expressions, Part 1 (c)” without properly adapting the thing, > especially in commit bc94554 > > . > ------------------------------ > You can view, comment on, or merge this pull request online at: > > https://github.com/haskell/haskell-report/pull/4 > > Commit Summary > > - Fix a typo in: Semantics of Case Expressions, Part 3 (s) > > File Changes > > - *M* report/exps.verb > > (1) > > Patch Links: > > - https://github.com/haskell/haskell-report/pull/4.patch > > - https://github.com/haskell/haskell-report/pull/4.diff > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > > . > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmct at jmct.cc Thu Mar 15 23:17:12 2018 From: jmct at jmct.cc (=?utf-8?Q?Jos=C3=A9=20Manuel=20Calder=C3=B3n=20Trilla?=) Date: Thu, 15 Mar 2018 19:17:12 -0400 Subject: [Haskell] The Haskell Report: who maintains it? In-Reply-To: References: Message-ID: <1521155832.1278526.1304854160.6717D8AD@webmail.messagingengine.com> All of us on the Haskell Language Committee have the ability to commit on that repo. I think typos are uncontroversial and I'll happily merge pull requests like that. I think the pull-request you point out suffered from the bystander effect, unfortunately. I'll review and merge it now. If you let me know the typo you'd like fixed I'll make sure that gets done as well. Cheers,José Manuel On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote:> Friends > > Does anyone know who, if anyone, feels responsible for committing > updates to the Haskell 2010 Report?> > Who even has commit rights? > > There’s Frank’s pull request below, and I have another important > typo to fix.> > Thanks > > Simon > > > *From:* Frank Steffahn [mailto:notifications at github.com] *Sent:* 11 > March 2018 17:03 *To:* haskell/haskell-report report at noreply.github.com> *Cc:* Subscribed > *Subject:* [haskell/haskell-report] > Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4)> > Hi. I noticed this in the Haskell 2010 report, which is an obvious > typo / mistake. I’m not 100% sure if this is the right branch (or > even in general the right place) to note this, but I hope it will get > fixed ;-)> This seems like it is an artifact of copy-and-pasting from “Semantics > of Case Expressions, Part 1 (c)” without properly adapting the thing, > especially in commit bc94554.> > You can view, comment on, or merge this pull request online at: > https://github.com/haskell/haskell-report/pull/4[1] > Commit Summary > * Fix a typo in: Semantics of Case Expressions, Part 3 (s)> File Changes > * *M* report/exps.verb[2] (1) > Patch Links: > * https://github.com/haskell/haskell-report/pull/4.patch[3] > * https://github.com/haskell/haskell-report/pull/4.diff[4]> — You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub[5], or mute the > thread[6].> _________________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell Links: 1. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=1xk6eQn%2Fq4vKglbQSLHNOGYrNdxJBp074b2%2ByJbvCrQ%3D&reserved=0 2. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4%2Ffiles%23diff-0&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=OYptlGmxyWflETFlpd4f8ln1AEYgT8EwiYX44dPafJI%3D&reserved=0 3. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.patch&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=gUICTD38nmiLSOheLW14zHM%2FTj2Uv59k7kxyxXKXgpU%3D&reserved=0 4. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4.diff&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=NrCOwM0rJ8rH0p7d3tSG7YCsVziBJGli%2BKfx8SaFgDE%3D&reserved=0 5. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaskell-report%2Fpull%2F4&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=1xk6eQn%2Fq4vKglbQSLHNOGYrNdxJBp074b2%2ByJbvCrQ%3D&reserved=0 6. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAjsewyB3mgR1zjDxYvon2hz67U0hf_Zks5tdVjEgaJpZM4SlxDs&data=04%7C01%7Csimonpj%40microsoft.com%7C31eff0e0f0104cb0e64408d58771f2eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636563845832254992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=mnTU7w1yzqPGoT6eYBrw21SvvrnH6byxUEi2yZZ1ftE%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrohavoc at gmail.com Fri Mar 16 05:12:01 2018 From: astrohavoc at gmail.com (Shao Cheng) Date: Fri, 16 Mar 2018 05:12:01 +0000 Subject: Custom ghcPrimIface for cross-compilation? Message-ID: Hi all, is it possible for a 64-bit ghc to emit 32-bit code, if I supply a custom ghcPrimIface via Hooks and also modify the platform flags in DynFlags? The module does not import Prelude and has no dependencies other than GHC.Prim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Fri Mar 16 06:10:26 2018 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 16 Mar 2018 14:10:26 +0800 Subject: Custom ghcPrimIface for cross-compilation? In-Reply-To: References: Message-ID: Hi, not sure I understand your question. If you build a cross compiler targetting a 32bit device (say Raspbian/Raspberry Pi) for say x86_64 linux, you end up with a 64bit compiler emitting code for a 32bit device. If you question revolves around dynamically changing GHCs target at runtime. Essentially turning GHC into a multi-target compiler, we hope to get there eventually. Please not that just emitting a single module in 32bit is likely not going to get you far. You will still need to build the rts and potentially some additional support libraries to turn that module into something useful. Cheers, Moritz > On Mar 16, 2018, at 1:12 PM, Shao Cheng wrote: > > Hi all, is it possible for a 64-bit ghc to emit 32-bit code, if I supply a custom ghcPrimIface via Hooks and also modify the platform flags in DynFlags? The module does not import Prelude and has no dependencies other than GHC.Prim. _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From stegeman at gmail.com Fri Mar 16 14:09:57 2018 From: stegeman at gmail.com (Luite Stegeman) Date: Fri, 16 Mar 2018 14:09:57 +0000 Subject: Custom ghcPrimIface for cross-compilation? In-Reply-To: References: Message-ID: Hi, Normally when you build a cross compiler, you build the GHC sources configured for the target platform. Your GHC.Prim would already expect 32 bit, so the hook is not needed. However if you want to use the ghc library to build a non-standard cross compiler (GHCJS in my case), it may be useful. I added the `ghcPrimIface` hook for this purpose: GHCJS essentially targets a 32 bit platform, and it's a standalone program that uses the existing (already installed) `ghc` library. But this is really a stop-gap solution. Besides replacing the GHC.Prim interface, you also need to make sure that the name cache in the GHC session doesn't contain entries referring to the built-in version, and the built-in rewrite rules also need to be avoided. And apparently there are more places: In GHCJS on GHC 8.0 it is possible to get type errors that shouldn't have been there, caused by differences between the original and replaced GHC.Prim module. For GHC 8.2 I made the decision to abandon the use of the ghcPrimIface hook, instead building GHCJS against a "private" ghc library (under the cabal package name `ghc-api-ghcjs` ). The `ghc-api-ghcjs` library always targets 32 bit. Once we have a better way to dynamically change the target in the `ghc` library, GHCJS can drop the customized library. Luite On Fri, Mar 16, 2018 at 6:12 AM Shao Cheng wrote: > Hi all, is it possible for a 64-bit ghc to emit 32-bit code, if I supply a > custom ghcPrimIface via Hooks and also modify the platform flags in > DynFlags? The module does not import Prelude and has no dependencies other > than GHC.Prim. _______________________________________________ > 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 chow.soham at gmail.com Sat Mar 17 19:17:39 2018 From: chow.soham at gmail.com (Soham Chowdhury) Date: Sat, 17 Mar 2018 19:17:39 +0000 Subject: [GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types In-Reply-To: <065.ad4391f791f4da3372d3314908d8ca11@haskell.org> References: <050.87f5b641e82d5f06fa4748e90b74c406@haskell.org> <065.ad4391f791f4da3372d3314908d8ca11@haskell.org> Message-ID: That sounds great! I never got around to working on this myself, feel free :) On Sun, Mar 18, 2018, 00:45 GHC wrote: > #13776: -ddump-splices produces unnecessarily qualified names for tuple > and list > types > -------------------------------------+------------------------------------- > Reporter: RyanGlScott | Owner: mrkgnao > Type: bug | Status: new > Priority: normal | Milestone: > Component: Template Haskell | Version: 8.0.1 > Resolution: | Keywords: newcomer > 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 ckoparkar): > > I'd like to work on this, if that's OK with @mrkgnao. > > I have a patch on my local machine > that does the right thing for the examples posted in the > description (and some tests: `th/T3319`, `th/T5700`, > `th/TH_foreignInterruptible`). > While I work on submitting that on Phabricator, I wanted to post a summary > here and get some early feedback. > > > (1) It seems that `showName` doesn't play a role in pretty-printing the > splices > with `-ddump-splices`. Instead, the `Outputable` instances in GHC do most > of the > work. Specifically, `Outputable RdrName` is responsible for printing out > the fully > qualified names in question. > > (2) When the Renamer typechecks & runs a splice (`RnSplice.runRnSplice`), > it > converts the splice to `HsSyn RdrName` (hence the `Outputable RdrName`). > `TcSplice.lookupThName` is involved in the process, which converts > a `TH.Name` to `Name` via `Convert.thRdrNameGuesses`. > > (3) For primitives like `[]`, `(:)` etc. `TH.dataToQa` generates a fully > qualified > global name, i.e `NameG NameSpace PkgName ModName`. > And the corresponding `RdrName` generated by `thRdrNameGuesses` is also > fully > qualified (`Orig Module OccName`). But this is not what we want for built- > in syntax. > > (4) So the "patch" is a simple change to modify this behavior. If > `thOrigRdrName` is > dealing with built-in syntax, it returns an `Exact Name` instead. > > {{{#!haskell > > thOrigRdrName :: String -> TH.NameSpace -> PkgName -> ModName -> RdrName > thOrigRdrName occ th_ns pkg mod = > let occ' = mk_occ (mk_ghc_ns th_ns) occ > in case isBuiltInOcc_maybe occ' of > Just name -> nameRdrName name > Nothing -> (mkOrig $! (mkModule (mk_pkg pkg) (mk_mod mod))) $! occ' > > }}} > > I ran the testsuite, and apart from some `perf` tests, almost everything > else worked. > > These tests fail: > > {{{ > ghci/linking/ghcilink003.run ghcilink003 [bad exit code] (normal) > > ghci/linking/ghcilink006.run ghcilink006 [bad exit code] (normal) > > th/T13366.run -- (gcc: error trying to exec 'cc1plus': > execvp: > -- No such file or directory) > }}} > > but there's a good chance that this is unrelated to the patch. > > > Does the overall approach seem reasonable ? I'll submit a patch soon. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Sun Mar 18 05:38:31 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Sun, 18 Mar 2018 13:38:31 +0800 Subject: Is "cml_cont" of CmmCall used in practice? Message-ID: Hi all, Is the "cml_cont" field of the CmmCall variant is really used in practice? I traversed the output of raw Cmm produced by ghc compiling the whole base package, but the value of cml_cont is always Nothing. Regards, Shao Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sun Mar 18 07:32:25 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 18 Mar 2018 10:32:25 +0300 Subject: Is "cml_cont" of CmmCall used in practice? In-Reply-To: References: Message-ID: Hi Shao, Perhaps not in the Cmm output generated for your programs, but it's definitely used in the code generator. See e.g. `lowerSafeForeignCall` and `blockCode` which set the field with `Just`. The former seems to be related with foreign calls so perhaps try compiling a FFI package. `CmmLayoutStack` uses that field for code generation (I don't understand the details yet). Ömer 2018-03-18 8:38 GMT+03:00 Shao, Cheng : > Hi all, > > Is the "cml_cont" field of the CmmCall variant is really used in practice? I > traversed the output of raw Cmm produced by ghc compiling the whole base > package, but the value of cml_cont is always Nothing. > > Regards, > Shao Cheng > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From cheng.shao at tweag.io Sun Mar 18 07:50:19 2018 From: cheng.shao at tweag.io (Cheng Shao) Date: Sun, 18 Mar 2018 07:50:19 +0000 Subject: Is "cml_cont" of CmmCall used in practice? In-Reply-To: References: Message-ID: Hi Ömer, See e.g. `lowerSafeForeignCall` and `blockCode` > which set the field with `Just`. The former seems to be related with > foreign > calls so perhaps try compiling a FFI package. I tried compiling a module with a `foreign import ccall safe` declaration, yet the output raw Cmm still doesn't use `cml_cont`. `CmmLayoutStack` uses that field > for code generation (I don't understand the details yet). > Thanks for pointing that out, I'll check its implementation. I also found another evidence of the field not used by codegens: in `PprC` which is used by unregisterised builds, only the `cml_target` field is used. So for now I assume that the assertion of `cml_cont = Nothing` holds for final Cmm output, and backend writers need not be concerned with it. Regards, Shao Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.terepeta at gmail.com Sun Mar 18 13:52:10 2018 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Sun, 18 Mar 2018 13:52:10 +0000 Subject: Is "cml_cont" of CmmCall used in practice? In-Reply-To: References: Message-ID: On Sun, Mar 18, 2018 at 6:38 AM Shao, Cheng wrote: > Hi all, > > Is the "cml_cont" field of the CmmCall variant is really used in practice? > I traversed the output of raw Cmm produced by ghc compiling the whole base > package, but the value of cml_cont is always Nothing. > > Regards, > Shao Cheng > Hi, I'm not a GHC expert, so please don't trust everything I say ;) That being said, I think `cml_cont` is used a lot. If you look at the `compiler/codeGen` directory (that's what turns STG to cmm), you'll see that `MkGraph.mkCallReturnsTo` is called a few times. That's the function that will construct a `CmmCall` with the continuation block. When dumping cmm, you'll often see all those `returns to` notes. For instance, compiling: ``` foo :: Int -> Int foo x = case x of 42 -> 111111 _ -> 000000 ``` results in: ``` [...] c2cN: // global I64[Sp - 8] = c2cI; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c2cI; else goto c2cJ; // Evaluate the parameter. c2cJ: // global call (I64[R1])(R1) returns to c2cI, args: 8, res: 8, upd: 8; // ^^^^^^^^^^^^^^^ // this specifies the continuation block // see also PprCmm.pprNode // Now check if it's 42. c2cI: // global if (I64[R1 + 7] == 42) goto c2cU; else goto c2cT; c2cU: // global [...] ``` As far as I understand it, this allows the code above to jump to the `x` closure (to evalutae it), and have the closure jump back to the continuation block (note that it's address is stored before we jump to closure). AFAICS this particular code is created by `StgCmmExpr.emitEnter`. Hope this helps! - Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sun Mar 18 14:48:55 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 18 Mar 2018 17:48:55 +0300 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? Message-ID: Hi, I'm trying to understand what a "return" list in INFO_TABLE_RET declaration line specifies. As far as I understand a "return" in the declaration line is something different than a "return" in the body. For example, in this definition: (in HeapStackCheck.cmm) INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) return (/* no return values */) { return (ptr); } The return list is empty and it even says "no return values" explicitly, yet it returns something. My guess is that the "return" list in the header is actually for arguments. I found this info table which has an argument: (in StgMiscClosures.cmm) INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs) return (P_ ret) { unwind Sp = Sp + WDS(2); #if defined(PROFILING) CCCS = cccs; #endif jump stg_ap_0_fast(ret); } This is the use site: (in Interpreter.c) #if defined(PROFILING) // restore the CCCS after evaluating the closure Sp_subW(2); SpW(1) = (W_)cap->r.rCCCS; SpW(0) = (W_)&stg_restore_cccs_eval_info; #endif Sp_subW(2); SpW(1) = (W_)tagged_obj; SpW(0) = (W_)&stg_enter_info; RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); If I understand this correctly, the "tagged_obj" code will put the return value in R1, pop the stack (which will have stg_restore_ccs_eval_info at the bottom) and jump to this the info table code shown above. So `P_ ret` is the value of `tagged_obj`, and the "return" list is actually for parameters. Did I get this right? If I did, I'm curious why it's called "return" and not "args" or something like that. Thanks, Ömer From kavon at farvard.in Sun Mar 18 22:34:46 2018 From: kavon at farvard.in (Kavon Farvardin) Date: Sun, 18 Mar 2018 17:34:46 -0500 Subject: Is "cml_cont" of CmmCall used in practice? In-Reply-To: References: Message-ID: <81B10A9E-BEBC-4267-858A-87414933D05A@farvard.in> > Is the "cml_cont" field of the CmmCall variant is really used in practice? Seconding what Michal has already said, yes, the `cml_cont` field is used quite a bit in Cmm. Any non-tail call in the program will have this field populated with information about where control-flow continues after the call returns. This field is used for some important steps, such as Proc Point analysis ( CmmProcPoint.callProcPoints ), the result of which is used to layout the stack. Stack layout uses the information about what values are live in the continuation block of a non-tail call to determine what values need to be saved to the stack. Thus, the control-flow graph structure of a CmmProc is defined in part by the `cml_cont` field (see the Cmm specific instance of Hoopl's NonLocal class in CmmNode, where it is used to indicate successors of a block). > I traversed the output of raw Cmm produced by ghc compiling the whole base package, but the value of cml_cont is always Nothing. Hrm, were you looking for "returns to" in that output? ~kavon > On Mar 18, 2018, at 8:52 AM, Michal Terepeta wrote: > > On Sun, Mar 18, 2018 at 6:38 AM Shao, Cheng > wrote: > Hi all, > > Is the "cml_cont" field of the CmmCall variant is really used in practice? I traversed the output of raw Cmm produced by ghc compiling the whole base package, but the value of cml_cont is always Nothing. > > Regards, > Shao Cheng > > > Hi, > > I'm not a GHC expert, so please don't trust everything I say ;) > > That being said, I think `cml_cont` is used a lot. If you look at the > `compiler/codeGen` directory (that's what turns STG to cmm), you'll > see that `MkGraph.mkCallReturnsTo` is called a few times. That's the > function that will construct a `CmmCall` with the continuation block. > > When dumping cmm, you'll often see all those `returns to` notes. For > instance, compiling: > > ``` > foo :: Int -> Int > foo x = > case x of > 42 -> 111111 > _ -> 000000 > ``` > > results in: > > ``` > [...] > c2cN: // global > I64[Sp - 8] = c2cI; > R1 = R2; > Sp = Sp - 8; > if (R1 & 7 != 0) goto c2cI; else goto c2cJ; > > // Evaluate the parameter. > c2cJ: // global > call (I64[R1])(R1) returns to c2cI, args: 8, res: 8, upd: 8; > // ^^^^^^^^^^^^^^^ > // this specifies the continuation block > // see also PprCmm.pprNode > > // Now check if it's 42. > c2cI: // global > if (I64[R1 + 7] == 42) goto c2cU; else goto c2cT; > c2cU: // global > [...] > ``` > > As far as I understand it, this allows the code above to jump to the > `x` closure (to evalutae it), and have the closure jump back to the > continuation block (note that it's address is stored before we jump to > closure). AFAICS this particular code is created by > `StgCmmExpr.emitEnter`. > > Hope this helps! > > - Michal > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From rahulmutt at gmail.com Mon Mar 19 00:53:48 2018 From: rahulmutt at gmail.com (Rahul Muttineni) Date: Mon, 19 Mar 2018 06:23:48 +0530 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: Hi Omer, An INFO_TABLE_RET is a frame that "can be returned to" and the return keyword allows you to provide a name for the value(s) that was(were) returned to this frame and do something with it if you wish. If you didn't have this keyword, you would have to do low-level stack manipulations yourself to get a handle on the return value and it's easy to mess up. You can think of INFO_TABLE_RET as a traditional stack frame in languages like C, except it's powerful because you can specify custom logic on how you deal with the returned value. In some cases, like stg_atomically_frame, you may not even return the value further down into the stack until certain conditions are met (the transaction is valid). Hope that helps, Rahul On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan wrote: > Hi, > > I'm trying to understand what a "return" list in INFO_TABLE_RET declaration > line specifies. As far as I understand a "return" in the declaration line > is > something different than a "return" in the body. For example, in this > definition: (in HeapStackCheck.cmm) > > INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) > return (/* no return values */) > { > return (ptr); > } > > The return list is empty and it even says "no return values" explicitly, > yet it > returns something. > > My guess is that the "return" list in the header is actually for > arguments. I > found this info table which has an argument: (in StgMiscClosures.cmm) > > INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs) > return (P_ ret) > { > unwind Sp = Sp + WDS(2); > #if defined(PROFILING) > CCCS = cccs; > #endif > jump stg_ap_0_fast(ret); > } > > This is the use site: (in Interpreter.c) > > #if defined(PROFILING) > // restore the CCCS after evaluating the closure > Sp_subW(2); > SpW(1) = (W_)cap->r.rCCCS; > SpW(0) = (W_)&stg_restore_cccs_eval_info; > #endif > Sp_subW(2); > SpW(1) = (W_)tagged_obj; > SpW(0) = (W_)&stg_enter_info; > RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); > > If I understand this correctly, the "tagged_obj" code will put the return > value > in R1, pop the stack (which will have stg_restore_ccs_eval_info at the > bottom) > and jump to this the info table code shown above. So `P_ ret` is the value > of > `tagged_obj`, and the "return" list is actually for parameters. > > Did I get this right? If I did, I'm curious why it's called "return" and > not > "args" or something like that. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Rahul Muttineni -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 19 09:02:33 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Mar 2018 09:02:33 +0000 Subject: Is "cml_cont" of CmmCall used in practice? In-Reply-To: References: Message-ID: Adding Kavon. It would be good to record the outcome of this discussion in a 'Note' with the cml_cont declaration, explaining what it is for. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 18 March 2018 07:32 | To: Shao, Cheng | Cc: ghc-devs | Subject: Re: Is "cml_cont" of CmmCall used in practice? | | Hi Shao, | | Perhaps not in the Cmm output generated for your programs, but it's | definitely used in the code generator. See e.g. `lowerSafeForeignCall` | and `blockCode` which set the field with `Just`. The former seems to | be related with foreign calls so perhaps try compiling a FFI package. | `CmmLayoutStack` uses that field for code generation (I don't | understand the details yet). | | Ömer | | 2018-03-18 8:38 GMT+03:00 Shao, Cheng : | > Hi all, | > | > Is the "cml_cont" field of the CmmCall variant is really used in | > practice? I traversed the output of raw Cmm produced by ghc | compiling | > the whole base package, but the value of cml_cont is always Nothing. | > | > Regards, | > Shao Cheng | > | > _______________________________________________ | > 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=04%7C01%7Csi | > | monpj%40microsoft.com%7Cb624f4ab25864a0a466d08d58ca28b07%7C72f988bf86f | > | 141af91ab2d7cd011db47%7C1%7C0%7C636569552118955129%7CUnknown%7CTWFpbGZ | > | sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1 | > &sdata=tdrRLRO6oORnAtTojQWMOXiL44hjVDJHFsORetboceM%3D&reserved=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=04%7C01%7Csimonpj%40microsoft.com%7Cb624f4ab25864a0a466d08d5 | 8ca28b07%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365695521189551 | 29%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | 6Ik1haWwifQ%3D%3D%7C- | 1&sdata=tdrRLRO6oORnAtTojQWMOXiL44hjVDJHFsORetboceM%3D&reserved=0 From omeragacan at gmail.com Mon Mar 19 10:02:47 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Mon, 19 Mar 2018 13:02:47 +0300 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: Hi Rahul, Thanks, that is really helpful. So my intuition was correct. I think the naming here is a bit unfortunate because unless you're already familiar with Cmm, when you see this: INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) return (/* no return values */) { return (ptr); } you will be _very_ confused. Ömer 2018-03-19 3:53 GMT+03:00 Rahul Muttineni : > Hi Omer, > > An INFO_TABLE_RET is a frame that "can be returned to" and the return > keyword allows you to provide a name for the value(s) that was(were) > returned to this frame and do something with it if you wish. If you didn't > have this keyword, you would have to do low-level stack manipulations > yourself to get a handle on the return value and it's easy to mess up. > > You can think of INFO_TABLE_RET as a traditional stack frame in languages > like C, except it's powerful because you can specify custom logic on how you > deal with the returned value. In some cases, like stg_atomically_frame, you > may not even return the value further down into the stack until certain > conditions are met (the transaction is valid). > > Hope that helps, > Rahul > > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan > wrote: >> >> Hi, >> >> I'm trying to understand what a "return" list in INFO_TABLE_RET >> declaration >> line specifies. As far as I understand a "return" in the declaration line >> is >> something different than a "return" in the body. For example, in this >> definition: (in HeapStackCheck.cmm) >> >> INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) >> return (/* no return values */) >> { >> return (ptr); >> } >> >> The return list is empty and it even says "no return values" explicitly, >> yet it >> returns something. >> >> My guess is that the "return" list in the header is actually for >> arguments. I >> found this info table which has an argument: (in StgMiscClosures.cmm) >> >> INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ >> cccs) >> return (P_ ret) >> { >> unwind Sp = Sp + WDS(2); >> #if defined(PROFILING) >> CCCS = cccs; >> #endif >> jump stg_ap_0_fast(ret); >> } >> >> This is the use site: (in Interpreter.c) >> >> #if defined(PROFILING) >> // restore the CCCS after evaluating the closure >> Sp_subW(2); >> SpW(1) = (W_)cap->r.rCCCS; >> SpW(0) = (W_)&stg_restore_cccs_eval_info; >> #endif >> Sp_subW(2); >> SpW(1) = (W_)tagged_obj; >> SpW(0) = (W_)&stg_enter_info; >> RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); >> >> If I understand this correctly, the "tagged_obj" code will put the return >> value >> in R1, pop the stack (which will have stg_restore_ccs_eval_info at the >> bottom) >> and jump to this the info table code shown above. So `P_ ret` is the value >> of >> `tagged_obj`, and the "return" list is actually for parameters. >> >> Did I get this right? If I did, I'm curious why it's called "return" and >> not >> "args" or something like that. >> >> Thanks, >> >> Ömer >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Rahul Muttineni From simonpj at microsoft.com Mon Mar 19 10:15:03 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Mar 2018 10:15:03 +0000 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: It'd be good to document this clearly somewhere; and explain how it is used. So that the next time someone wonders, they don't have to reproduce Omer's journey Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 19 March 2018 10:03 | To: Rahul Muttineni | Cc: ghc-devs | Subject: Re: What does "return" keyword mean in INFO_TABLE_RET | declarations? | | Hi Rahul, | | Thanks, that is really helpful. | | So my intuition was correct. I think the naming here is a bit | unfortunate because unless you're already familiar with Cmm, when you | see this: | | INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) | return (/* no return values */) | { | return (ptr); | } | | you will be _very_ confused. | | Ömer | | 2018-03-19 3:53 GMT+03:00 Rahul Muttineni : | > Hi Omer, | > | > An INFO_TABLE_RET is a frame that "can be returned to" and the | return | > keyword allows you to provide a name for the value(s) that was(were) | > returned to this frame and do something with it if you wish. If you | > didn't have this keyword, you would have to do low-level stack | > manipulations yourself to get a handle on the return value and it's | easy to mess up. | > | > You can think of INFO_TABLE_RET as a traditional stack frame in | > languages like C, except it's powerful because you can specify | custom | > logic on how you deal with the returned value. In some cases, like | > stg_atomically_frame, you may not even return the value further down | > into the stack until certain conditions are met (the transaction is | valid). | > | > Hope that helps, | > Rahul | > | > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan | > | > wrote: | >> | >> Hi, | >> | >> I'm trying to understand what a "return" list in INFO_TABLE_RET | >> declaration line specifies. As far as I understand a "return" in | the | >> declaration line is something different than a "return" in the | body. | >> For example, in this | >> definition: (in HeapStackCheck.cmm) | >> | >> INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) | >> return (/* no return values */) | >> { | >> return (ptr); | >> } | >> | >> The return list is empty and it even says "no return values" | >> explicitly, yet it returns something. | >> | >> My guess is that the "return" list in the header is actually for | >> arguments. I found this info table which has an argument: (in | >> StgMiscClosures.cmm) | >> | >> INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, | W_ | >> cccs) | >> return (P_ ret) | >> { | >> unwind Sp = Sp + WDS(2); | >> #if defined(PROFILING) | >> CCCS = cccs; | >> #endif | >> jump stg_ap_0_fast(ret); | >> } | >> | >> This is the use site: (in Interpreter.c) | >> | >> #if defined(PROFILING) | >> // restore the CCCS after evaluating the closure | >> Sp_subW(2); | >> SpW(1) = (W_)cap->r.rCCCS; | >> SpW(0) = (W_)&stg_restore_cccs_eval_info; | >> #endif | >> Sp_subW(2); | >> SpW(1) = (W_)tagged_obj; | >> SpW(0) = (W_)&stg_enter_info; | >> RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); | >> | >> If I understand this correctly, the "tagged_obj" code will put the | >> return value in R1, pop the stack (which will have | >> stg_restore_ccs_eval_info at the | >> bottom) | >> and jump to this the info table code shown above. So `P_ ret` is | the | >> value of `tagged_obj`, and the "return" list is actually for | >> parameters. | >> | >> Did I get this right? If I did, I'm curious why it's called | "return" | >> and not "args" or something like that. | >> | >> Thanks, | >> | >> Ömer | >> _______________________________________________ | >> 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=04%7C01%7C | >> | simonpj%40microsoft.com%7Cb990019591bd43f5ba2508d58d80b93d%7C72f988bf | >> | 86f141af91ab2d7cd011db47%7C1%7C0%7C636570506392775790%7CUnknown%7CTWF | >> | pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D | >> %7C- | 1&sdata=ULVGoJr6gEijZOI7uQCLJ9JR4xS6SoNGPo5sIvGff50%3D&reserved=0 | > | > | > | > | > -- | > Rahul Muttineni | _______________________________________________ | 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=04%7C01%7Csimonpj%40microsoft.com%7Cb990019591bd43f5ba2508d5 | 8d80b93d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365705063927858 | 00%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | 6Ik1haWwifQ%3D%3D%7C- | 1&sdata=sEL63DuafSAYG0GgGcu30qdU22xkmnq5XLNJVKFlNtA%3D&reserved=0 From simonpj at microsoft.com Mon Mar 19 11:32:22 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Mar 2018 11:32:22 +0000 Subject: ghcpkg05 Message-ID: On my Linux platform, with an in-place build, I get a consistent failure of ghcpkg05. Any ideas how I can fix it? Thanks Simon =====> ghcpkg05(normal) 1 of 1 [0, 0, 0] cd "./ghcpkg05.run" && $MAKE -s --no-print-directory ghcpkg05 Actual stderr output differs from expected: diff -uw "./ghcpkg05.run/ghcpkg05.stderr.normalised" "./ghcpkg05.run/ghcpkg05.run.stderr.normalised" --- ./ghcpkg05.run/ghcpkg05.stderr.normalised 2018-03-19 11:31:12.533918366 +0000 +++ ./ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-03-19 11:31:12.533918366 +0000 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX-ghc.so","libtestpkg-2.0-XXX-ghc.dylib","testpkg-2.0-XXX-ghc.dll"] on library path +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/haskeline/dist-install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/text/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/containers/dist-install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /5playpen/simonpj/HEAD-1/libraries/bytestring/dist-install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) Unexpected results from: TEST="ghcpkg05" -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 19 13:29:42 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Mar 2018 13:29:42 +0000 Subject: Haskell Report 2010: pattern bindings Message-ID: Thanks Jose. The other issue I have in mind is that of pattern bindings. Currently in the 2010 Haskell Report * The text on the monomorphism restriction (4.5.5) refers to “simple pattern bindings”. * It claims that a simple pattern binding “is a pattern binding in which the pattern consists of a single variable” * You’d expect “simple pattern binding” to be defined in 3.17.1 Patterns. But it isn’t. * Instead, 4.4.3.2 Pattern bindings explicitly contradicts 4.5.5 by saying “a simple pattern binding has form p=e”. What a mess! The simplest way out is probably: * Define “simple pattern binding” to be of form x=e, in 3.17.1. * Fix the first para of 4.4.3.2. * Fix the cross-ref in 4.5.5 to refer to the definition of simple pattern. Sadly, 4.4.3.2 still is not very well defined. It’s supposed to say what pattern bindings mean, including top-level ones; but it does so by referring to 3.12 which does not handle top-level bindings. I’m not sure if this is worth fixing. Simon From: José Manuel Calderón Trilla Sent: 15 March 2018 23:17 To: Simon Peyton Jones ; haskell-prime at haskell.org; ghc-devs at haskell.org Subject: Re: [Haskell] The Haskell Report: who maintains it? All of us on the Haskell Language Committee have the ability to commit on that repo. I think typos are uncontroversial and I'll happily merge pull requests like that. I think the pull-request you point out suffered from the bystander effect, unfortunately. I'll review and merge it now. If you let me know the typo you'd like fixed I'll make sure that gets done as well. Cheers, José Manuel On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote: Friends Does anyone know who, if anyone, feels responsible for committing updates to the Haskell 2010 Report? Who even has commit rights? There’s Frank’s pull request below, and I have another important typo to fix. Thanks Simon From: Frank Steffahn [mailto:notifications at github.com] Sent: 11 March 2018 17:03 To: haskell/haskell-report Cc: Subscribed Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4) Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / mistake. I’m not 100% sure if this is the right branch (or even in general the right place) to note this, but I hope it will get fixed ;-) This seems like it is an artifact of copy-and-pasting from “Semantics of Case Expressions, Part 1 (c)” without properly adapting the thing, especially in commit bc94554. ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/haskell/haskell-report/pull/4 Commit Summary * Fix a typo in: Semantics of Case Expressions, Part 3 (s) File Changes * M report/exps.verb (1) Patch Links: * https://github.com/haskell/haskell-report/pull/4.patch * https://github.com/haskell/haskell-report/pull/4.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread. _______________________________________________ Haskell mailing list Haskell at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 332 bytes Desc: image001.jpg URL: From ben at smart-cactus.org Mon Mar 19 15:27:22 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 19 Mar 2018 11:27:22 -0400 Subject: ghcpkg05 In-Reply-To: References: Message-ID: <878taoxezu.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > On my Linux platform, with an in-place build, I get a consistent failure of ghcpkg05. Hmm, interesting. I've seen this before but it seemingly vanished before I was able to identify the cause. Does /5playpen/simonpj/HEAD-1/compiler/stage2/build/utils exist? 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 asiamgenius at gmail.com Mon Mar 19 15:53:48 2018 From: asiamgenius at gmail.com (Abhiroop Sarkar) Date: Mon, 19 Mar 2018 15:53:48 +0000 Subject: Viewing the types declared in GHC.Prim in local machine Message-ID: Is it possible to view the types generated in the GHC.Prim module on my local machine? The commentary[1] states that it is a virtual module and a source file including dummy declarations are available in this location: ` libraries/base/GHC/Prim.hs`, however, upon downloading and building the latest GHC codebase I could not find this dummy file on my machine. Do I have to modify my Makefile somehow to generate these dummy types? For building, I have followed the instructions mentioned here[2] and set `BuildFlavour = devel2`. Thanks, Abhiroop Sarkar [1]https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps [2]https://ghc.haskell.org/trac/ghc/wiki/Newcomers -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Mar 19 16:59:41 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 19 Mar 2018 12:59:41 -0400 Subject: Viewing the types declared in GHC.Prim in local machine In-Reply-To: References: Message-ID: I don't think Prim.hs exists (anymore). Depending on how you installed GHC, you might have the Haddock doc files locally, which includes Prim. Or, you can :browse GHC.Prim in GHCi. Or, you can look at compiler/prelude/primops.txt.pp which generates the term-level definitions in Prim. Or, you can look at compiler/prelude/TysPrim.hs which "generates" the type-level definitions in Prim. I hope this helps! Richard > On Mar 19, 2018, at 11:53 AM, Abhiroop Sarkar wrote: > > Is it possible to view the types generated in the GHC.Prim module on my local machine? > > The commentary[1] states that it is a virtual module and a source file including dummy declarations are available in this location: `libraries/base/GHC/Prim.hs`, however, upon downloading and building the latest GHC codebase I could not find this dummy file on my machine. Do I have to modify my Makefile somehow to generate these dummy types? > > For building, I have followed the instructions mentioned here[2] and set `BuildFlavour = devel2`. > > Thanks, > Abhiroop Sarkar > > [1]https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps > [2]https://ghc.haskell.org/trac/ghc/wiki/Newcomers > > _______________________________________________ > 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 Mar 19 17:04:59 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 19 Mar 2018 13:04:59 -0400 Subject: Viewing the types declared in GHC.Prim in local machine In-Reply-To: References: Message-ID: <87sh8wvvwp.fsf@smart-cactus.org> Abhiroop Sarkar writes: > Is it possible to view the types generated in the GHC.Prim module on my > local machine? > > The commentary[1] states that it is a virtual module and a source file > including dummy declarations are available in this location: ` > libraries/base/GHC/Prim.hs`, however, upon downloading and building the > latest GHC codebase I could not find this dummy file on my machine. Do I > have to modify my Makefile somehow to generate these dummy types? > Indeed GHC.Prim is no longer exposed by `base`; it's now in the `ghc-prim` library. If you have built the compiler you should find the module generated for Haddock in libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs. I've updated the commentary to reflect this new location. You can also use the :browse GHCi command to dump the module's declarations. 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 marlowsd at gmail.com Mon Mar 19 18:50:27 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 19 Mar 2018 18:50:27 +0000 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: On 19 March 2018 at 00:53, Rahul Muttineni wrote: > Hi Omer, > > An INFO_TABLE_RET is a frame that "can be returned to" and the return > keyword allows you to provide a name for the value(s) that was(were) > returned to this frame and do something with it if you wish. If you didn't > have this keyword, you would have to do low-level stack manipulations > yourself to get a handle on the return value and it's easy to mess up. > > You can think of INFO_TABLE_RET as a traditional stack frame in languages > like C, except it's powerful because you can specify custom logic on how > you deal with the returned value. In some cases, like stg_atomically_frame, > you may not even return the value further down into the stack until certain > conditions are met (the transaction is valid). > This is correct. The "documentation" for this is in the CmmParse.y module: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165 It wouldn't hurt to move all that to the wiki and leave a link behind, if anyone wants to do that. Cheers Simon > Hope that helps, > Rahul > > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan > wrote: > >> Hi, >> >> I'm trying to understand what a "return" list in INFO_TABLE_RET >> declaration >> line specifies. As far as I understand a "return" in the declaration line >> is >> something different than a "return" in the body. For example, in this >> definition: (in HeapStackCheck.cmm) >> >> INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) >> return (/* no return values */) >> { >> return (ptr); >> } >> >> The return list is empty and it even says "no return values" explicitly, >> yet it >> returns something. >> >> My guess is that the "return" list in the header is actually for >> arguments. I >> found this info table which has an argument: (in StgMiscClosures.cmm) >> >> INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ >> cccs) >> return (P_ ret) >> { >> unwind Sp = Sp + WDS(2); >> #if defined(PROFILING) >> CCCS = cccs; >> #endif >> jump stg_ap_0_fast(ret); >> } >> >> This is the use site: (in Interpreter.c) >> >> #if defined(PROFILING) >> // restore the CCCS after evaluating the closure >> Sp_subW(2); >> SpW(1) = (W_)cap->r.rCCCS; >> SpW(0) = (W_)&stg_restore_cccs_eval_info; >> #endif >> Sp_subW(2); >> SpW(1) = (W_)tagged_obj; >> SpW(0) = (W_)&stg_enter_info; >> RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); >> >> If I understand this correctly, the "tagged_obj" code will put the return >> value >> in R1, pop the stack (which will have stg_restore_ccs_eval_info at the >> bottom) >> and jump to this the info table code shown above. So `P_ ret` is the >> value of >> `tagged_obj`, and the "return" list is actually for parameters. >> >> Did I get this right? If I did, I'm curious why it's called "return" and >> not >> "args" or something like that. >> >> Thanks, >> >> Ömer >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Rahul Muttineni > > _______________________________________________ > 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 Tue Mar 20 09:16:58 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Mar 2018 09:16:58 +0000 Subject: ghcpkg05 In-Reply-To: <878taoxezu.fsf@smart-cactus.org> References: <878taoxezu.fsf@smart-cactus.org> Message-ID: | Hmm, interesting. I've seen this before but it seemingly vanished | before I was able to identify the cause. Does /5playpen/simonpj/HEAD- | 1/compiler/stage2/build/utils exist? No, it does not. Should it? Simon | -----Original Message----- | From: Ben Gamari | Sent: 19 March 2018 15:27 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: ghcpkg05 | | Simon Peyton Jones via ghc-devs writes: | | > On my Linux platform, with an in-place build, I get a consistent | failure of ghcpkg05. | | Hmm, interesting. I've seen this before but it seemingly vanished | before I was able to identify the cause. Does /5playpen/simonpj/HEAD- | 1/compiler/stage2/build/utils exist? | | Cheers, | | - Ben From simonpj at microsoft.com Tue Mar 20 09:57:59 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Mar 2018 09:57:59 +0000 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: It’s fine where it is, provided it takes the form of Note [Stack frames] and that Note is referred to from relevant places elsewhere. E.g. Omer didn’t find it. One plausible place to point to it is the very definition site of INFO_TABLE_RET, wherever that is. Simon From: ghc-devs On Behalf Of Simon Marlow Sent: 19 March 2018 18:50 To: Rahul Muttineni Cc: ghc-devs Subject: Re: What does "return" keyword mean in INFO_TABLE_RET declarations? On 19 March 2018 at 00:53, Rahul Muttineni > wrote: Hi Omer, An INFO_TABLE_RET is a frame that "can be returned to" and the return keyword allows you to provide a name for the value(s) that was(were) returned to this frame and do something with it if you wish. If you didn't have this keyword, you would have to do low-level stack manipulations yourself to get a handle on the return value and it's easy to mess up. You can think of INFO_TABLE_RET as a traditional stack frame in languages like C, except it's powerful because you can specify custom logic on how you deal with the returned value. In some cases, like stg_atomically_frame, you may not even return the value further down into the stack until certain conditions are met (the transaction is valid). This is correct. The "documentation" for this is in the CmmParse.y module: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165 It wouldn't hurt to move all that to the wiki and leave a link behind, if anyone wants to do that. Cheers Simon Hope that helps, Rahul On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan > wrote: Hi, I'm trying to understand what a "return" list in INFO_TABLE_RET declaration line specifies. As far as I understand a "return" in the declaration line is something different than a "return" in the body. For example, in this definition: (in HeapStackCheck.cmm) INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) return (/* no return values */) { return (ptr); } The return list is empty and it even says "no return values" explicitly, yet it returns something. My guess is that the "return" list in the header is actually for arguments. I found this info table which has an argument: (in StgMiscClosures.cmm) INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs) return (P_ ret) { unwind Sp = Sp + WDS(2); #if defined(PROFILING) CCCS = cccs; #endif jump stg_ap_0_fast(ret); } This is the use site: (in Interpreter.c) #if defined(PROFILING) // restore the CCCS after evaluating the closure Sp_subW(2); SpW(1) = (W_)cap->r.rCCCS; SpW(0) = (W_)&stg_restore_cccs_eval_info; #endif Sp_subW(2); SpW(1) = (W_)tagged_obj; SpW(0) = (W_)&stg_enter_info; RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); If I understand this correctly, the "tagged_obj" code will put the return value in R1, pop the stack (which will have stg_restore_ccs_eval_info at the bottom) and jump to this the info table code shown above. So `P_ ret` is the value of `tagged_obj`, and the "return" list is actually for parameters. Did I get this right? If I did, I'm curious why it's called "return" and not "args" or something like that. Thanks, Ömer _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Rahul Muttineni _______________________________________________ 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 omeragacan at gmail.com Tue Mar 20 13:05:25 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Mar 2018 16:05:25 +0300 Subject: Question about indirectees of BLACKHOLE closures Message-ID: Hi, I've been looking at BLACKHOLE closures and how the indirectee field is used and I have a few questions: Looking at evacuate for BLACKHOLE closures: case BLACKHOLE: { StgClosure *r; const StgInfoTable *i; r = ((StgInd*)q)->indirectee; if (GET_CLOSURE_TAG(r) == 0) { i = r->header.info; if (IS_FORWARDING_PTR(i)) { r = (StgClosure *)UN_FORWARDING_PTR(i); i = r->header.info; } if (i == &stg_TSO_info || i == &stg_WHITEHOLE_info || i == &stg_BLOCKING_QUEUE_CLEAN_info || i == &stg_BLOCKING_QUEUE_DIRTY_info) { copy(p,info,q,sizeofW(StgInd),gen_no); return; } ASSERT(i != &stg_IND_info); } q = r; *p = r; goto loop; } It seems like indirectee can be a TSO, WHITEHOLE, BLOCKING_QUEUE_CLEAN, BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it mean for a BLACKHOLE to point to a - TSO - WHITEHOLE - BLOCKING_QUEUE_CLEAN - BLOCKING_QUEUE_DIRTY Is this documented somewhere or otherwise could someone give a few pointers on where to look in the code? Secondly, I also looked at the BLACKHOLE entry code, and it seems like it has a different assumption about what can indirectee field point to: INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") (P_ node) { W_ r, info, owner, bd; P_ p, bq, msg; TICK_ENT_DYN_IND(); /* tick */ retry: p = StgInd_indirectee(node); if (GETTAG(p) != 0) { return (p); } info = StgHeader_info(p); if (info == stg_IND_info) { // This could happen, if e.g. we got a BLOCKING_QUEUE that has // just been replaced with an IND by another thread in // wakeBlockingQueue(). goto retry; } if (info == stg_TSO_info || info == stg_BLOCKING_QUEUE_CLEAN_info || info == stg_BLOCKING_QUEUE_DIRTY_info) { ("ptr" msg) = ccall allocate(MyCapability() "ptr", BYTES_TO_WDS(SIZEOF_MessageBlackHole)); SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); MessageBlackHole_tso(msg) = CurrentTSO; MessageBlackHole_bh(msg) = node; (r) = ccall messageBlackHole(MyCapability() "ptr", msg "ptr"); if (r == 0) { goto retry; } else { StgTSO_why_blocked(CurrentTSO) = BlockedOnBlackHole::I16; StgTSO_block_info(CurrentTSO) = msg; jump stg_block_blackhole(node); } } else { ENTER(p); } } The difference is, when the tag of indirectee is 0, evacuate assumes that indirectee can't point to an IND, but BLACKHOLE entry code thinks it's possible and there's even a comment about why. (I don't understand the comment yet) I'm wondering if this code is correct, and why. Again any pointers would be appreciated. Thanks, Ömer From omeragacan at gmail.com Tue Mar 20 13:08:33 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Mar 2018 16:08:33 +0300 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: I think this may be my bad. Both StgMiscClosures.cmm and Updates.cmm have this line in the header: This file is written in a subset of C--, extended with various features specific to GHC. It is compiled by GHC directly. For the syntax of .cmm files, see the parser in ghc/compiler/cmm/CmmParse.y. and CmmParse.y explains INFO_TABLE_RET: Stack Frames ------------ A stack frame is written like this: INFO_TABLE_RET ( label, FRAME_TYPE, info_ptr, field1, ..., fieldN ) return ( arg1, ..., argM ) { ... code ... } where field1 ... fieldN are the fields of the stack frame (with types) arg1...argN are the values returned to the stack frame (with types). The return values are assumed to be passed according to the NativeReturn convention. ... It's just that sometimes it's not easy to find your way in a 880kloc code base. Sorry for the noise, Ömer 2018-03-20 12:57 GMT+03:00 Simon Peyton Jones via ghc-devs : > It’s fine where it is, provided it takes the form of > > Note [Stack frames] > > and that Note is referred to from relevant places elsewhere. E.g. Omer > didn’t find it. One plausible place to point to it is the very definition > site of INFO_TABLE_RET, wherever that is. > > > > Simon > > > > From: ghc-devs On Behalf Of Simon Marlow > Sent: 19 March 2018 18:50 > To: Rahul Muttineni > Cc: ghc-devs > Subject: Re: What does "return" keyword mean in INFO_TABLE_RET declarations? > > > > On 19 March 2018 at 00:53, Rahul Muttineni wrote: > > Hi Omer, > > > > An INFO_TABLE_RET is a frame that "can be returned to" and the return > keyword allows you to provide a name for the value(s) that was(were) > returned to this frame and do something with it if you wish. If you didn't > have this keyword, you would have to do low-level stack manipulations > yourself to get a handle on the return value and it's easy to mess up. > > > > You can think of INFO_TABLE_RET as a traditional stack frame in languages > like C, except it's powerful because you can specify custom logic on how you > deal with the returned value. In some cases, like stg_atomically_frame, you > may not even return the value further down into the stack until certain > conditions are met (the transaction is valid). > > > > This is correct. The "documentation" for this is in the CmmParse.y module: > https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165 > > It wouldn't hurt to move all that to the wiki and leave a link behind, if > anyone wants to do that. > > Cheers > > Simon > > > > > > Hope that helps, > > Rahul > > > > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan > wrote: > > Hi, > > I'm trying to understand what a "return" list in INFO_TABLE_RET declaration > line specifies. As far as I understand a "return" in the declaration line is > something different than a "return" in the body. For example, in this > definition: (in HeapStackCheck.cmm) > > INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) > return (/* no return values */) > { > return (ptr); > } > > The return list is empty and it even says "no return values" explicitly, yet > it > returns something. > > My guess is that the "return" list in the header is actually for arguments. > I > found this info table which has an argument: (in StgMiscClosures.cmm) > > INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, W_ cccs) > return (P_ ret) > { > unwind Sp = Sp + WDS(2); > #if defined(PROFILING) > CCCS = cccs; > #endif > jump stg_ap_0_fast(ret); > } > > This is the use site: (in Interpreter.c) > > #if defined(PROFILING) > // restore the CCCS after evaluating the closure > Sp_subW(2); > SpW(1) = (W_)cap->r.rCCCS; > SpW(0) = (W_)&stg_restore_cccs_eval_info; > #endif > Sp_subW(2); > SpW(1) = (W_)tagged_obj; > SpW(0) = (W_)&stg_enter_info; > RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); > > If I understand this correctly, the "tagged_obj" code will put the return > value > in R1, pop the stack (which will have stg_restore_ccs_eval_info at the > bottom) > and jump to this the info table code shown above. So `P_ ret` is the value > of > `tagged_obj`, and the "return" list is actually for parameters. > > Did I get this right? If I did, I'm curious why it's called "return" and not > "args" or something like that. > > Thanks, > > Ömer > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > > Rahul Muttineni > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Tue Mar 20 13:13:13 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Mar 2018 13:13:13 +0000 Subject: What does "return" keyword mean in INFO_TABLE_RET declarations? In-Reply-To: References: Message-ID: It might help to a) make the reference more specific, et See Note [Stack frames] in CmmParse.y b) put that citation close to the relevant definitions, rather than at the head of the file. It's not easy for authors to anticipate the path that others will follow later. But /you/ now know what you didn't understand, and what would have helped you. Just add the info, in the places that would have meant you found it instantly. That'll save time for others. Simon | -----Original Message----- | From: Ömer Sinan Ağacan | Sent: 20 March 2018 13:09 | To: Simon Peyton Jones | Cc: Simon Marlow ; Rahul Muttineni | ; ghc-devs | Subject: Re: What does "return" keyword mean in INFO_TABLE_RET | declarations? | | I think this may be my bad. Both StgMiscClosures.cmm and Updates.cmm | have this line in the header: | | This file is written in a subset of C--, extended with various | features specific to GHC. It is compiled by GHC directly. For | the | syntax of .cmm files, see the parser in | ghc/compiler/cmm/CmmParse.y. | | and CmmParse.y explains INFO_TABLE_RET: | | Stack Frames | ------------ | | A stack frame is written like this: | | INFO_TABLE_RET ( label, FRAME_TYPE, info_ptr, field1, ..., fieldN | ) | return ( arg1, ..., argM ) | { | ... code ... | } | | where field1 ... fieldN are the fields of the stack frame (with | types) | arg1...argN are the values returned to the stack frame (with | types). | The return values are assumed to be passed according to the | NativeReturn convention. | | ... | | It's just that sometimes it's not easy to find your way in a 880kloc | code base. | | Sorry for the noise, | | Ömer | | 2018-03-20 12:57 GMT+03:00 Simon Peyton Jones via ghc-devs | : | > It’s fine where it is, provided it takes the form of | > | > Note [Stack frames] | > | > and that Note is referred to from relevant places elsewhere. E.g. | Omer | > didn’t find it. One plausible place to point to it is the very | definition | > site of INFO_TABLE_RET, wherever that is. | > | > | > | > Simon | > | > | > | > From: ghc-devs On Behalf Of Simon | > Marlow | > Sent: 19 March 2018 18:50 | > To: Rahul Muttineni | > Cc: ghc-devs | > Subject: Re: What does "return" keyword mean in INFO_TABLE_RET | declarations? | > | > | > | > On 19 March 2018 at 00:53, Rahul Muttineni | wrote: | > | > Hi Omer, | > | > | > | > An INFO_TABLE_RET is a frame that "can be returned to" and the | return | > keyword allows you to provide a name for the value(s) that was(were) | > returned to this frame and do something with it if you wish. If you | > didn't have this keyword, you would have to do low-level stack | > manipulations yourself to get a handle on the return value and it's | easy to mess up. | > | > | > | > You can think of INFO_TABLE_RET as a traditional stack frame in | > languages like C, except it's powerful because you can specify | custom | > logic on how you deal with the returned value. In some cases, like | > stg_atomically_frame, you may not even return the value further down | > into the stack until certain conditions are met (the transaction is | valid). | > | > | > | > This is correct. The "documentation" for this is in the CmmParse.y | module: | > | https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/c | > mm/CmmParse.y;b3b394b44e42f19ab7c23668a4008e4f728b51ba$151-165 | > | > It wouldn't hurt to move all that to the wiki and leave a link | behind, | > if anyone wants to do that. | > | > Cheers | > | > Simon | > | > | > | > | > | > Hope that helps, | > | > Rahul | > | > | > | > On Sun, Mar 18, 2018 at 8:18 PM, Ömer Sinan Ağacan | > | > wrote: | > | > Hi, | > | > I'm trying to understand what a "return" list in INFO_TABLE_RET | > declaration line specifies. As far as I understand a "return" in the | > declaration line is something different than a "return" in the body. | > For example, in this | > definition: (in HeapStackCheck.cmm) | > | > INFO_TABLE_RET ( stg_ret_p, RET_SMALL, W_ info_ptr, P_ ptr ) | > return (/* no return values */) | > { | > return (ptr); | > } | > | > The return list is empty and it even says "no return values" | > explicitly, yet it returns something. | > | > My guess is that the "return" list in the header is actually for | arguments. | > I | > found this info table which has an argument: (in | StgMiscClosures.cmm) | > | > INFO_TABLE_RET (stg_restore_cccs_eval, RET_SMALL, W_ info_ptr, | W_ cccs) | > return (P_ ret) | > { | > unwind Sp = Sp + WDS(2); | > #if defined(PROFILING) | > CCCS = cccs; | > #endif | > jump stg_ap_0_fast(ret); | > } | > | > This is the use site: (in Interpreter.c) | > | > #if defined(PROFILING) | > // restore the CCCS after evaluating the closure | > Sp_subW(2); | > SpW(1) = (W_)cap->r.rCCCS; | > SpW(0) = (W_)&stg_restore_cccs_eval_info; | > #endif | > Sp_subW(2); | > SpW(1) = (W_)tagged_obj; | > SpW(0) = (W_)&stg_enter_info; | > RETURN_TO_SCHEDULER_NO_PAUSE(ThreadRunGHC, ThreadYielding); | > | > If I understand this correctly, the "tagged_obj" code will put the | > return value in R1, pop the stack (which will have | > stg_restore_ccs_eval_info at the | > bottom) | > and jump to this the info table code shown above. So `P_ ret` is the | > value of `tagged_obj`, and the "return" list is actually for | > parameters. | > | > Did I get this right? If I did, I'm curious why it's called "return" | > and not "args" or something like that. | > | > Thanks, | > | > Ömer | > _______________________________________________ | > 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=04%7C01%7Csi | > | monpj%40microsoft.com%7Ce0440775dc534fcb0dca08d58e63c808%7C72f988bf86f | > | 141af91ab2d7cd011db47%7C1%7C0%7C636571481562185434%7CUnknown%7CTWFpbGZ | > | sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1 | > &sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=0 | > | > | > | > -- | > | > Rahul Muttineni | > | > | > _______________________________________________ | > 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=04%7C01%7Csi | > | monpj%40microsoft.com%7Ce0440775dc534fcb0dca08d58e63c808%7C72f988bf86f | > | 141af91ab2d7cd011db47%7C1%7C0%7C636571481562185434%7CUnknown%7CTWFpbGZ | > | sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1 | > &sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=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=04%7C01%7Csimonpj%40microsoft.com%7Ce0440775dc534fcb0dca08d5 | 8e63c808%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365714815621854 | 34%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | 6Ik1haWwifQ%3D%3D%7C- | 1&sdata=DzEyrLjKI2jlGBd6J%2BqUUgKfCxW9XErYlRjDDK2rcaQ%3D&reserved=0 | > From matthewtpickering at gmail.com Tue Mar 20 13:23:41 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 20 Mar 2018 13:23:41 +0000 Subject: Why does SpecConstr run far later than specialisation Message-ID: As far as I understand it, the goals of SpecConstr and specialisation are the same. One works for normal value arguments and one works for special type class dictionary arguments. However, looking at the pass order in `SimplCore`, specialisation runs very early before any major simplification but SpecConstr runs very late right at the end of the pipeline. Does anyone know the justification for this? It seems intuitively that they should work in the same way. Cheers, Matt From mail at joachim-breitner.de Tue Mar 20 13:42:16 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 20 Mar 2018 09:42:16 -0400 Subject: Why does SpecConstr run far later than specialisation In-Reply-To: References: Message-ID: <1521553336.21110.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 20.03.2018, 13:23 +0000 schrieb Matthew Pickering: > As far as I understand it, the goals of SpecConstr and specialisation > are the same. One works for > normal value arguments and one works for special type class dictionary > arguments. > > However, looking at the pass order in `SimplCore`, specialisation runs > very early before any major simplification but SpecConstr runs very > late right at the end of the pipeline. > > Does anyone know the justification for this? It seems intuitively that > they should work in the same way. Just a guess: We want the demand analyzer to run before SpecConstr, because I expect that there are many functions where both the demand analyzer are happy to do something, and SpecConstr is happy to do something, but the worker-wrapper done by DmdAnal is strictly preferable (no code duplication, for example.) But the Specializer and the demand analyzer have no overlap, and we we do want to strictness-analyzer the type-class-specialized code. But as I said, it’s just a guess. Cheers, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://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 marlowsd at gmail.com Tue Mar 20 14:58:29 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 20 Mar 2018 14:58:29 +0000 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: Hi Omer, On 20 March 2018 at 13:05, Ömer Sinan Ağacan wrote: > Hi, > > I've been looking at BLACKHOLE closures and how the indirectee field is > used > and I have a few questions: > > Looking at evacuate for BLACKHOLE closures: > > case BLACKHOLE: > { > StgClosure *r; > const StgInfoTable *i; > r = ((StgInd*)q)->indirectee; > if (GET_CLOSURE_TAG(r) == 0) { > i = r->header.info; > if (IS_FORWARDING_PTR(i)) { > r = (StgClosure *)UN_FORWARDING_PTR(i); > i = r->header.info; > } > if (i == &stg_TSO_info > || i == &stg_WHITEHOLE_info > || i == &stg_BLOCKING_QUEUE_CLEAN_info > || i == &stg_BLOCKING_QUEUE_DIRTY_info) { > copy(p,info,q,sizeofW(StgInd),gen_no); > return; > } > ASSERT(i != &stg_IND_info); > } > q = r; > *p = r; > goto loop; > } > > It seems like indirectee can be a TSO, WHITEHOLE, BLOCKING_QUEUE_CLEAN, > BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it mean > for > a BLACKHOLE to point to a > > - TSO > - WHITEHOLE > - BLOCKING_QUEUE_CLEAN > - BLOCKING_QUEUE_DIRTY > That sounds right to me. > Is this documented somewhere or otherwise could someone give a few > pointers on > where to look in the code? > Unfortunately I don't think we have good documentation for this, but you should look at the comments around messageBlackHole in Messages.c. > Secondly, I also looked at the BLACKHOLE entry code, and it seems like it > has a > different assumption about what can indirectee field point to: > > INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") > (P_ node) > { > W_ r, info, owner, bd; > P_ p, bq, msg; > > TICK_ENT_DYN_IND(); /* tick */ > > retry: > p = StgInd_indirectee(node); > if (GETTAG(p) != 0) { > return (p); > } > > info = StgHeader_info(p); > if (info == stg_IND_info) { > // This could happen, if e.g. we got a BLOCKING_QUEUE that has > // just been replaced with an IND by another thread in > // wakeBlockingQueue(). > goto retry; > } > > if (info == stg_TSO_info || > info == stg_BLOCKING_QUEUE_CLEAN_info || > info == stg_BLOCKING_QUEUE_DIRTY_info) > { > ("ptr" msg) = ccall allocate(MyCapability() "ptr", > BYTES_TO_WDS(SIZEOF_ > MessageBlackHole)); > > SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); > MessageBlackHole_tso(msg) = CurrentTSO; > MessageBlackHole_bh(msg) = node; > > (r) = ccall messageBlackHole(MyCapability() "ptr", msg "ptr"); > > if (r == 0) { > goto retry; > } else { > StgTSO_why_blocked(CurrentTSO) = BlockedOnBlackHole::I16; > StgTSO_block_info(CurrentTSO) = msg; > jump stg_block_blackhole(node); > } > } > else > { > ENTER(p); > } > } > > The difference is, when the tag of indirectee is 0, evacuate assumes that > indirectee can't point to an IND, but BLACKHOLE entry code thinks it's > possible > and there's even a comment about why. (I don't understand the comment yet) > I'm > wondering if this code is correct, and why. Again any pointers would be > appreciated. > Taking a quick look at the code, my guess is that: - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() - but when this happens, the indirectee of the BLACKHOLE will also be overwritten to point to the value At runtime a thread might see an intermediate state because these mutations are happening in another thread, so we might follow the indirectee and see the IND. But this state can't be observed by the GC, because all mutator threads have stopped at a safe point. Cheers Simon > Thanks, > > Ömer > _______________________________________________ > 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 marlowsd at gmail.com Tue Mar 20 15:27:36 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 20 Mar 2018 15:27:36 +0000 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: Added comments: https://phabricator.haskell.org/D4517 On 20 March 2018 at 14:58, Simon Marlow wrote: > Hi Omer, > > On 20 March 2018 at 13:05, Ömer Sinan Ağacan wrote: > >> Hi, >> >> I've been looking at BLACKHOLE closures and how the indirectee field is >> used >> and I have a few questions: >> >> Looking at evacuate for BLACKHOLE closures: >> >> case BLACKHOLE: >> { >> StgClosure *r; >> const StgInfoTable *i; >> r = ((StgInd*)q)->indirectee; >> if (GET_CLOSURE_TAG(r) == 0) { >> i = r->header.info; >> if (IS_FORWARDING_PTR(i)) { >> r = (StgClosure *)UN_FORWARDING_PTR(i); >> i = r->header.info; >> } >> if (i == &stg_TSO_info >> || i == &stg_WHITEHOLE_info >> || i == &stg_BLOCKING_QUEUE_CLEAN_info >> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { >> copy(p,info,q,sizeofW(StgInd),gen_no); >> return; >> } >> ASSERT(i != &stg_IND_info); >> } >> q = r; >> *p = r; >> goto loop; >> } >> >> It seems like indirectee can be a TSO, WHITEHOLE, BLOCKING_QUEUE_CLEAN, >> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it >> mean for >> a BLACKHOLE to point to a >> >> - TSO >> - WHITEHOLE >> - BLOCKING_QUEUE_CLEAN >> - BLOCKING_QUEUE_DIRTY >> > > That sounds right to me. > > >> Is this documented somewhere or otherwise could someone give a few >> pointers on >> where to look in the code? >> > > Unfortunately I don't think we have good documentation for this, but you > should look at the comments around messageBlackHole in Messages.c. > > >> Secondly, I also looked at the BLACKHOLE entry code, and it seems like it >> has a >> different assumption about what can indirectee field point to: >> >> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") >> (P_ node) >> { >> W_ r, info, owner, bd; >> P_ p, bq, msg; >> >> TICK_ENT_DYN_IND(); /* tick */ >> >> retry: >> p = StgInd_indirectee(node); >> if (GETTAG(p) != 0) { >> return (p); >> } >> >> info = StgHeader_info(p); >> if (info == stg_IND_info) { >> // This could happen, if e.g. we got a BLOCKING_QUEUE that has >> // just been replaced with an IND by another thread in >> // wakeBlockingQueue(). >> goto retry; >> } >> >> if (info == stg_TSO_info || >> info == stg_BLOCKING_QUEUE_CLEAN_info || >> info == stg_BLOCKING_QUEUE_DIRTY_info) >> { >> ("ptr" msg) = ccall allocate(MyCapability() "ptr", >> BYTES_TO_WDS(SIZEOF_MessageBl >> ackHole)); >> >> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); >> MessageBlackHole_tso(msg) = CurrentTSO; >> MessageBlackHole_bh(msg) = node; >> >> (r) = ccall messageBlackHole(MyCapability() "ptr", msg >> "ptr"); >> >> if (r == 0) { >> goto retry; >> } else { >> StgTSO_why_blocked(CurrentTSO) = BlockedOnBlackHole::I16; >> StgTSO_block_info(CurrentTSO) = msg; >> jump stg_block_blackhole(node); >> } >> } >> else >> { >> ENTER(p); >> } >> } >> >> The difference is, when the tag of indirectee is 0, evacuate assumes that >> indirectee can't point to an IND, but BLACKHOLE entry code thinks it's >> possible >> and there's even a comment about why. (I don't understand the comment >> yet) I'm >> wondering if this code is correct, and why. Again any pointers would be >> appreciated. >> > > Taking a quick look at the code, my guess is that: > - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() > - but when this happens, the indirectee of the BLACKHOLE will also be > overwritten to point to the value > > At runtime a thread might see an intermediate state because these > mutations are happening in another thread, so we might follow the > indirectee and see the IND. But this state can't be observed by the GC, > because all mutator threads have stopped at a safe point. > > Cheers > Simon > > > >> Thanks, >> >> Ömer >> _______________________________________________ >> 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 Tue Mar 20 22:03:02 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 20 Mar 2018 22:03:02 +0000 Subject: Why does SpecConstr run far later than specialisation In-Reply-To: <1521553336.21110.2.camel@joachim-breitner.de> References: <1521553336.21110.2.camel@joachim-breitner.de> Message-ID: However, looking at the pass order in `SimplCore`, specialisation runs very early before any major simplification but SpecConstr runs very late right at the end of the pipeline. Does anyone know the justification for this? Here’s my thought * Typeclass specialisation makes a specialised copy of a function in which many higher order calls (via the dictionary) are replaced with calls to known functions. That exposes LOTS of stuff to all phases of optimisation including the strictness analyser. So running it early is good. * Moreover typeclass specialisation is exposed simply by type at which we call an overloaded function, and that is apparent early. So running it early is OK. * SpecConstr just eliminates data constructor allocation and case expressions, so it is less likely to unleash a cascade of further optimisations. * Moreover, SpecConstr only works when we have f (a:b), and calls like that are more likely to be exposed after we’ve optimised the program. So do it late. All of these things are doubtless only sort-of-true. Concrete examples to the contrary would be useful. Simon -----Original Message----- From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim Breitner Sent: 20 March 2018 13:42 To: ghc-devs at haskell.org Subject: Re: Why does SpecConstr run far later than specialisation Hi, Am Dienstag, den 20.03.2018, 13:23 +0000 schrieb Matthew Pickering: > As far as I understand it, the goals of SpecConstr and specialisation > are the same. One works for normal value arguments and one works for > special type class dictionary arguments. > > However, looking at the pass order in `SimplCore`, specialisation runs > very early before any major simplification but SpecConstr runs very > late right at the end of the pipeline. > > Does anyone know the justification for this? It seems intuitively that > they should work in the same way. Just a guess: We want the demand analyzer to run before SpecConstr, because I expect that there are many functions where both the demand analyzer are happy to do something, and SpecConstr is happy to do something, but the worker-wrapper done by DmdAnal is strictly preferable (no code duplication, for example.) But the Specializer and the demand analyzer have no overlap, and we we do want to strictness-analyzer the type-class-specialized code. But as I said, it’s just a guess. Cheers, Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cff102ef484bd411807e108d58e68796c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636571501747132026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=R1t%2FW5BJeJPausEfMIfbYOgwj5qLaX5Hda4Z4LwDoJk%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Mar 22 10:26:57 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Mar 2018 10:26:57 +0000 Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance In-Reply-To: References: Message-ID: Evan That’s truly great information, thank you. Could you start a GHC ticket for it? Stuff gets lots in email, less so in tickets. The big take-away I got from your message is this: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 The bytes-allocated number has gone up a bit. (Not too surprising… the compiler is doing more.) But the productivity number is down sharply, and consistently so, which translates directly into longer compile times. Somehow, although residency is not increasing, GC time is greatly increased. We have some compiler/perf regression tests that track bytes-allocated, but not that track productivity, which is why we have noticed. It’d be good to figure out what’s gone wrong here. Maybe a change in nursery size or something stupid like that? It’d be great if someone felt up to investigating a bit Thanks for gathering this data. Simon From: Glasgow-haskell-users On Behalf Of Evan Laforge Sent: 21 March 2018 22:05 To: GHC users Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance I just upgraded from 8.0.2 to 8.4.1, and I took the opportunity to do a few informal compile time and run time tests. There's been a lot of talk about compile time regressions, so maybe these will be of interest, informal as they are. I wound up skipping 8.2.1 due to https://ghc.haskell.org/trac/ghc/ticket/13604, but I could still test with 8.2 perfectly well. Just haven't done it yet. In this context, RunTests is more code with no optimization (and -fhpc, if it matters). debug/seq and opt/seq are the same code but with no optimization and -O respectively. I found that -O2 hurt compile time but didn't improve run time, but it's been a long time so I should run that experiment again. compile times: OS X, macbook pro: RunTests 549.10s user 118.45s system 343% cpu 3:14.53 total 8.0.2 RunTests 548.71s user 117.10s system 347% cpu 3:11.78 total 8.0.2 RunTests 450.92s user 109.63s system 343% cpu 2:43.13 total 8.4.1 RunTests 445.48s user 107.99s system 341% cpu 2:42.19 total 8.4.1 debug/seq 284.47s user 55.95s system 345% cpu 1:38.58 total 8.0.2 debug/seq 283.33s user 55.27s system 343% cpu 1:38.53 total 8.0.2 debug/seq 220.92s user 50.21s system 337% cpu 1:20.32 total 8.4.1 debug/seq 218.39s user 49.20s system 345% cpu 1:17.47 total 8.4.1 opt/seq 732.63s user 70.86s system 338% cpu 3:57.30 total 8.0.2 opt/seq 735.21s user 71.48s system 327% cpu 4:06.31 total 8.0.2 opt/seq 785.12s user 65.42s system 327% cpu 4:19.84 total 8.4.1 opt/seq 765.52s user 64.01s system 321% cpu 4:18.29 total 8.4.1 Linux, PC: RunTests 781.31s user 58.21s system 363% cpu 3:50.70 total 8.0.2 RunTests 613.11s user 49.84s system 357% cpu 3:05.52 total 8.4.1 debug/seq 429.44s user 31.34s system 362% cpu 2:07.03 total 8.0.2 debug/seq 329.67s user 23.86s system 352% cpu 1:40.38 total 8.4.1 opt/seq 1277.20s user 45.85s system 358% cpu 6:08.68 total 8.0.2 opt/seq 1339.73s user 39.87s system 341% cpu 6:43.50 total 8.4.1 So it looks like non-optimized compile times have gotten significantly better since 8.0.2. However, optimized has gotten a little worse, but not much. The performance numbers are a bit more disappointing. At first it appeared that allocation went down in 8.4.1 while overall time is up significantly. However, the 8.4.1 used newer dependencies, so to try to control for those, I tested again after using a cabal freeze from the 8.4.1 test. Of course I had to remove the ghc distributed packages, like container and 'ghc' itself, but the rest of the deps should be the same. Those have the 'libs' suffix on Linux. From that, it looks like the improved memory in 8.4.1 was due to external dependencies, and in fact 8.4.1 bumped memory usage up again. Ow. In the graphs, 'score' is just the input file. 'max mb' and 'total mb' and 'prd' come from the post-run GC report, specifically '* bytes maximum residency', '* bytes allocated in the heap', and productivity fields. 'derive', 'lily' and 'perform' are just different kinds of processes. They are CPU time bracketing the specific action, after initialization, and the range is min and max over 6 runs, so no fancy criterion-like analysis. Each run is a separate process, so they should be independent. I was hoping for some gains due to the join points stuff, but it kind of looks like things get worse across the board. I don't know why productivity goes down so much, and I don't know why the effect seems so much worse on OS X. Of course the obvious next step is to see where 8.2.1 lies, but I thought I'd see if there's interest before going to the trouble. Of course, I should track down the regressions for my own purposes, but it's a bit of a daunting task. The step of reducing to a minimal example seems a lot harder for performance than for a bug! Probably some old fashioned SCC annotations await me, but that can be a long and confusing process. OS X, macbook pro: score max mb total mb prd derive lily perform ghc 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 8.0.2 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 8.4.1 bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 8.0.2 bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 8.4.1 cerucuk-punyah 138.01 10080.55 0.93 6.98~7.16 1.24~1.30 8.0.2 cerucuk-punyah 130.78 9617.35 0.68 8.91~9.22 1.57~1.68 8.4.1 hex 32.86 2120.95 0.91 0.76~0.88 0.16~0.19 8.0.2 hex 32.67 2194.82 0.66 1.09~1.16 0.28~0.30 8.4.1 p1 67.01 4039.82 0.92 2.63~2.73 0.47~0.50 8.0.2 p1 64.80 3899.85 0.68 3.35~3.43 0.58~0.59 8.4.1 viola-sonata 69.32 6083.65 0.92 2.48~2.56 2.07~2.13 0.25~0.26 8.0.2 viola-sonata 66.76 6120.26 0.68 3.32~3.43 2.90~2.93 0.32~0.34 8.4.1 Linux, PC: score max mb total mb prd derive lily perform ghc 6 79.76 3310.69 0.89 0.88~0.89 0.73~0.75 0.27~0.27 8.0.2 6 72.21 3421.45 0.90 0.87~0.87 0.72~0.79 0.28~0.28 8.0.2 libs 6 76.56 3419.05 0.77 1.16~1.17 0.87~0.93 0.33~0.33 8.4.1 bloom 69.82 2461.95 0.89 1.35~1.36 0.17~0.17 8.0.2 bloom 63.45 2554.89 0.90 1.33~1.35 0.18~0.18 8.0.2 libs bloom 67.79 2589.85 0.79 1.64~1.65 0.20~0.20 8.4.1 cerucuk-punyah 137.05 10113.41 0.94 7.44~7.50 1.31~1.33 8.0.2 cerucuk-punyah 128.09 10278.03 0.94 7.50~7.55 1.37~1.38 8.0.2 libs cerucuk-punyah 131.20 9617.22 0.84 7.35~7.40 1.49~1.50 8.4.1 hex 32.02 2096.87 0.92 0.73~0.74 0.18~0.18 8.0.2 hex 32.05 2200.30 0.91 0.73~0.80 0.19~0.19 8.0.2 libs hex 32.46 2144.22 0.83 0.89~0.90 0.20~0.20 8.4.1 p1 65.88 4054.66 0.93 2.84~2.87 0.49~0.50 8.0.2 p1 62.60 4127.68 0.94 2.83~2.92 0.51~0.51 8.0.2 libs p1 64.72 3899.72 0.81 2.80~2.81 0.54~0.55 8.4.1 viola-sonata 68.68 6086.49 0.93 2.55~2.56 2.10~2.12 0.27~0.27 8.0.2 viola-sonata 65.05 6212.57 0.93 2.52~2.55 2.07~2.16 0.28~0.28 8.0.2 libs viola-sonata 66.85 6120.15 0.83 2.91~2.92 2.48~2.51 0.30~0.31 8.4.1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Fri Mar 23 00:14:57 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 22 Mar 2018 17:14:57 -0700 Subject: ghc 8.0.2 vs 8.4.1 compilation time and performance In-Reply-To: References: Message-ID: Ok, done, I created https://ghc.haskell.org/trac/ghc/ticket/14964 But first: On Thu, Mar 22, 2018 at 3:26 AM, Simon Peyton Jones wrote: > score max mb total mb prd derive lily perform > ghc > 6 72.26 3279.22 0.88 0.79~0.84 0.70~0.74 0.31~0.33 > 8.0.2 > 6 76.63 3419.20 0.58 1.45~1.59 1.05~1.07 0.33~0.36 > 8.4.1 > > bloom 70.69 2456.14 0.89 1.32~1.36 0.15~0.16 > 8.0.2 > bloom 67.86 2589.97 0.62 1.94~1.99 0.20~0.22 > 8.4.1 > > The bytes-allocated number has gone up a bit. (Not too surprising… the > compiler is doing more.) But the productivity number is down sharply, and > consistently so, which translates directly into longer compile times. > Somehow, although residency is not increasing, GC time is greatly increased. To be clear, this is the performance of generated code, not the performance of the compiler itself. The conclusion from compiler performance was non-optimized is much faster (yay!) and optimized slightly slower. That's reasonable if it's doing more work, but somehow the more work turns into lower GC productivity in the generated code :( > It’d be good to figure out what’s gone wrong here. Maybe a change in nursery > size or something stupid like that? I don't think so, this is my own code and the invocation is the same across versions, hopefully only the compiler version has changed. I am tweaking nursery size though, here are the RTS flags: -N -A8m -T I can try testing again with no RTS flags. I realize this is a bit vague as it stands, I'll try to narrow things down. From qdunkan at gmail.com Fri Mar 23 00:20:05 2018 From: qdunkan at gmail.com (Evan Laforge) Date: Thu, 22 Mar 2018 17:20:05 -0700 Subject: 8.4.1 ghci findings Message-ID: I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference. From omeragacan at gmail.com Fri Mar 23 12:18:33 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 23 Mar 2018 15:18:33 +0300 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: Thanks Simon, that's really helpful. A few more questions: As far as I understand the difference between - BLACKHOLE pointing to a TSO - BLACKHOLE pointing to a BLOCKING_QUEUE is that in the former we don't yet have any threads blocked by the BLACKHOLE whereas in the latter we have and the blocking queue holds all those blocked threads. Did I get this right? Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we BLACKHOLE a closure when we're done evaluating it (assuming no eager blackholing), and evaluation usually happens up to WHNF. Thanks, Ömer 2018-03-20 18:27 GMT+03:00 Simon Marlow : > Added comments: https://phabricator.haskell.org/D4517 > > On 20 March 2018 at 14:58, Simon Marlow wrote: >> >> Hi Omer, >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan wrote: >>> >>> Hi, >>> >>> I've been looking at BLACKHOLE closures and how the indirectee field is >>> used >>> and I have a few questions: >>> >>> Looking at evacuate for BLACKHOLE closures: >>> >>> case BLACKHOLE: >>> { >>> StgClosure *r; >>> const StgInfoTable *i; >>> r = ((StgInd*)q)->indirectee; >>> if (GET_CLOSURE_TAG(r) == 0) { >>> i = r->header.info; >>> if (IS_FORWARDING_PTR(i)) { >>> r = (StgClosure *)UN_FORWARDING_PTR(i); >>> i = r->header.info; >>> } >>> if (i == &stg_TSO_info >>> || i == &stg_WHITEHOLE_info >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { >>> copy(p,info,q,sizeofW(StgInd),gen_no); >>> return; >>> } >>> ASSERT(i != &stg_IND_info); >>> } >>> q = r; >>> *p = r; >>> goto loop; >>> } >>> >>> It seems like indirectee can be a TSO, WHITEHOLE, BLOCKING_QUEUE_CLEAN, >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it >>> mean for >>> a BLACKHOLE to point to a >>> >>> - TSO >>> - WHITEHOLE >>> - BLOCKING_QUEUE_CLEAN >>> - BLOCKING_QUEUE_DIRTY >> >> >> That sounds right to me. >> >>> >>> Is this documented somewhere or otherwise could someone give a few >>> pointers on >>> where to look in the code? >> >> >> Unfortunately I don't think we have good documentation for this, but you >> should look at the comments around messageBlackHole in Messages.c. >> >>> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems like it >>> has a >>> different assumption about what can indirectee field point to: >>> >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") >>> (P_ node) >>> { >>> W_ r, info, owner, bd; >>> P_ p, bq, msg; >>> >>> TICK_ENT_DYN_IND(); /* tick */ >>> >>> retry: >>> p = StgInd_indirectee(node); >>> if (GETTAG(p) != 0) { >>> return (p); >>> } >>> >>> info = StgHeader_info(p); >>> if (info == stg_IND_info) { >>> // This could happen, if e.g. we got a BLOCKING_QUEUE that >>> has >>> // just been replaced with an IND by another thread in >>> // wakeBlockingQueue(). >>> goto retry; >>> } >>> >>> if (info == stg_TSO_info || >>> info == stg_BLOCKING_QUEUE_CLEAN_info || >>> info == stg_BLOCKING_QUEUE_DIRTY_info) >>> { >>> ("ptr" msg) = ccall allocate(MyCapability() "ptr", >>> >>> BYTES_TO_WDS(SIZEOF_MessageBlackHole)); >>> >>> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); >>> MessageBlackHole_tso(msg) = CurrentTSO; >>> MessageBlackHole_bh(msg) = node; >>> >>> (r) = ccall messageBlackHole(MyCapability() "ptr", msg >>> "ptr"); >>> >>> if (r == 0) { >>> goto retry; >>> } else { >>> StgTSO_why_blocked(CurrentTSO) = BlockedOnBlackHole::I16; >>> StgTSO_block_info(CurrentTSO) = msg; >>> jump stg_block_blackhole(node); >>> } >>> } >>> else >>> { >>> ENTER(p); >>> } >>> } >>> >>> The difference is, when the tag of indirectee is 0, evacuate assumes that >>> indirectee can't point to an IND, but BLACKHOLE entry code thinks it's >>> possible >>> and there's even a comment about why. (I don't understand the comment >>> yet) I'm >>> wondering if this code is correct, and why. Again any pointers would be >>> appreciated. >> >> >> Taking a quick look at the code, my guess is that: >> - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() >> - but when this happens, the indirectee of the BLACKHOLE will also be >> overwritten to point to the value >> >> At runtime a thread might see an intermediate state because these >> mutations are happening in another thread, so we might follow the indirectee >> and see the IND. But this state can't be observed by the GC, because all >> mutator threads have stopped at a safe point. >> >> Cheers >> Simon >> >> >>> >>> Thanks, >>> >>> Ömer >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > From rahulmutt at gmail.com Fri Mar 23 15:51:18 2018 From: rahulmutt at gmail.com (Rahul Muttineni) Date: Fri, 23 Mar 2018 21:21:18 +0530 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: Hi Omer, As per my understanding, a BLACKHOLE can point to a THUNK when an exception is thrown. An exception walks up the stack and overwrites the blackholes pointed to by the update frames as it walks with an stg_raise closure. That way, if any concurrent thread happens to evaluate a thunk that was walked, it'll evaluate the thunk which will blow up as well thereby throwing the exception on the other thread(s) too. Definition of stg_raise: https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e90dda2557e8/rts/Exception.cmm#L424-L427 raiseExceptionHelper dealing with update frames: https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf414db678fa72/rts/Schedule.c#L2864-L2875 In general, yes, you can think that a BLACKHOLE will point to a non-THUNK object assuming that everything went right. Hope that helps, Rahul On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan wrote: > Thanks Simon, that's really helpful. > > A few more questions: > > As far as I understand the difference between > > - BLACKHOLE pointing to a TSO > - BLACKHOLE pointing to a BLOCKING_QUEUE > > is that in the former we don't yet have any threads blocked by the > BLACKHOLE > whereas in the latter we have and the blocking queue holds all those > blocked > threads. Did I get this right? > > Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we > BLACKHOLE > a closure when we're done evaluating it (assuming no eager blackholing), > and > evaluation usually happens up to WHNF. > > Thanks, > > Ömer > > 2018-03-20 18:27 GMT+03:00 Simon Marlow : > > Added comments: https://phabricator.haskell.org/D4517 > > > > On 20 March 2018 at 14:58, Simon Marlow wrote: > >> > >> Hi Omer, > >> > >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan > wrote: > >>> > >>> Hi, > >>> > >>> I've been looking at BLACKHOLE closures and how the indirectee field is > >>> used > >>> and I have a few questions: > >>> > >>> Looking at evacuate for BLACKHOLE closures: > >>> > >>> case BLACKHOLE: > >>> { > >>> StgClosure *r; > >>> const StgInfoTable *i; > >>> r = ((StgInd*)q)->indirectee; > >>> if (GET_CLOSURE_TAG(r) == 0) { > >>> i = r->header.info; > >>> if (IS_FORWARDING_PTR(i)) { > >>> r = (StgClosure *)UN_FORWARDING_PTR(i); > >>> i = r->header.info; > >>> } > >>> if (i == &stg_TSO_info > >>> || i == &stg_WHITEHOLE_info > >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info > >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { > >>> copy(p,info,q,sizeofW(StgInd),gen_no); > >>> return; > >>> } > >>> ASSERT(i != &stg_IND_info); > >>> } > >>> q = r; > >>> *p = r; > >>> goto loop; > >>> } > >>> > >>> It seems like indirectee can be a TSO, WHITEHOLE, BLOCKING_QUEUE_CLEAN, > >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it > >>> mean for > >>> a BLACKHOLE to point to a > >>> > >>> - TSO > >>> - WHITEHOLE > >>> - BLOCKING_QUEUE_CLEAN > >>> - BLOCKING_QUEUE_DIRTY > >> > >> > >> That sounds right to me. > >> > >>> > >>> Is this documented somewhere or otherwise could someone give a few > >>> pointers on > >>> where to look in the code? > >> > >> > >> Unfortunately I don't think we have good documentation for this, but you > >> should look at the comments around messageBlackHole in Messages.c. > >> > >>> > >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems like > it > >>> has a > >>> different assumption about what can indirectee field point to: > >>> > >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") > >>> (P_ node) > >>> { > >>> W_ r, info, owner, bd; > >>> P_ p, bq, msg; > >>> > >>> TICK_ENT_DYN_IND(); /* tick */ > >>> > >>> retry: > >>> p = StgInd_indirectee(node); > >>> if (GETTAG(p) != 0) { > >>> return (p); > >>> } > >>> > >>> info = StgHeader_info(p); > >>> if (info == stg_IND_info) { > >>> // This could happen, if e.g. we got a BLOCKING_QUEUE that > >>> has > >>> // just been replaced with an IND by another thread in > >>> // wakeBlockingQueue(). > >>> goto retry; > >>> } > >>> > >>> if (info == stg_TSO_info || > >>> info == stg_BLOCKING_QUEUE_CLEAN_info || > >>> info == stg_BLOCKING_QUEUE_DIRTY_info) > >>> { > >>> ("ptr" msg) = ccall allocate(MyCapability() "ptr", > >>> > >>> BYTES_TO_WDS(SIZEOF_MessageBlackHole)); > >>> > >>> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); > >>> MessageBlackHole_tso(msg) = CurrentTSO; > >>> MessageBlackHole_bh(msg) = node; > >>> > >>> (r) = ccall messageBlackHole(MyCapability() "ptr", msg > >>> "ptr"); > >>> > >>> if (r == 0) { > >>> goto retry; > >>> } else { > >>> StgTSO_why_blocked(CurrentTSO) = > BlockedOnBlackHole::I16; > >>> StgTSO_block_info(CurrentTSO) = msg; > >>> jump stg_block_blackhole(node); > >>> } > >>> } > >>> else > >>> { > >>> ENTER(p); > >>> } > >>> } > >>> > >>> The difference is, when the tag of indirectee is 0, evacuate assumes > that > >>> indirectee can't point to an IND, but BLACKHOLE entry code thinks it's > >>> possible > >>> and there's even a comment about why. (I don't understand the comment > >>> yet) I'm > >>> wondering if this code is correct, and why. Again any pointers would be > >>> appreciated. > >> > >> > >> Taking a quick look at the code, my guess is that: > >> - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() > >> - but when this happens, the indirectee of the BLACKHOLE will also be > >> overwritten to point to the value > >> > >> At runtime a thread might see an intermediate state because these > >> mutations are happening in another thread, so we might follow the > indirectee > >> and see the IND. But this state can't be observed by the GC, because all > >> mutator threads have stopped at a safe point. > >> > >> Cheers > >> Simon > >> > >> > >>> > >>> Thanks, > >>> > >>> Ömer > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Rahul Muttineni -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Mar 23 22:20:13 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Mar 2018 22:20:13 +0000 Subject: Windows Message-ID: I've just got a new laptop (the old one's hard disk died) so I'm trying to get to the point of being able to build GHC again. I'm currently stuck here: ./configure configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180323 checking for GHC Git commit id... inferred affdea82bb70e5a912b679a169c6e9a230e4c93e checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Unknown OS msys Any ideas? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Fri Mar 23 22:54:52 2018 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Fri, 23 Mar 2018 22:54:52 +0000 Subject: Windows In-Reply-To: References: Message-ID: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> Hi Simon, You need export MSYSTEM=MINGW64 in your bash profile. Regards, Tamar From: Simon Peyton Jones via ghc-devs Sent: Friday, March 23, 2018 22:21 To: ghc-devs at haskell.org Subject: Windows I’ve just got  a new laptop (the old one’s hard disk died) so I’m trying to get to the point of being able to build GHC again. I’m currently stuck here: ./configure configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180323 checking for GHC Git commit id... inferred affdea82bb70e5a912b679a169c6e9a230e4c93e checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-msys checking host system type... x86_64-pc-msys checking target system type... x86_64-pc-msys Unknown OS msys Any ideas? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggreif at gmail.com Sat Mar 24 15:34:05 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sat, 24 Mar 2018 16:34:05 +0100 Subject: Windows In-Reply-To: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> Message-ID: Just an idea... could this hint be part of the `configure` error message? Gabor On 3/23/18, lonetiger at gmail.com wrote: > Hi Simon, > > You need > > export MSYSTEM=MINGW64 > > in your bash profile. > > Regards, > Tamar > > From: Simon Peyton Jones via ghc-devs > Sent: Friday, March 23, 2018 22:21 > To: ghc-devs at haskell.org > Subject: Windows > > I’ve just got  a new laptop (the old one’s hard disk died) so I’m trying to > get to the point of being able to build GHC again. > I’m currently stuck here: > ./configure > configure: loading site script /usr/local/etc/config.site > checking for gfind... no > checking for find... /usr/bin/find > checking for sort... /usr/bin/sort > checking for GHC version date... inferred 8.5.20180323 > checking for GHC Git commit id... inferred > affdea82bb70e5a912b679a169c6e9a230e4c93e > checking for ghc... /c/fp/HP-8.2.2/bin/ghc > checking version of ghc... 8.2.2 > GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc > checking build system type... x86_64-pc-msys > checking host system type... x86_64-pc-msys > checking target system type... x86_64-pc-msys > Unknown OS msys > Any ideas? > Thanks > Simon > > From ben at smart-cactus.org Sat Mar 24 16:41:58 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 24 Mar 2018 12:41:58 -0400 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> Message-ID: <87muyxjui7.fsf@smart-cactus.org> Gabor Greif writes: > Just an idea... > > could this hint be part of the `configure` error message? > Indeed. See D4526. 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 omeragacan at gmail.com Sat Mar 24 19:27:04 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sat, 24 Mar 2018 22:27:04 +0300 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: Hi Rahul, I'm still confused. The code that walks the stack and updates UPDATE_FRAMEs only makes indirections point to the "raise" closure, not to thunks or anything else (I also don't understand why this is needed but I guess that's another topic). I still don't see how can a BLACKHOLE point to a THUNK. Ömer 2018-03-23 18:51 GMT+03:00 Rahul Muttineni : > Hi Omer, > > As per my understanding, a BLACKHOLE can point to a THUNK when an exception > is thrown. An exception walks up the stack and overwrites the blackholes > pointed to by the update frames as it walks with an stg_raise closure. That > way, if any concurrent thread happens to evaluate a thunk that was walked, > it'll evaluate the thunk which will blow up as well thereby throwing the > exception on the other thread(s) too. > > Definition of stg_raise: > https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e90dda2557e8/rts/Exception.cmm#L424-L427 > > raiseExceptionHelper dealing with update frames: > https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf414db678fa72/rts/Schedule.c#L2864-L2875 > > In general, yes, you can think that a BLACKHOLE will point to a non-THUNK > object assuming that everything went right. > > Hope that helps, > Rahul > > On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan > wrote: >> >> Thanks Simon, that's really helpful. >> >> A few more questions: >> >> As far as I understand the difference between >> >> - BLACKHOLE pointing to a TSO >> - BLACKHOLE pointing to a BLOCKING_QUEUE >> >> is that in the former we don't yet have any threads blocked by the >> BLACKHOLE >> whereas in the latter we have and the blocking queue holds all those >> blocked >> threads. Did I get this right? >> >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we >> BLACKHOLE >> a closure when we're done evaluating it (assuming no eager blackholing), >> and >> evaluation usually happens up to WHNF. >> >> Thanks, >> >> Ömer >> >> 2018-03-20 18:27 GMT+03:00 Simon Marlow : >> > Added comments: https://phabricator.haskell.org/D4517 >> > >> > On 20 March 2018 at 14:58, Simon Marlow wrote: >> >> >> >> Hi Omer, >> >> >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> I've been looking at BLACKHOLE closures and how the indirectee field >> >>> is >> >>> used >> >>> and I have a few questions: >> >>> >> >>> Looking at evacuate for BLACKHOLE closures: >> >>> >> >>> case BLACKHOLE: >> >>> { >> >>> StgClosure *r; >> >>> const StgInfoTable *i; >> >>> r = ((StgInd*)q)->indirectee; >> >>> if (GET_CLOSURE_TAG(r) == 0) { >> >>> i = r->header.info; >> >>> if (IS_FORWARDING_PTR(i)) { >> >>> r = (StgClosure *)UN_FORWARDING_PTR(i); >> >>> i = r->header.info; >> >>> } >> >>> if (i == &stg_TSO_info >> >>> || i == &stg_WHITEHOLE_info >> >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info >> >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { >> >>> copy(p,info,q,sizeofW(StgInd),gen_no); >> >>> return; >> >>> } >> >>> ASSERT(i != &stg_IND_info); >> >>> } >> >>> q = r; >> >>> *p = r; >> >>> goto loop; >> >>> } >> >>> >> >>> It seems like indirectee can be a TSO, WHITEHOLE, >> >>> BLOCKING_QUEUE_CLEAN, >> >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does it >> >>> mean for >> >>> a BLACKHOLE to point to a >> >>> >> >>> - TSO >> >>> - WHITEHOLE >> >>> - BLOCKING_QUEUE_CLEAN >> >>> - BLOCKING_QUEUE_DIRTY >> >> >> >> >> >> That sounds right to me. >> >> >> >>> >> >>> Is this documented somewhere or otherwise could someone give a few >> >>> pointers on >> >>> where to look in the code? >> >> >> >> >> >> Unfortunately I don't think we have good documentation for this, but >> >> you >> >> should look at the comments around messageBlackHole in Messages.c. >> >> >> >>> >> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems like >> >>> it >> >>> has a >> >>> different assumption about what can indirectee field point to: >> >>> >> >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") >> >>> (P_ node) >> >>> { >> >>> W_ r, info, owner, bd; >> >>> P_ p, bq, msg; >> >>> >> >>> TICK_ENT_DYN_IND(); /* tick */ >> >>> >> >>> retry: >> >>> p = StgInd_indirectee(node); >> >>> if (GETTAG(p) != 0) { >> >>> return (p); >> >>> } >> >>> >> >>> info = StgHeader_info(p); >> >>> if (info == stg_IND_info) { >> >>> // This could happen, if e.g. we got a BLOCKING_QUEUE that >> >>> has >> >>> // just been replaced with an IND by another thread in >> >>> // wakeBlockingQueue(). >> >>> goto retry; >> >>> } >> >>> >> >>> if (info == stg_TSO_info || >> >>> info == stg_BLOCKING_QUEUE_CLEAN_info || >> >>> info == stg_BLOCKING_QUEUE_DIRTY_info) >> >>> { >> >>> ("ptr" msg) = ccall allocate(MyCapability() "ptr", >> >>> >> >>> BYTES_TO_WDS(SIZEOF_MessageBlackHole)); >> >>> >> >>> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); >> >>> MessageBlackHole_tso(msg) = CurrentTSO; >> >>> MessageBlackHole_bh(msg) = node; >> >>> >> >>> (r) = ccall messageBlackHole(MyCapability() "ptr", msg >> >>> "ptr"); >> >>> >> >>> if (r == 0) { >> >>> goto retry; >> >>> } else { >> >>> StgTSO_why_blocked(CurrentTSO) = >> >>> BlockedOnBlackHole::I16; >> >>> StgTSO_block_info(CurrentTSO) = msg; >> >>> jump stg_block_blackhole(node); >> >>> } >> >>> } >> >>> else >> >>> { >> >>> ENTER(p); >> >>> } >> >>> } >> >>> >> >>> The difference is, when the tag of indirectee is 0, evacuate assumes >> >>> that >> >>> indirectee can't point to an IND, but BLACKHOLE entry code thinks it's >> >>> possible >> >>> and there's even a comment about why. (I don't understand the comment >> >>> yet) I'm >> >>> wondering if this code is correct, and why. Again any pointers would >> >>> be >> >>> appreciated. >> >> >> >> >> >> Taking a quick look at the code, my guess is that: >> >> - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() >> >> - but when this happens, the indirectee of the BLACKHOLE will also be >> >> overwritten to point to the value >> >> >> >> At runtime a thread might see an intermediate state because these >> >> mutations are happening in another thread, so we might follow the >> >> indirectee >> >> and see the IND. But this state can't be observed by the GC, because >> >> all >> >> mutator threads have stopped at a safe point. >> >> >> >> Cheers >> >> Simon >> >> >> >> >> >>> >> >>> Thanks, >> >>> >> >>> Ömer >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> >> >> > >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > -- > Rahul Muttineni From allbery.b at gmail.com Sat Mar 24 20:26:25 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 24 Mar 2018 16:26:25 -0400 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: I think I can at least answer the why: we're talking about threads referring to suspended computations within a thread whose stack is being "unwound". Those computations won't be resumable after the unwind (which makes their context go away). So they have to be overwritten with something to cause the referencing threads to abort if they need the no-longer-computable results of those suspended computations. On Sat, Mar 24, 2018 at 3:27 PM, Ömer Sinan Ağacan wrote: > Hi Rahul, > > I'm still confused. The code that walks the stack and updates UPDATE_FRAMEs > only makes indirections point to the "raise" closure, not to thunks or > anything > else (I also don't understand why this is needed but I guess that's another > topic). I still don't see how can a BLACKHOLE point to a THUNK. > > Ömer > > 2018-03-23 18:51 GMT+03:00 Rahul Muttineni : > > Hi Omer, > > > > As per my understanding, a BLACKHOLE can point to a THUNK when an > exception > > is thrown. An exception walks up the stack and overwrites the blackholes > > pointed to by the update frames as it walks with an stg_raise closure. > That > > way, if any concurrent thread happens to evaluate a thunk that was > walked, > > it'll evaluate the thunk which will blow up as well thereby throwing the > > exception on the other thread(s) too. > > > > Definition of stg_raise: > > https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e9 > 0dda2557e8/rts/Exception.cmm#L424-L427 > > > > raiseExceptionHelper dealing with update frames: > > https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf41 > 4db678fa72/rts/Schedule.c#L2864-L2875 > > > > In general, yes, you can think that a BLACKHOLE will point to a non-THUNK > > object assuming that everything went right. > > > > Hope that helps, > > Rahul > > > > On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan > > > wrote: > >> > >> Thanks Simon, that's really helpful. > >> > >> A few more questions: > >> > >> As far as I understand the difference between > >> > >> - BLACKHOLE pointing to a TSO > >> - BLACKHOLE pointing to a BLOCKING_QUEUE > >> > >> is that in the former we don't yet have any threads blocked by the > >> BLACKHOLE > >> whereas in the latter we have and the blocking queue holds all those > >> blocked > >> threads. Did I get this right? > >> > >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we > >> BLACKHOLE > >> a closure when we're done evaluating it (assuming no eager blackholing), > >> and > >> evaluation usually happens up to WHNF. > >> > >> Thanks, > >> > >> Ömer > >> > >> 2018-03-20 18:27 GMT+03:00 Simon Marlow : > >> > Added comments: https://phabricator.haskell.org/D4517 > >> > > >> > On 20 March 2018 at 14:58, Simon Marlow wrote: > >> >> > >> >> Hi Omer, > >> >> > >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan > >> >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> I've been looking at BLACKHOLE closures and how the indirectee field > >> >>> is > >> >>> used > >> >>> and I have a few questions: > >> >>> > >> >>> Looking at evacuate for BLACKHOLE closures: > >> >>> > >> >>> case BLACKHOLE: > >> >>> { > >> >>> StgClosure *r; > >> >>> const StgInfoTable *i; > >> >>> r = ((StgInd*)q)->indirectee; > >> >>> if (GET_CLOSURE_TAG(r) == 0) { > >> >>> i = r->header.info; > >> >>> if (IS_FORWARDING_PTR(i)) { > >> >>> r = (StgClosure *)UN_FORWARDING_PTR(i); > >> >>> i = r->header.info; > >> >>> } > >> >>> if (i == &stg_TSO_info > >> >>> || i == &stg_WHITEHOLE_info > >> >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info > >> >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { > >> >>> copy(p,info,q,sizeofW(StgInd),gen_no); > >> >>> return; > >> >>> } > >> >>> ASSERT(i != &stg_IND_info); > >> >>> } > >> >>> q = r; > >> >>> *p = r; > >> >>> goto loop; > >> >>> } > >> >>> > >> >>> It seems like indirectee can be a TSO, WHITEHOLE, > >> >>> BLOCKING_QUEUE_CLEAN, > >> >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does > it > >> >>> mean for > >> >>> a BLACKHOLE to point to a > >> >>> > >> >>> - TSO > >> >>> - WHITEHOLE > >> >>> - BLOCKING_QUEUE_CLEAN > >> >>> - BLOCKING_QUEUE_DIRTY > >> >> > >> >> > >> >> That sounds right to me. > >> >> > >> >>> > >> >>> Is this documented somewhere or otherwise could someone give a few > >> >>> pointers on > >> >>> where to look in the code? > >> >> > >> >> > >> >> Unfortunately I don't think we have good documentation for this, but > >> >> you > >> >> should look at the comments around messageBlackHole in Messages.c. > >> >> > >> >>> > >> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems > like > >> >>> it > >> >>> has a > >> >>> different assumption about what can indirectee field point to: > >> >>> > >> >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") > >> >>> (P_ node) > >> >>> { > >> >>> W_ r, info, owner, bd; > >> >>> P_ p, bq, msg; > >> >>> > >> >>> TICK_ENT_DYN_IND(); /* tick */ > >> >>> > >> >>> retry: > >> >>> p = StgInd_indirectee(node); > >> >>> if (GETTAG(p) != 0) { > >> >>> return (p); > >> >>> } > >> >>> > >> >>> info = StgHeader_info(p); > >> >>> if (info == stg_IND_info) { > >> >>> // This could happen, if e.g. we got a BLOCKING_QUEUE > that > >> >>> has > >> >>> // just been replaced with an IND by another thread in > >> >>> // wakeBlockingQueue(). > >> >>> goto retry; > >> >>> } > >> >>> > >> >>> if (info == stg_TSO_info || > >> >>> info == stg_BLOCKING_QUEUE_CLEAN_info || > >> >>> info == stg_BLOCKING_QUEUE_DIRTY_info) > >> >>> { > >> >>> ("ptr" msg) = ccall allocate(MyCapability() "ptr", > >> >>> > >> >>> BYTES_TO_WDS(SIZEOF_MessageBlackHole)); > >> >>> > >> >>> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); > >> >>> MessageBlackHole_tso(msg) = CurrentTSO; > >> >>> MessageBlackHole_bh(msg) = node; > >> >>> > >> >>> (r) = ccall messageBlackHole(MyCapability() "ptr", msg > >> >>> "ptr"); > >> >>> > >> >>> if (r == 0) { > >> >>> goto retry; > >> >>> } else { > >> >>> StgTSO_why_blocked(CurrentTSO) = > >> >>> BlockedOnBlackHole::I16; > >> >>> StgTSO_block_info(CurrentTSO) = msg; > >> >>> jump stg_block_blackhole(node); > >> >>> } > >> >>> } > >> >>> else > >> >>> { > >> >>> ENTER(p); > >> >>> } > >> >>> } > >> >>> > >> >>> The difference is, when the tag of indirectee is 0, evacuate assumes > >> >>> that > >> >>> indirectee can't point to an IND, but BLACKHOLE entry code thinks > it's > >> >>> possible > >> >>> and there's even a comment about why. (I don't understand the > comment > >> >>> yet) I'm > >> >>> wondering if this code is correct, and why. Again any pointers would > >> >>> be > >> >>> appreciated. > >> >> > >> >> > >> >> Taking a quick look at the code, my guess is that: > >> >> - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() > >> >> - but when this happens, the indirectee of the BLACKHOLE will also be > >> >> overwritten to point to the value > >> >> > >> >> At runtime a thread might see an intermediate state because these > >> >> mutations are happening in another thread, so we might follow the > >> >> indirectee > >> >> and see the IND. But this state can't be observed by the GC, because > >> >> all > >> >> mutator threads have stopped at a safe point. > >> >> > >> >> Cheers > >> >> Simon > >> >> > >> >> > >> >>> > >> >>> Thanks, > >> >>> > >> >>> Ömer > >> >>> _______________________________________________ > >> >>> ghc-devs mailing list > >> >>> ghc-devs at haskell.org > >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> >> > >> >> > >> > > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > > > -- > > Rahul Muttineni > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Sun Mar 25 07:14:24 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 25 Mar 2018 10:14:24 +0300 Subject: Curious demand in a function parameter Message-ID: Hi, In this program {-# LANGUAGE MagicHash #-} module Lib where import Control.Exception import GHC.Exts import GHC.IO data Err = Err deriving (Show) instance Exception Err f :: Int -> Int -> IO Int f x y | x > 0 = IO (raiseIO# (toException Err)) | y > 0 = return 1 | otherwise = return 2 when I compile this with 8.4 -O2 I get a strict demand on `y`: f :: Int -> Int -> IO Int [GblId, Arity=3, Str=, ...] but clearly `y` is not used on all code paths, so I don't understand why we have a strict demand here. I found this example in the comments around `raiseIO#`: -- raiseIO# needs to be a primop, because exceptions in the IO monad -- must be *precise* - we don't want the strictness analyser turning -- one kind of bottom into another, as it is allowed to do in pure code. -- -- But we *do* want to know that it returns bottom after -- being applied to two arguments, so that this function is strict in y -- f x y | x>0 = raiseIO blah -- | y>0 = return 1 -- | otherwise = return 2 However it doesn't explain why we want be strict on `y`. Interestingly, when I try to make GHC generate a worker and a wrapper for this function to make the program fail by evaluating `y` eagerly I somehow got a lazy demand on `y`: {-# LANGUAGE MagicHash #-} module Main where import Control.Exception import GHC.Exts import GHC.IO data Err = Err deriving (Show) instance Exception Err f :: Int -> Int -> IO Int f x y | x > 0 = IO (raiseIO# (toException Err)) | y > 0 = f x (y - 1) | otherwise = f (x - 1) y main = f 1 undefined I was thinking that this program should fail with "undefined" instead of "Err", but the demand I got for `f` became: f :: Int -> Int -> IO Int [GblId, Arity=2, Str=, ...] which makes sense to me. But I don't understand how my changes can change `y`s demand, and why the original demand is strict rather than lazy. Could anyone give me some pointers? Thanks Ömer From sgraf1337 at gmail.com Sun Mar 25 20:43:38 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sun, 25 Mar 2018 22:43:38 +0200 Subject: Curious demand in a function parameter In-Reply-To: References: Message-ID: Hey, the problem is with eta-expansion in this case, I believe, or rather the lack there-of. Your recursive `f` is always bottoming out, which makes GHC not want to eta-expand the RealWorld# parameter (Note [State hack and bottoming functions] in CoreArity.hs is probably related). If you change `f`s last branch to `return 2`, it's no longer (detectably) bottoming out and you get the 'desired' behavior: test.exe: Prelude.undefined CallStack (from HasCallStack): error, called at libraries\base\GHC\Err.hs:79:14 in base:GHC.Err undefined, called at test.hs:25:7 in main:Main Greetings, Sebastian 2018-03-25 9:14 GMT+02:00 Ömer Sinan Ağacan : > Hi, > > In this program > > {-# LANGUAGE MagicHash #-} > > module Lib where > > import Control.Exception > import GHC.Exts > import GHC.IO > > data Err = Err > deriving (Show) > instance Exception Err > > f :: Int -> Int -> IO Int > f x y | x > 0 = IO (raiseIO# (toException Err)) > | y > 0 = return 1 > | otherwise = return 2 > > when I compile this with 8.4 -O2 I get a strict demand on `y`: > > f :: Int -> Int -> IO Int > [GblId, > Arity=3, > Str=, > ...] > > but clearly `y` is not used on all code paths, so I don't understand why we > have a strict demand here. > > I found this example in the comments around `raiseIO#`: > > -- raiseIO# needs to be a primop, because exceptions in the IO monad > -- must be *precise* - we don't want the strictness analyser turning > -- one kind of bottom into another, as it is allowed to do in pure > code. > -- > -- But we *do* want to know that it returns bottom after > -- being applied to two arguments, so that this function is strict in y > -- f x y | x>0 = raiseIO blah > -- | y>0 = return 1 > -- | otherwise = return 2 > > However it doesn't explain why we want be strict on `y`. > > Interestingly, when I try to make GHC generate a worker and a wrapper for > this > function to make the program fail by evaluating `y` eagerly I somehow got a > lazy demand on `y`: > > {-# LANGUAGE MagicHash #-} > > module Main where > > import Control.Exception > import GHC.Exts > import GHC.IO > > data Err = Err > deriving (Show) > instance Exception Err > > f :: Int -> Int -> IO Int > f x y | x > 0 = IO (raiseIO# (toException Err)) > | y > 0 = f x (y - 1) > | otherwise = f (x - 1) y > > main = f 1 undefined > > I was thinking that this program should fail with "undefined" instead of > "Err", > but the demand I got for `f` became: > > f :: Int -> Int -> IO Int > [GblId, > Arity=2, > Str=, > ...] > > which makes sense to me. But I don't understand how my changes can change > `y`s > demand, and why the original demand is strict rather than lazy. Could > anyone > give me some pointers? > > Thanks > > Ömer > _______________________________________________ > 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 marlowsd at gmail.com Mon Mar 26 08:06:14 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 26 Mar 2018 09:06:14 +0100 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: The raise closure is declared to be a THUNK: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/Exception.cmm;60e29dc2611f5c1a01cfd9a870841927847a7b74$424 Another example of this is when an asynchronous exception is thrown, and we update all the thunks/BLACKHOLEs pointed to by the update frames to point to new thunks (actually AP_STACK closures) representing the frozen state of evaluation of those thunks. For this, see rts/RaiseAsync.c. Cheers Simon On 24 March 2018 at 19:27, Ömer Sinan Ağacan wrote: > Hi Rahul, > > I'm still confused. The code that walks the stack and updates UPDATE_FRAMEs > only makes indirections point to the "raise" closure, not to thunks or > anything > else (I also don't understand why this is needed but I guess that's another > topic). I still don't see how can a BLACKHOLE point to a THUNK. > > Ömer > > 2018-03-23 18:51 GMT+03:00 Rahul Muttineni : > > Hi Omer, > > > > As per my understanding, a BLACKHOLE can point to a THUNK when an > exception > > is thrown. An exception walks up the stack and overwrites the blackholes > > pointed to by the update frames as it walks with an stg_raise closure. > That > > way, if any concurrent thread happens to evaluate a thunk that was > walked, > > it'll evaluate the thunk which will blow up as well thereby throwing the > > exception on the other thread(s) too. > > > > Definition of stg_raise: > > https://github.com/ghc/ghc/blob/ba5797937e575ce6119de6c07703e9 > 0dda2557e8/rts/Exception.cmm#L424-L427 > > > > raiseExceptionHelper dealing with update frames: > > https://github.com/ghc/ghc/blob/d9d463289fe20316cff12a8f0dbf41 > 4db678fa72/rts/Schedule.c#L2864-L2875 > > > > In general, yes, you can think that a BLACKHOLE will point to a non-THUNK > > object assuming that everything went right. > > > > Hope that helps, > > Rahul > > > > On Fri, Mar 23, 2018 at 5:48 PM, Ömer Sinan Ağacan > > > wrote: > >> > >> Thanks Simon, that's really helpful. > >> > >> A few more questions: > >> > >> As far as I understand the difference between > >> > >> - BLACKHOLE pointing to a TSO > >> - BLACKHOLE pointing to a BLOCKING_QUEUE > >> > >> is that in the former we don't yet have any threads blocked by the > >> BLACKHOLE > >> whereas in the latter we have and the blocking queue holds all those > >> blocked > >> threads. Did I get this right? > >> > >> Secondly, can a BLACKHOLE point to a THUNK? I'd expect no, because we > >> BLACKHOLE > >> a closure when we're done evaluating it (assuming no eager blackholing), > >> and > >> evaluation usually happens up to WHNF. > >> > >> Thanks, > >> > >> Ömer > >> > >> 2018-03-20 18:27 GMT+03:00 Simon Marlow : > >> > Added comments: https://phabricator.haskell.org/D4517 > >> > > >> > On 20 March 2018 at 14:58, Simon Marlow wrote: > >> >> > >> >> Hi Omer, > >> >> > >> >> On 20 March 2018 at 13:05, Ömer Sinan Ağacan > >> >> wrote: > >> >>> > >> >>> Hi, > >> >>> > >> >>> I've been looking at BLACKHOLE closures and how the indirectee field > >> >>> is > >> >>> used > >> >>> and I have a few questions: > >> >>> > >> >>> Looking at evacuate for BLACKHOLE closures: > >> >>> > >> >>> case BLACKHOLE: > >> >>> { > >> >>> StgClosure *r; > >> >>> const StgInfoTable *i; > >> >>> r = ((StgInd*)q)->indirectee; > >> >>> if (GET_CLOSURE_TAG(r) == 0) { > >> >>> i = r->header.info; > >> >>> if (IS_FORWARDING_PTR(i)) { > >> >>> r = (StgClosure *)UN_FORWARDING_PTR(i); > >> >>> i = r->header.info; > >> >>> } > >> >>> if (i == &stg_TSO_info > >> >>> || i == &stg_WHITEHOLE_info > >> >>> || i == &stg_BLOCKING_QUEUE_CLEAN_info > >> >>> || i == &stg_BLOCKING_QUEUE_DIRTY_info) { > >> >>> copy(p,info,q,sizeofW(StgInd),gen_no); > >> >>> return; > >> >>> } > >> >>> ASSERT(i != &stg_IND_info); > >> >>> } > >> >>> q = r; > >> >>> *p = r; > >> >>> goto loop; > >> >>> } > >> >>> > >> >>> It seems like indirectee can be a TSO, WHITEHOLE, > >> >>> BLOCKING_QUEUE_CLEAN, > >> >>> BLOCKING_QUEUE_DIRTY, and it can't be IND. I'm wondering what does > it > >> >>> mean for > >> >>> a BLACKHOLE to point to a > >> >>> > >> >>> - TSO > >> >>> - WHITEHOLE > >> >>> - BLOCKING_QUEUE_CLEAN > >> >>> - BLOCKING_QUEUE_DIRTY > >> >> > >> >> > >> >> That sounds right to me. > >> >> > >> >>> > >> >>> Is this documented somewhere or otherwise could someone give a few > >> >>> pointers on > >> >>> where to look in the code? > >> >> > >> >> > >> >> Unfortunately I don't think we have good documentation for this, but > >> >> you > >> >> should look at the comments around messageBlackHole in Messages.c. > >> >> > >> >>> > >> >>> Secondly, I also looked at the BLACKHOLE entry code, and it seems > like > >> >>> it > >> >>> has a > >> >>> different assumption about what can indirectee field point to: > >> >>> > >> >>> INFO_TABLE(stg_BLACKHOLE,1,0,BLACKHOLE,"BLACKHOLE","BLACKHOLE") > >> >>> (P_ node) > >> >>> { > >> >>> W_ r, info, owner, bd; > >> >>> P_ p, bq, msg; > >> >>> > >> >>> TICK_ENT_DYN_IND(); /* tick */ > >> >>> > >> >>> retry: > >> >>> p = StgInd_indirectee(node); > >> >>> if (GETTAG(p) != 0) { > >> >>> return (p); > >> >>> } > >> >>> > >> >>> info = StgHeader_info(p); > >> >>> if (info == stg_IND_info) { > >> >>> // This could happen, if e.g. we got a BLOCKING_QUEUE > that > >> >>> has > >> >>> // just been replaced with an IND by another thread in > >> >>> // wakeBlockingQueue(). > >> >>> goto retry; > >> >>> } > >> >>> > >> >>> if (info == stg_TSO_info || > >> >>> info == stg_BLOCKING_QUEUE_CLEAN_info || > >> >>> info == stg_BLOCKING_QUEUE_DIRTY_info) > >> >>> { > >> >>> ("ptr" msg) = ccall allocate(MyCapability() "ptr", > >> >>> > >> >>> BYTES_TO_WDS(SIZEOF_MessageBlackHole)); > >> >>> > >> >>> SET_HDR(msg, stg_MSG_BLACKHOLE_info, CCS_SYSTEM); > >> >>> MessageBlackHole_tso(msg) = CurrentTSO; > >> >>> MessageBlackHole_bh(msg) = node; > >> >>> > >> >>> (r) = ccall messageBlackHole(MyCapability() "ptr", msg > >> >>> "ptr"); > >> >>> > >> >>> if (r == 0) { > >> >>> goto retry; > >> >>> } else { > >> >>> StgTSO_why_blocked(CurrentTSO) = > >> >>> BlockedOnBlackHole::I16; > >> >>> StgTSO_block_info(CurrentTSO) = msg; > >> >>> jump stg_block_blackhole(node); > >> >>> } > >> >>> } > >> >>> else > >> >>> { > >> >>> ENTER(p); > >> >>> } > >> >>> } > >> >>> > >> >>> The difference is, when the tag of indirectee is 0, evacuate assumes > >> >>> that > >> >>> indirectee can't point to an IND, but BLACKHOLE entry code thinks > it's > >> >>> possible > >> >>> and there's even a comment about why. (I don't understand the > comment > >> >>> yet) I'm > >> >>> wondering if this code is correct, and why. Again any pointers would > >> >>> be > >> >>> appreciated. > >> >> > >> >> > >> >> Taking a quick look at the code, my guess is that: > >> >> - a BLOCKING_QUEUE gets overwritten by an IND in wakeBlockingQueue() > >> >> - but when this happens, the indirectee of the BLACKHOLE will also be > >> >> overwritten to point to the value > >> >> > >> >> At runtime a thread might see an intermediate state because these > >> >> mutations are happening in another thread, so we might follow the > >> >> indirectee > >> >> and see the IND. But this state can't be observed by the GC, because > >> >> all > >> >> mutator threads have stopped at a safe point. > >> >> > >> >> Cheers > >> >> Simon > >> >> > >> >> > >> >>> > >> >>> Thanks, > >> >>> > >> >>> Ömer > >> >>> _______________________________________________ > >> >>> ghc-devs mailing list > >> >>> ghc-devs at haskell.org > >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> >> > >> >> > >> > > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > > > -- > > Rahul Muttineni > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 26 09:34:06 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 09:34:06 +0000 Subject: Curious demand in a function parameter In-Reply-To: References: Message-ID: | but clearly `y` is not used on all code paths, so I don't understand | why we have a strict demand here. Why is f strict in y? Consider factorial n acc | n <0 = error "bad arg" | n==1 = acc | otherwise = factorial (n-1) (n*acc) Is this strict in 'acc'. GHC says "yes" because it's MUCH more efficient to be strict in 'acc'; and we don’t to the thrown off by the error case. Also, formally, is (factorial n bottom) equal to bottom? Yes, even if n<0, because error returns bottom. --------------- | Interestingly, when I try to make GHC generate a worker and a wrapper | for this function to make the program fail by evaluating `y` eagerly I | somehow got a lazy demand on `y`: That's a little more surprising to me, but as Sebastian point out you have now written a function that ALWAYS returns bottom. That's not a very interesting function! And GHC doesn't make much effort to optimise it. I have not looked into why GHC doesn't eta-expand guaranteed-bottom functions, but I bet there's a note about it. And I don't care much! Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 25 March 2018 08:14 | To: ghc-devs | Subject: Curious demand in a function parameter | | Hi, | | In this program | | {-# LANGUAGE MagicHash #-} | | module Lib where | | import Control.Exception | import GHC.Exts | import GHC.IO | | data Err = Err | deriving (Show) | instance Exception Err | | f :: Int -> Int -> IO Int | f x y | x > 0 = IO (raiseIO# (toException Err)) | | y > 0 = return 1 | | otherwise = return 2 | | when I compile this with 8.4 -O2 I get a strict demand on `y`: | | f :: Int -> Int -> IO Int | [GblId, | Arity=3, | Str=, | ...] | | but clearly `y` is not used on all code paths, so I don't understand | why we have a strict demand here. | | I found this example in the comments around `raiseIO#`: | | -- raiseIO# needs to be a primop, because exceptions in the IO | monad | -- must be *precise* - we don't want the strictness analyser | turning | -- one kind of bottom into another, as it is allowed to do in pure | code. | -- | -- But we *do* want to know that it returns bottom after | -- being applied to two arguments, so that this function is strict | in y | -- f x y | x>0 = raiseIO blah | -- | y>0 = return 1 | -- | otherwise = return 2 | | However it doesn't explain why we want be strict on `y`. | | Interestingly, when I try to make GHC generate a worker and a wrapper | for this function to make the program fail by evaluating `y` eagerly I | somehow got a lazy demand on `y`: | | {-# LANGUAGE MagicHash #-} | | module Main where | | import Control.Exception | import GHC.Exts | import GHC.IO | | data Err = Err | deriving (Show) | instance Exception Err | | f :: Int -> Int -> IO Int | f x y | x > 0 = IO (raiseIO# (toException Err)) | | y > 0 = f x (y - 1) | | otherwise = f (x - 1) y | | main = f 1 undefined | | I was thinking that this program should fail with "undefined" instead | of "Err", but the demand I got for `f` became: | | f :: Int -> Int -> IO Int | [GblId, | Arity=2, | Str=, | ...] | | which makes sense to me. But I don't understand how my changes can | change `y`s demand, and why the original demand is strict rather than | lazy. Could anyone give me some pointers? | | Thanks | | Ömer | _______________________________________________ | 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%7C79b17f4f38684f15c4a308d5 | 9220339a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365755894481854 | 06&sdata=T7ZJjz%2Bek5CFAUYtt9CmEkRLIml0OAj8yEU5fTsuFC0%3D&reserved=0 From simonpj at microsoft.com Mon Mar 26 09:46:22 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 09:46:22 +0000 Subject: Windows In-Reply-To: <87muyxjui7.fsf@smart-cactus.org> References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif ; lonetiger at gmail.com | Cc: ghc-devs at haskell.org | Subject: Re: Windows | | Gabor Greif writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - Ben From cheng.shao at tweag.io Mon Mar 26 09:58:47 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Mon, 26 Mar 2018 17:58:47 +0800 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > | -----Original Message----- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; lonetiger at gmail.com > | Cc: ghc-devs at haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - 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 simonpj at microsoft.com Mon Mar 26 10:02:48 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 10:02:48 +0000 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs > wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -----Original Message----- | From: ghc-devs > On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif >; lonetiger at gmail.com | Cc: ghc-devs at haskell.org | Subject: Re: Windows | | Gabor Greif > writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - 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 cheng.shao at tweag.io Mon Mar 26 10:07:23 2018 From: cheng.shao at tweag.io (Shao, Cheng) Date: Mon, 26 Mar 2018 18:07:23 +0800 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: Hi Simon, Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. If you have run "pacman -S" to update the MSYS2 packages before, then the old shortcuts setup by the MSYS2 installer may cease to function, and you can put a new shortcut on your desktop with that command. On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones wrote: > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > Well I just followed the Method A instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > > > Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 > -mintty" just once, after installing? Or repeatedly? Or that I should > somehow us it as my main shell? And what does that commend actually do? > > Sorry to be dense > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Shao, Cheng > *Sent:* 26 March 2018 10:59 > *To:* ghc-devs at haskell.org > *Subject:* Re: Windows > > > > Hi Simon, > > > > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > > > On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > > | -----Original Message----- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; lonetiger at gmail.com > | Cc: ghc-devs at haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - 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 simonpj at microsoft.com Mon Mar 26 10:08:53 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 10:08:53 +0000 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: One other thing. The instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows say to set PATH thus export PATH=/mingw64/bin:\$PATH But * in the installation tree I got from msys, there IS no c:/mingw64/bin. * I have a root directory c:/msys64. * Most binaries (eg bash, find) seem to be in c:/mingw64/usr/bin * But there is also c:/msys64/mingw64/bin, which (perhaps as a result of the pacman step) has lots more stuf like ar, cc, etc. All very confusing. For now I have put both c:/msys64/usr/bin and c:/msys64/mingw64/bin in my path. That seems to work, but is clearly not what the instructions say. Thanks Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs > wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -----Original Message----- | From: ghc-devs > On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif >; lonetiger at gmail.com | Cc: ghc-devs at haskell.org | Subject: Re: Windows | | Gabor Greif > writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - 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 lonetiger at gmail.com Mon Mar 26 10:09:18 2018 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Mon, 26 Mar 2018 11:09:18 +0100 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: <5ab8c6cf.89ce1c0a.c7e0a.abdc@mx.google.com> “C:\msys64\msys2_shell.cmd -mingw64 -mintty” Won’t work for you as it spawns a new process using mintty as your terminal emulator. If I remember correctly you have a setup where you use bash directly in emacs. In which case you just need To set the environment variables and add /mingw64/bin to your path. I would personally avoid the use of mintty because of how it implements pty. Lots of interactive programs don’t work Correctly under it, including ghci where we need specific hacks to work around some of it’s issues https://github.com/mintty/mintty/issues/56. From: Simon Peyton Jones via ghc-devs Sent: Monday, March 26, 2018 11:03 To: Shao, Cheng; ghc-devs at haskell.org Subject: RE: Windows If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing?  Or repeatedly?  Or that I should somehow us it as my main shell?  And what does that commend actually do? Sorry to be dense Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa         export MSYSTEM=MINGW64 Might someone do that?  I wasn't quite sure where Simon |  -----Original Message----- |  From: ghc-devs On Behalf Of Ben Gamari |  Sent: 24 March 2018 16:42 |  To: Gabor Greif ; lonetiger at gmail.com |  Cc: ghc-devs at haskell.org |  Subject: Re: Windows | |  Gabor Greif writes: | |  > Just an idea... |  > |  > could this hint be part of the `configure` error message? |  > |  Indeed. See D4526. | |  Cheers, | |  - 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 simonpj at microsoft.com Mon Mar 26 10:17:43 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 10:17:43 +0000 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. Interesting. Most shells are started by ‘make’. I think it uses the SHELL envt variable to decide what to start. Currently I have that set to * c:/msys64/usr/bin/bash Are you saying that I should put * C:\msys64\msys2_shell.cmd -mingw64 -mintty into my SHELL envt variable? (Also: I always a shell within emacs, rather that an msys window, and it uses SHELL to decide what to run.) Also: is this related to the export MSYSTEM=MINGW64 question? Thanks Simon From: ghc-devs On Behalf Of Shao, Cheng Sent: 26 March 2018 11:07 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, Running “C:\msys64\msys2_shell.cmd -mingw64 -mintty" has the same effect as clicking on the "MinGW-w64 Win64 Shell" shortcut. It is the proper way to start an mingw64 shell. If you have run "pacman -S" to update the MSYS2 packages before, then the old shortcuts setup by the MSYS2 installer may cease to function, and you can put a new shortcut on your desktop with that command. On Mon, Mar 26, 2018 at 6:02 PM, Simon Peyton Jones > wrote: If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs > On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs > wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -----Original Message----- | From: ghc-devs > On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif >; lonetiger at gmail.com | Cc: ghc-devs at haskell.org | Subject: Re: Windows | | Gabor Greif > writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - 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 simonpj at microsoft.com Mon Mar 26 10:20:15 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 10:20:15 +0000 Subject: Windows In-Reply-To: <5ab8c6cf.89ce1c0a.c7e0a.abdc@mx.google.com> References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> <5ab8c6cf.89ce1c0a.c7e0a.abdc@mx.google.com> Message-ID: I would personally avoid the use of mintty because of how it implements pty OK thanks. If I remember correctly you have a setup where you use bash directly in emacs. Correct In which case you just need To set the environment variables and add /mingw64/bin to your path. But set which envt variables to what, precisely? As I say in another email, c:/mingw64 doesn’t exist. c:/msys64 does, and c:/msys64/mingw64. Very confusing! Thanks Simon From: lonetiger at gmail.com Sent: 26 March 2018 11:09 To: Simon Peyton Jones ; Shao, Cheng ; ghc-devs at haskell.org Subject: RE: Windows “C:\msys64\msys2_shell.cmd -mingw64 -mintty” Won’t work for you as it spawns a new process using mintty as your terminal emulator. If I remember correctly you have a setup where you use bash directly in emacs. In which case you just need To set the environment variables and add /mingw64/bin to your path. I would personally avoid the use of mintty because of how it implements pty. Lots of interactive programs don’t work Correctly under it, including ghci where we need specific hacks to work around some of it’s issues https://github.com/mintty/mintty/issues/56. From: Simon Peyton Jones via ghc-devs Sent: Monday, March 26, 2018 11:03 To: Shao, Cheng; ghc-devs at haskell.org Subject: RE: Windows If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". Well I just followed the Method A instructions at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows Are you saying that I should run “C:\msys64\msys2_shell.cmd -mingw64 -mintty" just once, after installing? Or repeatedly? Or that I should somehow us it as my main shell? And what does that commend actually do? Sorry to be dense Simon From: ghc-devs > On Behalf Of Shao, Cheng Sent: 26 March 2018 10:59 To: ghc-devs at haskell.org Subject: Re: Windows Hi Simon, If the build environment is managed by an MSYS2 installation, then the MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs > wrote: Making it part of the error message would be v helpful. I have added a section to "Troubleshooting" on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows But it should really be part of the instructions higher up to sa export MSYSTEM=MINGW64 Might someone do that? I wasn't quite sure where Simon | -----Original Message----- | From: ghc-devs > On Behalf Of Ben Gamari | Sent: 24 March 2018 16:42 | To: Gabor Greif >; lonetiger at gmail.com | Cc: ghc-devs at haskell.org | Subject: Re: Windows | | Gabor Greif > writes: | | > Just an idea... | > | > could this hint be part of the `configure` error message? | > | Indeed. See D4526. | | Cheers, | | - 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 lonetiger at gmail.com Mon Mar 26 10:25:23 2018 From: lonetiger at gmail.com (Phyx) Date: Mon, 26 Mar 2018 11:25:23 +0100 Subject: Windows In-Reply-To: References: <5ab585bc.51d81c0a.d6935.3ffd@mx.google.com> <87muyxjui7.fsf@smart-cactus.org> Message-ID: On Mon, Mar 26, 2018 at 11:08 AM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > One other thing. The instructions at > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > say to set PATH thus > > > > export PATH=/mingw64/bin:\$PATH > > > > But > > - in the installation tree I got from msys, *there IS no > c:/mingw64/bin*. > - I have a root directory c:/msys64. > > These are correct, the instructions are written from the point of view of a msys2 environment and not the Windows one. So /mingw64 refers to an msys2 path not a windows path. In windows the / would indeed be interpreted to %HOMEDRIVE%/mingw64 but in msys2 this refers to what the msy2 filesystem has been mounted to. This is usually C:\msys64. Tamar at Yelow ~/ghc2> cygpath -w /mingw64/bin/ E:\msys64\mingw64\bin\ the msys2 tool cygpath converts between the two usually on demand. but you can query it for paths. What the instructions intended was for you to modify your msys2 environment, not your Windows one, as generally putting Cygwin derived programs on your global windows path is not advisable. > > - > - Most binaries (eg *bash*, *find*) seem to be in c:/mingw64/usr/bin > > Yes, any binary that is a posix port, e.g. depends on newlib crt instead of the Microsoft runtime goes into the usual /usr/bin folder. This would include core-utils, make etc. > > - > - But there is also c:/msys64/mingw64/bin, which (perhaps as a result > of the pacman step) has lots more stuf like *ar*, *cc*, etc. > > This folder is meant to contain native ports, e.g. programs that have been "ported" to work on Windows using a standard windows runtime. These have no dependencies on newlib/Cygwin. This is the distinctions between these two folders. > - > > > > All very confusing. For now I have put both c:/msys64/usr/bin and > c:/msys64/mingw64/bin in my path. That seems to work, but is clearly not > what the instructions say. > The instruction could be somewhat clearer here, but they are intended to only affect your msys2 installation, and never your global Windows system. > > > Thanks > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Shao, Cheng > *Sent:* 26 March 2018 10:59 > *To:* ghc-devs at haskell.org > *Subject:* Re: Windows > > > > Hi Simon, > > > > If the build environment is managed by an MSYS2 installation, then the > MinGW64 shell startup script automatically sets up "MSYSTEM" for you. It > can be launched like "C:\msys64\msys2_shell.cmd -mingw64 -mintty". > > > > On Mon, Mar 26, 2018 at 5:46 PM, Simon Peyton Jones via ghc-devs < > ghc-devs at haskell.org> wrote: > > Making it part of the error message would be v helpful. > > I have added a section to "Troubleshooting" on > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows > > But it should really be part of the instructions higher up to sa > export MSYSTEM=MINGW64 > > Might someone do that? I wasn't quite sure where > > Simon > > > | -----Original Message----- > | From: ghc-devs On Behalf Of Ben Gamari > | Sent: 24 March 2018 16:42 > | To: Gabor Greif ; lonetiger at gmail.com > | Cc: ghc-devs at haskell.org > | Subject: Re: Windows > | > | Gabor Greif writes: > | > | > Just an idea... > | > > | > could this hint be part of the `configure` error message? > | > > | Indeed. See D4526. > | > | Cheers, > | > | - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > 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 Mon Mar 26 14:54:07 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Mar 2018 10:54:07 -0400 Subject: Updating Phabricator Message-ID: <87bmfakhva.fsf@smart-cactus.org> Hello everyone, In around 90 minutes I will start a Phabricator upgrade. It has been a few months since the last update so it may take up 30 minutes or so. I'll send a message before starting. 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 Mon Mar 26 16:40:08 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Mar 2018 12:40:08 -0400 Subject: Updating Phabricator In-Reply-To: <87bmfakhva.fsf@smart-cactus.org> References: <87bmfakhva.fsf@smart-cactus.org> Message-ID: <874ll2kcyk.fsf@smart-cactus.org> Ben Gamari writes: > Hello everyone, > > In around 90 minutes I will start a Phabricator upgrade. It has been a > few months since the last update so it may take up 30 minutes or so. > I'll send a message before starting. > I'll begin the upgrade in about 10 minutes. 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 Mon Mar 26 17:30:05 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Mar 2018 13:30:05 -0400 Subject: Updating Phabricator In-Reply-To: <874ll2kcyk.fsf@smart-cactus.org> References: <87bmfakhva.fsf@smart-cactus.org> <874ll2kcyk.fsf@smart-cactus.org> Message-ID: <87zi2uiw2w.fsf@smart-cactus.org> Ben Gamari writes: > Ben Gamari writes: > >> Hello everyone, >> >> In around 90 minutes I will start a Phabricator upgrade. It has been a >> few months since the last update so it may take up 30 minutes or so. >> I'll send a message before starting. >> > I'll begin the upgrade in about 10 minutes. > The update is finished. As always, let me know if anything seems amiss. 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 Mon Mar 26 18:47:08 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Mar 2018 14:47:08 -0400 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: References: Message-ID: <87vadiisie.fsf@smart-cactus.org> Simon Marlow writes: > The raise closure is declared to be a THUNK: > > https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/Exception.cmm;60e29dc2611f5c1a01cfd9a870841927847a7b74$424 > > Another example of this is when an asynchronous exception is thrown, and we > update all the thunks/BLACKHOLEs pointed to by the update frames to point > to new thunks (actually AP_STACK closures) representing the frozen state of > evaluation of those thunks. For this, see rts/RaiseAsync.c. > This thread has answered a number of interesting questions. It would be a shame if these answers vanished into the abyss of the ghc-devs archives. Omer, do you think you could make sure that the discussion here is summarized in a Note (or ensure that the relevant notes reference one another, if they already exist)? 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 david at well-typed.com Mon Mar 26 22:58:56 2018 From: david at well-typed.com (David Feuer) Date: Mon, 26 Mar 2018 18:58:56 -0400 Subject: Missed beta reductions Message-ID: <20180326222349.5ED40BCFD5@haskell.org> What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David FeuerWell-Typed, LLP -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 26 23:14:07 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Mar 2018 23:14:07 +0000 Subject: Missed beta reductions In-Reply-To: <20180326222349.5ED40BCFD5@haskell.org> References: <20180326222349.5ED40BCFD5@haskell.org> Message-ID: GHC always beta-reduces. It does not always inline. For that: -ddump-inlinings Simon From: ghc-devs On Behalf Of David Feuer Sent: 26 March 2018 23:59 To: ghc-devs at haskell.org Subject: Missed beta reductions What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David Feuer Well-Typed, LLP -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Tue Mar 27 00:04:27 2018 From: david at well-typed.com (David Feuer) Date: Mon, 26 Mar 2018 20:04:27 -0400 Subject: Missed beta reductions In-Reply-To: Message-ID: <20180326232917.885FFBD003@haskell.org> Hmmm. So you think maybe it's doing something like (roughly; I don't have the exact case in front of me) (\p q -> f p (g p q)) this that ==> beta reduce let  p = this  q = thatin f p (g p q) ==> inline q let  p = thisin f p (g p that)? I tried marking the "this" in question INLINE CONLIKE [0]. Shouldn't that tell GHC that duplicating it is fine? I really want to see it for RULES. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones Date: 3/26/18 7:14 PM (GMT-05:00) To: David Feuer , ghc-devs at haskell.org Subject: RE: Missed beta reductions GHC always beta-reduces. It does not always inline.   For that: -ddump-inlinings Simon From: ghc-devs On Behalf Of David Feuer Sent: 26 March 2018 23:59 To: ghc-devs at haskell.org Subject: Missed beta reductions What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David Feuer Well-Typed, LLP -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Mar 27 07:55:02 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Mar 2018 07:55:02 +0000 Subject: Missed beta reductions In-Reply-To: <2b0e38e9-098d-404d-8218-e8d1986e07c8@DM3NAM06FT015.Eop-nam06.prod.protection.outlook.com> References: <2b0e38e9-098d-404d-8218-e8d1986e07c8@DM3NAM06FT015.Eop-nam06.prod.protection.outlook.com> Message-ID: Yes, it’s possible that he sequence you are seeing is what is happening to you. But why is that not what you want to see? What are you trying to achieve? Since this function might be applied to many different arguments, it’s probably not a good idea to do anything unconditionally… S From: David Feuer Sent: 27 March 2018 01:04 To: Simon Peyton Jones ; ghc-devs at haskell.org Subject: RE: Missed beta reductions Hmmm. So you think maybe it's doing something like (roughly; I don't have the exact case in front of me) (\p q -> f p (g p q)) this that ==> beta reduce let p = this q = that in f p (g p q) ==> inline q let p = this in f p (g p that) ? I tried marking the "this" in question INLINE CONLIKE [0]. Shouldn't that tell GHC that duplicating it is fine? I really want to see it for RULES. David Feuer Well-Typed, LLP -------- Original message -------- From: Simon Peyton Jones > Date: 3/26/18 7:14 PM (GMT-05:00) To: David Feuer >, ghc-devs at haskell.org Subject: RE: Missed beta reductions GHC always beta-reduces. It does not always inline. For that: -ddump-inlinings Simon From: ghc-devs > On Behalf Of David Feuer Sent: 26 March 2018 23:59 To: ghc-devs at haskell.org Subject: Missed beta reductions What's the best way to find spots where GHC saw a redex and choose not to beta reduce? Is there a flag for that? It could be useful when trying to figure out why rules aren't firing. David Feuer Well-Typed, LLP -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Tue Mar 27 21:28:44 2018 From: david at well-typed.com (David Feuer) Date: Tue, 27 Mar 2018 17:28:44 -0400 Subject: Missed beta reductions In-Reply-To: References: <2b0e38e9-098d-404d-8218-e8d1986e07c8@DM3NAM06FT015.Eop-nam06.prod.protection.outlook.com> Message-ID: <2423108.7ZDdrvG1Tn@squirrel> On Tuesday, March 27, 2018 7:55:02 AM EDT Simon Peyton Jones wrote: > Yes, it’s possible that he sequence you are seeing is what is happening to you. But why is that not what you want to see? What are you trying to achieve? > > Since this function might be applied to many different arguments, it’s probably not a good idea to do anything unconditionally… I gave rather poor guesses in my last message. I'm trying to get fromListN for Data.Primitive.Array to participate in list fusion. I'm rewriting to a foldr form so it can fuse with build. This is actually working. The trouble is the write-back rule, that's supposed to fire if fusion doesn't happen. That's not working, and I'm quite mystified about why. -- The basic function fromListNArray :: Int -> [a] -> Array a fromListNArray !n l = createArray n fromListN_too_short $ \mi -> let go i (x:xs) | i < n = writeArray mi i x >> go (i+1) xs | otherwise = fromListN_too_long go i [] = unless (i == n) fromListN_too_short in go 0 l {-# NOINLINE fromListNArray #-} fromListN_too_short, fromListN_too_long :: a fromListN_too_short = error "barf" fromListN_too_long = error "die" {-# NOINLINE fromListN_too_short #-} {-# NOINLINE fromListN_too_long #-} {-# RULES -- The rule to let it fuse "fromListNArray/foldr" [~1] forall n xs. fromListNArray n xs = createArray n fromListN_too_short $ \mary -> foldr (fillArray_go n mary) (fillArray_stop n) xs 0 -- The attempted write-back rule "fillArrayN/list" [1] forall n mary xs i. foldr (fillArray_go n mary) (fillArray_stop n) xs i = fillArrayN n mary xs i #-} fillArrayN :: Int -> MutableArray s a -> [a] -> Int -> ST s () fillArrayN !n !mary xs0 !i0 = go i0 xs0 where go i (x:xs) | i < n = writeArray mary i x >> go (i+1) xs | otherwise = fromListN_too_long go i [] = unless (i == n) fromListN_too_short {-# NOINLINE fillArrayN #-} fillArray_go :: Int -> MutableArray s a -> a -> (Int -> ST s ()) -> Int -> ST s () fillArray_go !n !mary = \x r i -> if i < n then writeArray mary i x >> r (i + 1) else fromListN_too_long {-# INLINE [0] fillArray_go #-} fillArray_stop :: Int -> Int -> ST s () fillArray_stop !n = \i -> unless (i == n) fromListN_too_short {-# INLINE [0] fillArray_stop #-} My test case, which has nothing to fuse with: bye :: Int -> [Int] -> Array Int bye n xs = fmap (+1) $ fromListNArray n xs The fromListNArray/foldr rule fires: Rule fired Rule: fromListNArray/foldr Module: (FL) Before: fromListNArray TyArg Int ValArg n_a6aF ValArg xs_a6aG After: (\ (@ a_a6XO) (n_a6ba :: Int) (xs_a6bb :: [a_a6XO]) -> $ (createArray n_a6ba fromListN_too_short) (\ (@ s_a6XV) (mary_a6bc :: MutableArray s_a6XV a_a6XO) -> foldr (fillArray_go n_a6ba mary_a6bc) (fillArray_stop n_a6ba) xs_a6bb (I# 0#))) n_a6aF xs_a6aG Cont: StrictArg $fApplicativeArray_$cfmap Stop[BoringCtxt] Array Int But the fromListArrayN/list rule never does. We go from bye :: Int -> [Int] -> Array Int bye = \ (n_a6aF :: Int) (xs_a6aG :: [Int]) -> case n_a6aF of wild_Xl { I# ds_d70d -> case ds_d70d of ds_X70p { __DEFAULT -> case runRW# (\ (s_i72w :: State# RealWorld) -> case newArray# ds_X70p fromListN_too_short (s_i72w `cast` ) of { (# ipv_i72X, ipv1_i72Y #) -> case ((foldr (fillArray_go wild_Xl ((MutableArray ipv1_i72Y) `cast` )) (fillArray_stop wild_Xl) xs_a6aG lvl_s7h1) `cast` ) (ipv_i72X `cast` ) of { (# ipv_i73A, ipv1_i73B #) -> unsafeFreezeArray# (ipv1_i72Y `cast` ) ipv_i73A } }) of { (# ipv_i72I, ipv1_i72J #) -> $fApplicativeArray_$cfmap lvl_s7h0 (Array ipv1_i72J) }; 0# -> case emptyArray# (##) of wild_Xd { __DEFAULT -> $fApplicativeArray_$cfmap lvl_s7h0 (Array wild_Xd) } } } to something where everything inlines except errors. From simonpj at microsoft.com Wed Mar 28 07:33:23 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 28 Mar 2018 07:33:23 +0000 Subject: Cabal trouble Message-ID: Trying to build the repro case in Trac #14208, I get this cabal install --with-ghc=/home/simonpj/5builds/ghc-8.4-branch/inplace/bin/ghc-stage2 Warning: cannot determine version of /home/simonpj/.cabal/bin/c2hs : "" Resolving dependencies... cabal: Could not resolve dependencies: trying: exceptions-0.8.3 (dependency of streamly) next goal: template-haskell (dependency of exceptions) rejecting: template-haskell-2.13.0.0/installed-2.1... (conflict: exceptions => template-haskell>=2.2 && <2.13) rejecting: template-haskell-2.12.0.0, template-haskell-2.11.1.0, template-haskell-2.11.0.0, template-haskell-2.10.0.0, template-haskell-2.9.0.0, template-haskell-2.8.0.0, template-haskell-2.7.0.0, template-haskell-2.6.0.0, template-haskell-2.5.0.0, template-haskell-2.4.0.1, template-haskell-2.4.0.0, template-haskell-2.3.0.1, template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from non-upgradeable package requires installed instance) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: template-haskell, exceptions, streamly, transformers, base This is with my in-place build of GHC-8.4 (in-place but not modified in any way). I've done a 'cabal upate'. What am I doing wrong? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at well-typed.com Wed Mar 28 11:28:19 2018 From: david at well-typed.com (David Feuer) Date: Wed, 28 Mar 2018 13:28:19 +0200 Subject: Missed beta reductions In-Reply-To: <2423108.7ZDdrvG1Tn@squirrel> Message-ID: <20180328105314.6A934BCF5F@haskell.org> I dug into this some more. My first problem was a stupid mistake: matching on Data.Foldable.foldr instead of GHC.List.foldr. That makes the write-back rule work when there's no fusion at all. However, if there's partial fusion with augment, then I actually get a problem from a failure to inline. That inlining failure strikes me as somewhat surprising. The function involved is actually a *partial application* of a one-shot function. I don't see how we could ever win much by not inlining it. I'll provide further details soon. David FeuerWell-Typed, LLP -------- Original message --------From: David Feuer Date: 3/27/18 11:28 PM (GMT+01:00) To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Missed beta reductions On Tuesday, March 27, 2018 7:55:02 AM EDT Simon Peyton Jones wrote: > Yes, it’s possible that he sequence you are seeing is what is happening to you.  But why is that not what you want to see?  What are you trying to achieve? > > Since this function might be applied to many different arguments, it’s probably not a good idea to do anything unconditionally… I gave rather poor guesses in my last message. I'm trying to get fromListN for Data.Primitive.Array to participate in list fusion. I'm rewriting to a foldr form so it can fuse with build. This is actually working. The trouble is the write-back rule, that's supposed to fire if fusion doesn't happen. That's not working, and I'm quite mystified about why. -- The basic function fromListNArray :: Int -> [a] -> Array a fromListNArray !n l =   createArray n fromListN_too_short $ \mi ->     let go i (x:xs)           | i < n = writeArray mi i x >> go (i+1) xs           | otherwise = fromListN_too_long         go i [] = unless (i == n) fromListN_too_short      in go 0 l {-# NOINLINE fromListNArray #-} fromListN_too_short, fromListN_too_long :: a fromListN_too_short = error "barf" fromListN_too_long = error "die" {-# NOINLINE fromListN_too_short #-} {-# NOINLINE fromListN_too_long #-} {-# RULES -- The rule to let it fuse "fromListNArray/foldr" [~1] forall n xs.   fromListNArray n xs = createArray n fromListN_too_short $ \mary ->     foldr (fillArray_go n mary) (fillArray_stop n) xs 0 -- The attempted write-back rule "fillArrayN/list" [1] forall n mary xs i.   foldr (fillArray_go n mary) (fillArray_stop n) xs i = fillArrayN n mary xs i #-} fillArrayN :: Int -> MutableArray s a -> [a] -> Int -> ST s () fillArrayN !n !mary xs0 !i0 = go i0 xs0   where     go i (x:xs)       | i < n = writeArray mary i x >> go (i+1) xs       | otherwise = fromListN_too_long     go i [] = unless (i == n) fromListN_too_short {-# NOINLINE fillArrayN #-} fillArray_go :: Int              -> MutableArray s a              -> a              -> (Int -> ST s ())              -> Int              -> ST s () fillArray_go !n !mary = \x r i ->   if i < n     then writeArray mary i x >> r (i + 1)     else fromListN_too_long {-# INLINE [0] fillArray_go #-} fillArray_stop :: Int -> Int -> ST s () fillArray_stop !n = \i -> unless (i == n) fromListN_too_short {-# INLINE [0] fillArray_stop #-} My test case, which has nothing to fuse with: bye :: Int -> [Int] -> Array Int bye n xs = fmap (+1) $ fromListNArray n xs The fromListNArray/foldr rule fires: Rule fired     Rule: fromListNArray/foldr     Module: (FL)     Before: fromListNArray TyArg Int ValArg n_a6aF ValArg xs_a6aG     After:  (\ (@ a_a6XO) (n_a6ba :: Int) (xs_a6bb :: [a_a6XO]) ->                $ (createArray n_a6ba fromListN_too_short)                  (\ (@ s_a6XV) (mary_a6bc :: MutableArray s_a6XV a_a6XO) ->                     foldr                       (fillArray_go n_a6ba mary_a6bc)                       (fillArray_stop n_a6ba)                       xs_a6bb                       (I# 0#)))               n_a6aF xs_a6aG     Cont:   StrictArg $fApplicativeArray_$cfmap             Stop[BoringCtxt] Array Int But the fromListArrayN/list rule never does. We go from bye :: Int -> [Int] -> Array Int bye   = \ (n_a6aF :: Int) (xs_a6aG :: [Int]) ->       case n_a6aF of wild_Xl { I# ds_d70d ->       case ds_d70d of ds_X70p {         __DEFAULT ->           case runRW#                  (\ (s_i72w :: State# RealWorld) ->                     case newArray# ds_X70p fromListN_too_short (s_i72w `cast` )                     of                     { (# ipv_i72X, ipv1_i72Y #) ->                     case ((foldr                              (fillArray_go wild_Xl ((MutableArray ipv1_i72Y) `cast` ))                              (fillArray_stop wild_Xl)                              xs_a6aG                              lvl_s7h1)                           `cast` )                            (ipv_i72X `cast` )                     of                     { (# ipv_i73A, ipv1_i73B #) ->                     unsafeFreezeArray# (ipv1_i72Y `cast` ) ipv_i73A                     }                     })           of           { (# ipv_i72I, ipv1_i72J #) ->           $fApplicativeArray_$cfmap lvl_s7h0 (Array ipv1_i72J)           };         0# ->           case emptyArray# (##) of wild_Xd { __DEFAULT ->           $fApplicativeArray_$cfmap lvl_s7h0 (Array wild_Xd)           }       }       } to something where everything inlines except errors. _______________________________________________ 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 Mar 28 14:49:35 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Mar 2018 10:49:35 -0400 Subject: Scavenging SRTs in scavenge_one Message-ID: <877epwi7bb.fsf@smart-cactus.org> Hi Simon, I'm a bit confused by scavenge_one; namely it doesn't scavenge SRTs. It appears that it is primarily used for remembered set entries but it's not at all clear why this means that we can safely ignore SRTs (e.g. in the FUN and THUNK cases). Can you shed some light on 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 alpmestan at gmail.com Wed Mar 28 23:59:21 2018 From: alpmestan at gmail.com (Alp Mestanogullari) Date: Thu, 29 Mar 2018 01:59:21 +0200 Subject: Cabal trouble In-Reply-To: References: Message-ID: Appending `--allow-newer=template-haskell` should tell cabal to ignore upper bounds on that package and consider more recent versions as well. In case the problem really just has to do with bounds and the code itself doesn't care, this should allow you to successfully build that package. You could also say `--allow-newer=exceptions:template-haskell` to ask cabal to ignore the upper bounds that the exceptions package puts on template-haskell. [1] has more to say about option. [1]: https://cabal.readthedocs.io/en/stable/nix-local-build.html#cfg-flag---allow-newer On Wed, Mar 28, 2018 at 9:33 AM, Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Trying to build the repro case in Trac #14208, I get this > > cabal install --with-ghc=/home/simonpj/5builds/ghc-8.4-branch/ > inplace/bin/ghc-stage2 > > Warning: cannot determine version of /home/simonpj/.cabal/bin/c2hs : > > "" > > Resolving dependencies... > > cabal: Could not resolve dependencies: > > trying: exceptions-0.8.3 (dependency of streamly) > > next goal: template-haskell (dependency of exceptions) > > rejecting: template-haskell-2.13.0.0/installed-2.1... (conflict: > exceptions => > > template-haskell>=2.2 && <2.13) > > rejecting: template-haskell-2.12.0.0, template-haskell-2.11.1.0, > > template-haskell-2.11.0.0, template-haskell-2.10.0.0, > > template-haskell-2.9.0.0, template-haskell-2.8.0.0, > template-haskell-2.7.0.0, > > template-haskell-2.6.0.0, template-haskell-2.5.0.0, > template-haskell-2.4.0.1, > > template-haskell-2.4.0.0, template-haskell-2.3.0.1, > template-haskell-2.3.0.0, > > template-haskell-2.2.0.0 (constraint from non-upgradeable package requires > > installed instance) > > After searching the rest of the dependency tree exhaustively, these were > the > > goals I've had most trouble fulfilling: template-haskell, exceptions, > > streamly, transformers, base > > This is with my in-place build of GHC-8.4 (in-place but not modified in > any way). I’ve done a ‘cabal upate’. > > What am I doing wrong? > > Thanks > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Alp Mestanogullari -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Mar 29 06:28:19 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 29 Mar 2018 09:28:19 +0300 Subject: Question about indirectees of BLACKHOLE closures In-Reply-To: <87vadiisie.fsf@smart-cactus.org> References: <87vadiisie.fsf@smart-cactus.org> Message-ID: I still don't understand the whole story with blackholes but I'll update the comments around the BLACKHOLE stack frame and/or wiki pages once I get a better understanding. Ömer 2018-03-26 21:47 GMT+03:00 Ben Gamari : > Simon Marlow writes: > >> The raise closure is declared to be a THUNK: >> >> https://phabricator.haskell.org/diffusion/GHC/browse/master/rts/Exception.cmm;60e29dc2611f5c1a01cfd9a870841927847a7b74$424 >> >> Another example of this is when an asynchronous exception is thrown, and we >> update all the thunks/BLACKHOLEs pointed to by the update frames to point >> to new thunks (actually AP_STACK closures) representing the frozen state of >> evaluation of those thunks. For this, see rts/RaiseAsync.c. >> > This thread has answered a number of interesting questions. It would be > a shame if these answers vanished into the abyss of the ghc-devs > archives. > > Omer, do you think you could make sure that the discussion here is > summarized in a Note (or ensure that the relevant notes reference one > another, if they already exist)? > > Cheers, > > - Ben > From v.cacciarimiraldo at uu.nl Thu Mar 29 14:16:26 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Thu, 29 Mar 2018 16:16:26 +0200 Subject: Memory usage exploding for complex pattern matching Message-ID: Dear ghc-devs, We are working on a library and came across quite high memory consumption when compiling some code (generated by TH). This memory issue seems to come from the exhaustiveness checker as we found in: https://ghc.haskell.org/trac/ghc/ticket/11163 https://ghc.haskell.org/trac/ghc/ticket/11195 We came up with a "minimal" example that at least is self contained and triggers the problem; `runghc Minimal.hs` should finish with about 5GB of RAM. Our actual non-minimal scenario runs out of memory on a 16GB RAM machine. We tried with ghc 8.4.2, 8.0.2 and 7.10.3 and ghc-HEAD; all of those showed a similar problem, although the older ghc's used less memory. Do you have any suggestions to make our code finish compiling without running out of memory? Thanks!! Victor -------------- next part -------------- A non-text attachment was scrubbed... Name: Minimal.hs Type: text/x-haskell Size: 47202 bytes Desc: Minimal.hs URL: From ben at smart-cactus.org Thu Mar 29 15:26:29 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Mar 2018 11:26:29 -0400 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: Message-ID: <87woxuhpi9.fsf@smart-cactus.org> "Victor Miraldo (UU)" writes: > Dear ghc-devs, > > We are working on a library and came across quite high memory consumption > when compiling some code (generated by TH). > > This memory issue seems to come from the exhaustiveness checker as > we found in: > https://ghc.haskell.org/trac/ghc/ticket/11163 > https://ghc.haskell.org/trac/ghc/ticket/11195 > > We came up with a "minimal" example that at least is self contained and > triggers the problem; `runghc Minimal.hs` should finish with about 5GB of RAM. > Hmm, with 8.2 I'm seeing a peak memory usage of 3.5 GB, with that peak occurring during renaming, not desugaring (when exhaustiveness checking happens). Are you certain that the exhaustiveness checker is the responsible party? 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 matthewtpickering at gmail.com Thu Mar 29 15:27:10 2018 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 29 Mar 2018 16:27:10 +0100 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: Message-ID: You can turn off the pattern match checker, is that an option? Can you post your code which shows the poor behaviour. It could be good to profile that part of GHC to see if there are any easy gains but it is known to be slow. Cheers, Matt On Thu, Mar 29, 2018 at 3:16 PM, Victor Miraldo (UU) wrote: > Dear ghc-devs, > > We are working on a library and came across quite high memory consumption > when compiling some code (generated by TH). > > This memory issue seems to come from the exhaustiveness checker as > we found in: > https://ghc.haskell.org/trac/ghc/ticket/11163 > https://ghc.haskell.org/trac/ghc/ticket/11195 > > We came up with a "minimal" example that at least is self contained and > triggers the problem; `runghc Minimal.hs` should finish with about 5GB of RAM. > > Our actual non-minimal scenario runs out of memory on a 16GB RAM machine. > > We tried with ghc 8.4.2, 8.0.2 and 7.10.3 and ghc-HEAD; all of those showed > a similar problem, although the older ghc's used less memory. > > Do you have any suggestions to make our code finish compiling without running > out of memory? > > Thanks!! > Victor > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From v.cacciarimiraldo at uu.nl Thu Mar 29 16:05:50 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Thu, 29 Mar 2018 18:05:50 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: <5f94ff7a7ba34a4899f185486ca554ef@ICTSC-W-S210.soliscom.uu.nl> References: <5f94ff7a7ba34a4899f185486ca554ef@ICTSC-W-S210.soliscom.uu.nl> Message-ID: Hello! > You can turn off the pattern match checker, is that an option? How? > Can you post your code which shows the poor behaviour. It could be > good to profile that part of GHC to see if there are any easy gains > but it is known to be slow. I attached a minimal example in the original e-mail. The code that triggers the really bad case is not much bigger. It is divided in many more modules, though. Cheers, Victor From v.cacciarimiraldo at uu.nl Thu Mar 29 16:12:09 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Thu, 29 Mar 2018 18:12:09 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> Message-ID: Hello Ben, >> We came up with a "minimal" example that at least is self contained and >> triggers the problem; `runghc Minimal.hs` should finish with about 5GB of RAM. >> > Hmm, with 8.2 I'm seeing a peak memory usage of 3.5 GB, with that peak > occurring during renaming, not desugaring (when exhaustiveness checking > happens). Are you certain that the exhaustiveness checker is the > responsible party? Not at all! In fact, I ran some comparisons with "-ddump-phases" and plotted those. I'm attaching the graphs here. From base to "added E" we added 16 more pattern matches, then each "added" phase is an additional 16 pattern matches. The simplifier stands out there. I couldn't run a bigger case as I had hit the ceiling of my machine. Cheers, Victor -------------- next part -------------- A non-text attachment was scrubbed... Name: SpacePerPhase.png Type: image/png Size: 48865 bytes Desc: SpacePerPhase.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TimePerPhase.png Type: image/png Size: 46136 bytes Desc: TimePerPhase.png URL: From ben at smart-cactus.org Thu Mar 29 16:32:10 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Mar 2018 12:32:10 -0400 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> Message-ID: <87po3mhmgq.fsf@smart-cactus.org> "Victor Miraldo (UU)" writes: > Hello Ben, > > >>> We came up with a "minimal" example that at least is self contained and >>> triggers the problem; `runghc Minimal.hs` should finish with about 5GB of RAM. >>> >> Hmm, with 8.2 I'm seeing a peak memory usage of 3.5 GB, with that peak >> occurring during renaming, not desugaring (when exhaustiveness checking >> happens). Are you certain that the exhaustiveness checker is the >> responsible party? > > Not at all! In fact, I ran some comparisons with "-ddump-phases" and > plotted those. > I'm attaching the graphs here. From base to "added E" we added 16 more > pattern matches, > then each "added" phase is an additional 16 pattern matches. The > simplifier stands out there. > > I couldn't run a bigger case as I had hit the ceiling of my machine. > I tried 8.4 and indeed the renamer/typechecker takes dramatically less memory (yay!), leaving desugar as the largest allocator (allocating around 3GB) while compiling the minimal example. Furthermore, disabling the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically reduces desugarer allocations (to around 60MByte). It looks like you are right. Unfortunately, it's not clear what can be done to work around this short of disabling the match checker for the entire module, as suggested by mpickering. Ideally we would have some notion of local warning flags (e.g. #602), allowing us to disable this (rather expensive) warning for generated code. Sadly, we aren't there yet. Perhaps you would like to propose such a mechanism? 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 Thu Mar 29 17:47:01 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Mar 2018 17:47:01 +0000 Subject: Memory usage exploding for complex pattern matching In-Reply-To: <87po3mhmgq.fsf@smart-cactus.org> References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: Let's make a Trac ticket for this (since there is a nice small reproducer). Or, if it seems a dup, attach the reproducer to some existing ticket. Maybe we should revert the (recent) patch that makes TH code behave like source code, until this pattern-match check business is solved. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 29 March 2018 17:32 | To: Victor Miraldo (UU) | Cc: ghc-devs at haskell.org | Subject: Re: Memory usage exploding for complex pattern matching | | "Victor Miraldo (UU)" writes: | | > Hello Ben, | > | > | >>> We came up with a "minimal" example that at least is self contained | and | >>> triggers the problem; `runghc Minimal.hs` should finish with about | 5GB of RAM. | >>> | >> Hmm, with 8.2 I'm seeing a peak memory usage of 3.5 GB, with that | peak | >> occurring during renaming, not desugaring (when exhaustiveness | checking | >> happens). Are you certain that the exhaustiveness checker is the | >> responsible party? | > | > Not at all! In fact, I ran some comparisons with "-ddump-phases" and | > plotted those. | > I'm attaching the graphs here. From base to "added E" we added 16 more | > pattern matches, | > then each "added" phase is an additional 16 pattern matches. The | > simplifier stands out there. | > | > I couldn't run a bigger case as I had hit the ceiling of my machine. | > | I tried 8.4 and indeed the renamer/typechecker takes dramatically less | memory (yay!), leaving desugar as the largest allocator (allocating | around 3GB) while compiling the minimal example. Furthermore, disabling | the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically | reduces desugarer allocations (to around 60MByte). It looks like you are | right. | | Unfortunately, it's not clear what can be done to work around this short | of | disabling the match checker for the entire module, as suggested by | mpickering. Ideally we would have some notion of local warning flags | (e.g. #602), allowing us to disable this (rather expensive) warning for | generated code. Sadly, we aren't there yet. Perhaps you would like to | propose such a mechanism? | | Cheers, | | - Ben From v.cacciarimiraldo at uu.nl Thu Mar 29 18:47:27 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Thu, 29 Mar 2018 20:47:27 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: Hello, @Ben > I tried 8.4 and indeed the renamer/typechecker takes dramatically less > memory (yay!), leaving desugar as the largest allocator (allocating > around 3GB) while compiling the minimal example. Furthermore, disabling > the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically > reduces desugarer allocations (to around 60MByte). It looks like you are > right. I have just tried compiling my code with 8.4.2 and using -fmax-pmcheck-iterations=0, I gave GHC 12GB of ram and it still ran out (through `ulimit -v$((1024*1024*12))`). I saw many warnings about the pattern match checker exceeding the iterations I specified: warning: Pattern match checker exceeded (0) iterations in a case alternative. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) Which makes me wonder, is the option really stopping the checker or just displaying something when it exceeds the given number? > Unfortunately, it's not clear what can be done to work around this short > of > disabling the match checker for the entire module, as suggested by > mpickering. Ideally we would have some notion of local warning flags > (e.g. #602), allowing us to disable this (rather expensive) warning for > generated code. Sadly, we aren't there yet. Perhaps you would like to > propose such a mechanism? You guys are much more indicated to propose mechanisms to fix this. If you think this is a sensible mechanism to implement, sure! I'd be happy to propose it. @Simon > Let's make a Trac ticket for this (since there is a nice small reproducer). Or, if it seems a dup, attach the reproducer to some existing ticket. Should I be the one creating it or adding the reproducer? The closest I've seen is: https://ghc.haskell.org/trac/ghc/ticket/11195 > Maybe we should revert the (recent) patch that makes TH code behave like source code, until this pattern-match check business is solved. Let me know when this happens, I'll be happy to test my code again! Thanks! Cheers, Victor From ben at smart-cactus.org Thu Mar 29 19:57:03 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Mar 2018 15:57:03 -0400 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: <87k1tuhcza.fsf@smart-cactus.org> "Victor Miraldo (UU)" writes: > Hello, > > @Ben > >> I tried 8.4 and indeed the renamer/typechecker takes dramatically less >> memory (yay!), leaving desugar as the largest allocator (allocating >> around 3GB) while compiling the minimal example. Furthermore, disabling >> the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically >> reduces desugarer allocations (to around 60MByte). It looks like you are >> right. > > I have just tried compiling my code with 8.4.2 and using > -fmax-pmcheck-iterations=0, > I gave GHC 12GB of ram and it still ran out (through `ulimit > -v$((1024*1024*12))`). > Hmmm, I'm a bit confused. Why are our results so different? How precisely are you invoking GHC? > @Simon > >> Let's make a Trac ticket for this (since there is a nice small >> reproducer). Or, if it seems a dup, attach the reproducer to some >> existing ticket. > > Should I be the one creating it or adding the reproducer? > The closest I've seen is: https://ghc.haskell.org/trac/ghc/ticket/11195 > Let's start with a fresh ticket; #11195 has a rather long history. Do you think you could open it and attach your repro? 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 v.cacciarimiraldo at uu.nl Thu Mar 29 20:10:27 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Thu, 29 Mar 2018 22:10:27 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: Hello, >> I have just tried compiling my code with 8.4.2 and using >> -fmax-pmcheck-iterations=0, >> I gave GHC 12GB of ram and it still ran out (through `ulimit >> -v$((1024*1024*12))`). >> > Hmmm, I'm a bit confused. Why are our results so different? How > precisely are you invoking GHC? Here I meant my whole code, not just the repro. I could have been more clear. Nevertheless, I'm calling it through stack: stack build --ghc-options="-fmax-pmcheck-iterations=0" I have just ran the repro with and without "-fmax-pmcheck-iterations=0" and got similar results to yours. > Let's start with a fresh ticket; #11195 has a rather long history. Do > you think you could open it and attach your repro? Sure thing, will do it tomorrow! Cheers, Victor From omeragacan at gmail.com Fri Mar 30 11:20:15 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 30 Mar 2018 14:20:15 +0300 Subject: Phabricator new behavior regarding submitting patches for reviews Message-ID: Hi, One of the changes with the recent Phabricator update is that we can no longer submit a patch for reviews until the build bot successfully builds it. I can't even ping people in the comment section until the patch builds. It says: > These changes have not finished building yet and may have build failures. This > revision is currently a draft. You can leave comments, but no one will be > notified until the revision is submitted for review. The "submit" button now says "submit quietly". This is really annoying because - It takes several days for build bot to build a patch (I have a patch that has been in the queue for 3 days now and it's still counting) - I can validate a patch on my laptop in an hour. (slow validate takes about 2-3 hours) Previously I could get approvals, and then test locally and push. Now I can't do that unless I email people about the patch. - In the previous version I could submit an incomplete patch for comments, now I can't do that because no one will be notified and there's no way to ping people to explicitly draw attention (again unless I email people). So if possible (without downgrading it) could we bring back the old behavior (perhaps there's a setting about this?) Thanks, Ömer From ben at well-typed.com Fri Mar 30 14:41:57 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 30 Mar 2018 10:41:57 -0400 Subject: Phabricator new behavior regarding submitting patches for reviews In-Reply-To: References: Message-ID: <87fu4hhbgv.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > Hi, > > One of the changes with the recent Phabricator update is that we can no longer > submit a patch for reviews until the build bot successfully builds it. I can't > even ping people in the comment section until the patch builds. It says: > >> These changes have not finished building yet and may have build failures. This >> revision is currently a draft. You can leave comments, but no one will be >> notified until the revision is submitted for review. > > The "submit" button now says "submit quietly". > > This is really annoying because > > - It takes several days for build bot to build a patch (I have a patch that has > been in the queue for 3 days now and it's still counting) > > - I can validate a patch on my laptop in an hour. (slow validate takes about 2-3 > hours) Previously I could get approvals, and then test locally and push. Now I > can't do that unless I email people about the patch. > > - In the previous version I could submit an incomplete patch for comments, now I > can't do that because no one will be notified and there's no way to ping > people to explicitly draw attention (again unless I email people). > > So if possible (without downgrading it) could we bring back the old behavior > (perhaps there's a setting about this?) > Indeed, I am also concerned that the new behavior is going to slow down the review process too much. Unfortunately, there is currently no support to revert to the old notification behavior nor does Phacility seem to have any plan to add support [1]. They do, however, mention a potential workaround which I have applied to our installation. I believe differentials should now behave as they did previously. Cheers, - Ben [1] https://secure.phabricator.com/T2543 -------------- 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 Fri Mar 30 14:46:02 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 30 Mar 2018 10:46:02 -0400 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: <87d0zlhba0.fsf@smart-cactus.org> "Victor Miraldo (UU)" writes: > Hello, > >>> I have just tried compiling my code with 8.4.2 and using >>> -fmax-pmcheck-iterations=0, >>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>> -v$((1024*1024*12))`). >>> >> Hmmm, I'm a bit confused. Why are our results so different? How >> precisely are you invoking GHC? > > Here I meant my whole code, not just the repro. I could have been more clear. > Nevertheless, I'm calling it through stack: > I'll admit that I am a bit lost; Minimal.hs compiles for me with a maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled using GHC 8.4.1. Is this not the repro you are referring to? 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 v.cacciarimiraldo at uu.nl Fri Mar 30 15:06:26 2018 From: v.cacciarimiraldo at uu.nl (Victor Miraldo (UU)) Date: Fri, 30 Mar 2018 17:06:26 +0200 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: Hello, >>>> I have just tried compiling my code with 8.4.2 and using >>>> -fmax-pmcheck-iterations=0, >>>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>>> -v$((1024*1024*12))`). >>>> >>> Hmmm, I'm a bit confused. Why are our results so different? How >>> precisely are you invoking GHC? >> >> Here I meant my whole code, not just the repro. I could have been more clear. >> Nevertheless, I'm calling it through stack: >> > I'll admit that I am a bit lost; Minimal.hs compiles for me with a > maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled > using GHC 8.4.1. Is this not the repro you are referring to? I get the same behavior as you for Minimal.hs. The "my code" above referred to the whole library that I'm developping. In fact, the Minimal.hs file contains a distilled version of that library with a template haskell splice that we are trying to use in one of our fully fledged examples. Do you want me to produce a larger "NotSoMinimal.hs" closer to the real thing? Cheers, Victor From ben at smart-cactus.org Fri Mar 30 15:23:55 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 30 Mar 2018 11:23:55 -0400 Subject: Memory usage exploding for complex pattern matching In-Reply-To: References: <8e707c69a3044b19a2b3702eb77c02d3@ICTSC-W-S208.soliscom.uu.nl> <87po3mhmgq.fsf@smart-cactus.org> Message-ID: <877epth9iy.fsf@smart-cactus.org> "Victor Miraldo (UU)" writes: > Hello, > >>>>> I have just tried compiling my code with 8.4.2 and using >>>>> -fmax-pmcheck-iterations=0, >>>>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>>>> -v$((1024*1024*12))`). >>>>> >>>> Hmmm, I'm a bit confused. Why are our results so different? How >>>> precisely are you invoking GHC? >>> >>> Here I meant my whole code, not just the repro. I could have been more clear. >>> Nevertheless, I'm calling it through stack: >>> >> I'll admit that I am a bit lost; Minimal.hs compiles for me with a >> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled >> using GHC 8.4.1. Is this not the repro you are referring to? > > I get the same behavior as you for Minimal.hs. > > The "my code" above referred to the whole library that I'm developping. > In fact, the Minimal.hs file contains a distilled version of that library with > a template haskell splice that we are trying to use in one of our > fully fledged examples. > Okay, I just wanted to be certain we were indeed seeing the same behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program, even one with the deep matches seen in Minimal.hs. 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 omeragacan at gmail.com Fri Mar 30 15:29:52 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 30 Mar 2018 18:29:52 +0300 Subject: Phabricator new behavior regarding submitting patches for reviews In-Reply-To: <87fu4hhbgv.fsf@smart-cactus.org> References: <87fu4hhbgv.fsf@smart-cactus.org> Message-ID: Thanks Ben. Is there anything I can do about the existing tickets stuck in "draft" state? Ömer 2018-03-30 17:41 GMT+03:00 Ben Gamari : > Ömer Sinan Ağacan writes: > >> Hi, >> >> One of the changes with the recent Phabricator update is that we can no longer >> submit a patch for reviews until the build bot successfully builds it. I can't >> even ping people in the comment section until the patch builds. It says: >> >>> These changes have not finished building yet and may have build failures. This >>> revision is currently a draft. You can leave comments, but no one will be >>> notified until the revision is submitted for review. >> >> The "submit" button now says "submit quietly". >> >> This is really annoying because >> >> - It takes several days for build bot to build a patch (I have a patch that has >> been in the queue for 3 days now and it's still counting) >> >> - I can validate a patch on my laptop in an hour. (slow validate takes about 2-3 >> hours) Previously I could get approvals, and then test locally and push. Now I >> can't do that unless I email people about the patch. >> >> - In the previous version I could submit an incomplete patch for comments, now I >> can't do that because no one will be notified and there's no way to ping >> people to explicitly draw attention (again unless I email people). >> >> So if possible (without downgrading it) could we bring back the old behavior >> (perhaps there's a setting about this?) >> > Indeed, I am also concerned that the new behavior is going to slow down > the review process too much. Unfortunately, there is currently no > support to revert to the old notification behavior nor does Phacility > seem to have any plan to add support [1]. > > They do, however, mention a potential workaround which I have applied to > our installation. I believe differentials should now behave as they did > previously. > > Cheers, > > - Ben > > > [1] https://secure.phabricator.com/T2543 From ben at well-typed.com Fri Mar 30 18:04:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 30 Mar 2018 14:04:45 -0400 Subject: Phabricator new behavior regarding submitting patches for reviews In-Reply-To: References: <87fu4hhbgv.fsf@smart-cactus.org> Message-ID: <871sg1h22w.fsf@smart-cactus.org> Ömer Sinan Ağacan writes: > Thanks Ben. Is there anything I can do about the existing tickets stuck in > "draft" state? > I assume you worked this out? I think you can just "request review" in the actions menu at the bottom of the page. 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 omeragacan at gmail.com Fri Mar 30 20:11:01 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 30 Mar 2018 23:11:01 +0300 Subject: Phabricator new behavior regarding submitting patches for reviews In-Reply-To: <871sg1h22w.fsf@smart-cactus.org> References: <87fu4hhbgv.fsf@smart-cactus.org> <871sg1h22w.fsf@smart-cactus.org> Message-ID: > I assume you worked this out? I think you can just "request review" in > the actions menu at the bottom of the page. This seems to work, although it's still one extra step compared to the previous version. Ömer 2018-03-30 21:04 GMT+03:00 Ben Gamari : > Ömer Sinan Ağacan writes: > >> Thanks Ben. Is there anything I can do about the existing tickets stuck in >> "draft" state? >> > I assume you worked this out? I think you can just "request review" in > the actions menu at the bottom of the page. > > Cheers, > > - Ben > From lonetiger at gmail.com Sat Mar 31 10:31:24 2018 From: lonetiger at gmail.com (Phyx) Date: Sat, 31 Mar 2018 11:31:24 +0100 Subject: Reconfigure required for head. Message-ID: Hi all, I have just committed 4de585a which lifts the MAX_PATH restrictions for Haskell programs compiled with GHC 8.6 for Windows users. However when you update, you *MUST* run configure again. This counts for ALL platforms otherwise your build will suffer a not so friendly failure. If you're using Hadrian to build, you must manually update the submodule to HEAD of master as the Hadrian submodule hasn't been bumped yet. Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: