Re: Wildcards in type synonyms
Wild guess: you aren't instantiating the kinds of the meta-tyvars to
something sensible, so kinds don't line up. Eg. where are k_ax9 and k_awW
bound?
You need to be super-careful about the *level* of wildcards. That is a
tricky bit about the whole wildcard implementation.
I'm still unconvinced whether this is a good use of your valuable time --
but of course that is up to you.
Simon
On Thu, 28 Jul 2022 at 06:53, ÉRDI Gergő wrote:
> (TL;DR: `newMetaTyVarX` gives me type metavars that behave weirdly and I
> don't understand why. What shoudl I use instead?)
>
> OK so I have two half-done implementations now:
>
>* Doing `HsType`-level substitution in the middle of `tc_infer_hs_type`
> (see my exchange with Richard on why this needs to happen in
> `tc_infer_hs_type` instead of `rnHsTyKi`)
>
>* Doing Core `Type`-level substitution in the middle of
> `tc_infer_hs_type`
>
> The advantage of the first one is that it works :) The disadvantage is
> that it involves storing a `HsType` in a `TyCon`, which in turn means
> making it work inter-module will require an `Iface` representation for
> `HsType`s.
>
> Hence the second attempt. I think that would be a more principled solution
> anyway. This approach is based on typechecking the macro's right-hand side
> into a core `Type`, and storing that, and the list of wildcard-originating
> `TyVar`s, in the `TyCon`. At every occurrence site, I take this core
> `Type` and apply a substitution on it that is the composition of the
> following two:
>
>* A substitution from macro type synonym type parameters to the type
> arguments
>* An instantiation of each wildcard variable into a fresh metavariable
>
> Unfortunately, it is this second step that is tripping me up. If I use
> `newMetaTyVarX` to make these "refreshing" metavars, then while the
> substitution looks OK when eyeballing it, the resulting
> *type* metavariables seem to be handled by GHC as if they were *kind*
> metavariables?!
>
> Here's an example. The source input is:
>
> ```
> {-# LANGUAGE NoPolyKinds, NoStarIsType #-} -- Makes it easier to see how
> it goes wrong
>
> data MyData a b c = MkMyData a b c
> type MySyn a = MyData a _ Int
>
> f1 :: MyData a b c -> b
> f1 (MkMyData _ x _) = x
>
> f2 :: MySyn a -> Double
> f2 = f1
> ```
>
> I start with the following "macro type template" (using `-dppr-debug`
> format):
>
> ```
>TySynWildcard.MyData{tc r3}
> (a{tv auq} Nothing [sk:1] :: GHC.Types.Type{(w) tc 32Q})
> ((w_awX{tv} Nothing [tau:0] :: (k_awW{tv} Nothing [tau:0] ::
> GHC.Types.Type{(w) tc 32Q}))
> |> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
> GHC.Prim.~#{(w) tc 31I}
>
> GHC.Types.Type{(w) tc 32Q}
>
> GHC.Types.Type{(w) tc 32Q}
>
> (k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
>
> GHC.Types.Type{(w) tc 32Q})})
> GHC.Types.Int{(w) tc 3u}
> ```
>
> The substitution applied:
>
> ```
>[TCvSubst
> In scope: InScope {a{tv auu} k_awW{tv} w_axc{tv}}
> Type env: [auq :-> (a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing
> [tau:2] :: GHC.Types.Type{(w) tc 32Q})),
> awX :-> (w_axc{tv} Nothing [tau:2] :: (k_awW{tv} Nothing
> [tau:0] :: GHC.Types.Type{(w) tc 32Q}))]
> Co env: []]
> ```
>
> Note that the second type substitution, (w_awX :: k_awW) :-> (w_axc ::
> k_awW) is the
> one that should take care of instantiating the wildcard metavariable. And
> the result of applying this substitution still looks OK:
>
> ```
>TySynWildcard.MyData{tc r3}
> (a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2] ::
> GHC.Types.Type{(w) tc 32Q}))
> ((w_axc{tv} Nothing [tau:2] :: (k_awW{tv} Nothing [tau:0] ::
> GHC.Types.Type{(w) tc 32Q}))
> |> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
> GHC.Prim.~#{(w) tc 31I}
>
> GHC.Types.Type{(w) tc 32Q}
>
> GHC.Types.Type{(w) tc 32Q}
>
> (k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
>
> GHC.Types.Type{(w) tc 32Q})})
> GHC.Types.Int{(w) tc 3u}
> ```
>
> But soon after, typechecking fails:
>
> ```
> • Couldn't match type ‘Type’ with ‘Double’
>Expected: MyData a Type Int -> Double
> Actual: MyData a Type Int -> Type
> • In the expression: f1
>In an equation for ‘f2’: f2 = f1
> ```
>
> So this is weird. Instead of unification solving `w_axc ~ Double`, it
> seems `w_axc` is left unrestricted, and then `NoPolyKinds` picks it up as
> a kind variable (why?) and defaults it to `Type`.
>
> As an experiment, I have also tried *not* refreshing `w_awX`, only
> substituting in the type arguments. Now, of course, this can't possibly
> work as soon as I have more than one occurrence of `MySyn` due to the
> interference between the wildcard metavars, but if I only have one, then
> the program typechecks. So to me this suggests I'm doing things mostly
> right, except that the metavar returned by `newMetaTyVarX` is not fit for
> my use case.
>
> What should I use instead of `newMetaTyVarX`
Re: Wildcards in type synonyms
On Thu, 28 Jul 2022, Simon Peyton Jones wrote:
Wild guess: you aren't instantiating the kinds of the meta-tyvars to something
sensible, so kinds don't line up. Eg. where are k_ax9 and k_awW bound?
`a_auu :: k_ax9` is the result of typechecking my type argument (the `a`
in the source type `MySyn a`), so I would expect its kind to work because
it is computed by parts of GHC that I am not changing.
`w_awX :: k_awW` is the metavariable created during the typechecking of
the right-hand side of my type macro `type MySyn a = MyData a _ Int`. This
kind is then kept for the fresh metavariable that I try to replace `w_awX`
with, since I have `w_axc :: k_awW`.
The part that confuses me the most is that the right-hand side seems to
work just fine on its own:
As an experiment, I have also tried *not* refreshing `w_awX`, only
substituting in the type arguments. Now, of course, this can't possibly
work as soon as I have more than one occurrence of `MySyn` due to the
interference between the wildcard metavars, but if I only have one, then
the program typechecks.
So I have two versions of my code returning two types from
`tc_infer_hs_type` that only differ in containing either `w_awX :: k_awW`
or `w_axc :: k_awW`, and one of them typechecks while the other causes a
type error.
Typechecks (as long as only used once of course):
```
TySynWildcard.MyData{tc r3}
(a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2] ::
GHC.Types.Type{(w) tc 32Q}))
((w_awX{tv} Nothing [tau:0] :: (k_awW{tv} Nothing [tau:0] ::
GHC.Types.Type{(w) tc 32Q}))
|> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
GHC.Prim.~#{(w) tc 31I}
GHC.Types.Type{(w) tc 32Q}
GHC.Types.Type{(w) tc 32Q}
(k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
GHC.Types.Type{(w) tc 32Q})})
GHC.Types.Int{(w) tc 3u}
```
Doesn't typecheck:
```
TySynWildcard.MyData{tc r3}
(a{tv auu} Nothing [sk:2] :: (k_ax9{tv} Nothing [tau:2] ::
GHC.Types.Type{(w) tc 32Q}))
((w_axc{tv} Nothing [tau:2] :: (k_awW{tv} Nothing [tau:0] ::
GHC.Types.Type{(w) tc 32Q}))
|> {(co_awY{v} Just 'GHC.Types.Many{(w) d 65I} [lid[CoVarId]] ::
GHC.Prim.~#{(w) tc 31I}
GHC.Types.Type{(w) tc 32Q}
GHC.Types.Type{(w) tc 32Q}
(k_awW{tv} Nothing [tau:0] :: GHC.Types.Type{(w) tc 32Q})
GHC.Types.Type{(w) tc 32Q})})
GHC.Types.Int{(w) tc 3u}
```
What is the difference?___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Gitlab labels
Whenever I try to add a label to a ticket I get "an error occurred while updating labels". See below. When I repeat the exact same sequence, it works. If I add another label, again the error; repeating again works. This is tiresome and peculiar. Does anyone have any ideas? Simon [image: image.png] ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab labels
The error is bogus, if you refresh the page you will see that the label has been updated. This seems to be a bug in Gitlab, and I've also been seeing it a lot more often recently. I think Bryan attempted to investigate at a certain point, but I don't know what came of it. On 22/07/28 10:51, Simon Peyton Jones wrote: Whenever I try to add a label to a ticket I get "an error occurred while updating labels". See below. When I repeat the exact same sequence, it works. If I add another label, again the error; repeating again works. This is tiresome and peculiar. Does anyone have any ideas? Simon [image: image.png] ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Gitlab labels
I haven't looked into it yet. As I haven't seen this problem on any other instance of GitLab, I have a hunch it's unique to gitlab.haskell.org. I'd like to look into it eventually. -Bryan On 28/07/2022 12:55, Zubin Duggal wrote: The error is bogus, if you refresh the page you will see that the label has been updated. This seems to be a bug in Gitlab, and I've also been seeing it a lot more often recently. I think Bryan attempted to investigate at a certain point, but I don't know what came of it. On 22/07/28 10:51, Simon Peyton Jones wrote: Whenever I try to add a label to a ticket I get "an error occurred while updating labels". See below. When I repeat the exact same sequence, it works. If I add another label, again the error; repeating again works. This is tiresome and peculiar. Does anyone have any ideas? Simon [image: image.png] ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[Haskell] [ANNOUNCE] GHC 9.2.4 released
The GHC developers are very happy to at announce the availability of GHC 9.2.4. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.4). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html Blog Post: https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html This release will include: - The new `DeepSubsumption` language extension which reverses the effects of the [Simplified Subsumption Proposal] introduced in GHC 9.0. This is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and eases migration for users who depended on this feature. This extension is enabled by default with the `Haskell2010` and `Haskell98` languages but disabled with the `GHC2021` language originally introduced in GHC 9.2.1. See the [Deep Subsumption Proposal] for more details. - Fixes for segfaults that may arise due to a bug in the implementation of the `keepAlive#` primop. This may regress performance for certain programs which use this primop or functions which use the primop, such as `withForeignPtr`. These regressions are mostly small, but can be larger in certain edge cases. Judicious use of `unsafeWithForeignPtr` when its argument is known not to statically diverge can mitigate these in many cases. It is our judgment that the critical correctness issues justify the regression in performance and that it is important to get a release out with the fix while we work on a better approach which will improve performance for future releases (#21708). We have a [wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) that tracks possible solutions to this problem, and Ben wrote a [blog post](https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) detailing the introduction of the `keepAlive#` primop and its history. - Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685). - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885). - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). - ... and much more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html [Simplified Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst [Deep Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wildcards in type synonyms
On Thu, 28 Jul 2022, Simon Peyton Jones wrote: You need to be super-careful about the *level* of wildcards. That is a tricky bit about the whole wildcard implementation. Indeed! Ensuring the fresh metavars are at `topTcLevel` seems to have fixed my problem. My goal doesn't include support higher-rank types at all, anyway, so this should be good enough for now. Thanks, this was the key to all my troubles.___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Test suite
Doing *hadrian/build test* takes absolutely ages. It seems that it is building haddock, running haddock, building check_exact, and other things. Eg right now it is doing Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 more) => _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock But I didn't ask to do Haddock. I just wanted to run the testsuite. How can I do that? I would prefer never to build haddock. Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Test suite
Simon, I believe you can use `--docs=none`, at least it'll prevent running haddock. On Thu, Jul 28, 2022 at 3:46 PM Simon Peyton Jones wrote: > > Doing hadrian/build test > takes absolutely ages. It seems that it is building haddock, running > haddock, building check_exact, and other things. Eg right now it is doing > Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 more) > => _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock > > But I didn't ask to do Haddock. I just wanted to run the testsuite. How can > I do that? > > I would prefer never to build haddock. > > Thanks > > Simon > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Test suite
There are tests that depend upon haddock in the testsuite, so we need to build them to run those tests. Like Cheng says, passing `--docs=none` will avoid those tests. On 22/07/28 14:47, Simon Peyton Jones wrote: Doing *hadrian/build test* takes absolutely ages. It seems that it is building haddock, running haddock, building check_exact, and other things. Eg right now it is doing Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 more) => _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock But I didn't ask to do Haddock. I just wanted to run the testsuite. How can I do that? I would prefer never to build haddock. Thanks Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Test suite
> > There are tests that depend upon haddock in the testsuite, so we need to > build them to run those tests. Like Cheng says, passing `--docs=none` > will avoid those tests. > But looking at `ps` I see an invocation of haddock that was running for 20 minutes! This can't be right. Adding --docs=none apparently didn't work. I get zillions of failures. But then it turned out that this failed because I also added -VV, in the hope of seeing what is going on. So this works hadrian/build test --docs=none --only=T13199 But this does not (log below) hadrian/build test --docs=none --only=T13199 -VV I thought -VV controlled verbosity only! Simon => T13199(normal) 1 of 1 [0, 0, 0] cd "/tmp/ghctest-6yc58m02/test spaces/testsuite/tests/printer/T13199.run" && $MAKE --no-print-directory T13199 < ]0;T13199(normal) 1 of 1 [0, 0, 0] Actual stdout output differs from expected: diff -uw "/dev/null" "/tmp/ghctest-6yc58m02/test spaces/testsuite/tests/printer/T13199.run/T13199.run.stdout.normalised"< --- /dev/null 2022-07-28 08:52:58.41998 +0100 +++ "/tmp/ghctest-6yc58m02/test spaces/testsuite/tests/printer/T13199.run/T13199.run.stdout.normalised" 2022-07-28 16:04:06.479419465 +0100 @@ -0,0 +1,2 @@ +/home/simonpj/code/HEAD-1/_build/test/bin/check-ppr "`'/home/simonpj/code/HEAD-1/_build/stage1/bin/ghc' -dcore-lint -dstg-lint -dcmm-lint -fno-dump-with-ways -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output --print-libdir | tr -d '\r'`" T13199.hs +/home/simonpj/code/HEAD-1/_build/test/bin/check-exact "`'/home/simonpj/code/HEAD-1/_build/stage1/bin/ghc' -dcore-lint -dstg-lint -dcmm-lint -fno-dump-with-ways -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output --print-libdir | tr -d '\r'`" T13199.hs *** unexpected failure for T13199(normal) Performance Metrics (test environment: local): None collected. Unexpected results from: TEST="T13199" SUMMARY for test run started at Thu Jul 28 16:04:05 2022 0:00:00.845518 spent to go through 1 total tests, which gave rise to 7 test cases, of which 6 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 0 fragile tests Unexpected failures: /tmp/ghctest-6yc58m02/test spaces/testsuite/tests/printer/T13199.run T13199 [bad stdout] (normal) On Thu, 28 Jul 2022 at 15:23, Zubin Duggal wrote: > There are tests that depend upon haddock in the testsuite, so we need to > build them to run those tests. Like Cheng says, passing `--docs=none` > will avoid those tests. > > On 22/07/28 14:47, Simon Peyton Jones wrote: > >Doing *hadrian/build test* > >takes absolutely ages. It seems that it is building haddock, running > >haddock, building check_exact, and other things. Eg right now it is doing > >Run Haddock BuildPackage: libraries/parsec/src/Text/Parsec.hs (and 24 > more) > >=> _build/doc/html/libraries/parsec-3.1.15.0/parsec.haddock > > > >But I didn't ask to do Haddock. I just wanted to run the testsuite. How > >can I do that? > > > >I would prefer never to build haddock. > > > >Thanks > > > >Simon > > >___ > >ghc-devs mailing list > >ghc-devs@haskell.org > >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released
Thanks Zubin, this is good news. On a Mac when do ./configure I see checking Xcode version... xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance not found (too old?) I assume I can ignore that but FWIW it's weird as I do have that directory and it is not old: $ ls -ld /Library/Developer/CommandLineTools drwxr-xr-x@ 5 root wheel 160 27 May 20:54 /Library/Developer/CommandLineTools $ xcode-select --version xcode-select version 2395. On a Mac it is still necessary to do xattr -rc . before doing sudo make install this is also true for 9.4.1-rc1 which I noted in 21506 <https://gitlab.haskell.org/ghc/ghc/-/issues/21506>. Thanks George On Thu, Jul 28, 2022 at 8:17 AM Zubin Duggal wrote: > The GHC developers are very happy to at announce the availability of GHC > 9.2.4. Binary distributions, source distributions, and documentation are > available at [`downloads.haskell.org`]( > https://downloads.haskell.org/ghc/9.2.4). > > Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html > Blog Post: > https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html > > This release will include: > > - The new `DeepSubsumption` language extension which reverses the > effects of the [Simplified Subsumption Proposal] introduced in GHC > 9.0. This > is an attempt to make GHC 9.2.4 more backwards compatible with GHC > 8.10 and > eases migration for users who depended on this feature. > > This extension is enabled by default with the `Haskell2010` > and `Haskell98` languages but disabled with the `GHC2021` > language originally introduced in GHC 9.2.1. > > See the [Deep Subsumption Proposal] for more details. > > - Fixes for segfaults that may arise due to a bug in the implementation > of the > `keepAlive#` primop. This may regress performance for certain programs > which > use this primop or functions which use the primop, such as > `withForeignPtr`. > These regressions are mostly small, but can be larger in certain edge > cases. > Judicious use of `unsafeWithForeignPtr` when its argument is known not > to > statically diverge can mitigate these in many cases. It is our > judgment that > the critical correctness issues justify the regression in performance > and that > it is important to get a release out with the fix while we work on a > better > approach which will improve performance for future releases (#21708). > > We have a [wiki page]( > https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) > that tracks possible solutions to this problem, and Ben wrote a > [blog post]( > https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) > detailing the introduction of the `keepAlive#` primop and its history. > > - Fixes for a number of miscompilations on AArch64 and other platforms > (#21624, > #21773, #20735, #21685). > > - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, > #21885). > > - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). > >- ... and much more. See the [release notes] for a full accounting. > > As some of the fixed issues do affect correctness users are encouraged to > upgrade promptly. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk > stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, > and other anonymous > contributors whose on-going financial and in-kind support has > facilitated GHC maintenance and release management over the years. > Finally, this release would not have been possible without the hundreds > of open-source contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy compiling, > > - Zubin > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: > https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html > [Simplified Subsumption Proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst > [Deep Subsumption Proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released
Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
