From jjantura at gmail.com  Wed Mar  5 09:07:11 2025
From: jjantura at gmail.com (Jar Jar)
Date: Wed, 5 Mar 2025 10:07:11 +0100
Subject: Gitlab access
Message-ID: <CAKrj_JLXY7U-E4gQdPNUPn7-+i0cMcXG_HXrbTrQ+gzvdk4Hwg@mail.gmail.com>

Hi ghc-devs,

Please accept gitlab access request for : spamdefence+haskell at torinthiel.pl

Kind Regards,
JJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250305/f2ad0fd8/attachment.html>

From ben at well-typed.com  Fri Mar 14 23:26:25 2025
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 14 Mar 2025 19:26:25 -0400
Subject: GHC 9.12.2 is now available
Message-ID: <878qp7tcrz.fsf@smart-cactus.org>


The GHC developers are happy to announce the release of GHC 9.12.2.
Binary distributions, source distributions, and documentation are available at
[downloads.haskell.org].

We hope to have this release available via `ghcup` shortly. This is a small
release fixing a critical code generation bug, #25653, affecting some subword
division operations.

As always, GHC's release status, including planned future releases, can
be found on the GHC Wiki [status].

We would like to thank IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O,
Serokell, Equinix, SimSpace, the 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 who contribute their code, tickets, and
energy to the GHC project.

As always, do give this release a try and open a [ticket] if you see
anything amiss.


[release notes]: https://downloads.haskell.org/ghc/9.12.2/docs/users_guide/9.12.2-notes.html
[status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
[downloads.haskell.org]: https://downloads.haskell.org/ghc/9.12.2
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250314/09045f88/attachment.sig>

From rodrigo.m.mesquita at gmail.com  Wed Mar 19 22:44:34 2025
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Wed, 19 Mar 2025 22:44:34 +0000
Subject: Gitlab access
In-Reply-To: <CAKrj_JLXY7U-E4gQdPNUPn7-+i0cMcXG_HXrbTrQ+gzvdk4Hwg@mail.gmail.com>
References: <CAKrj_JLXY7U-E4gQdPNUPn7-+i0cMcXG_HXrbTrQ+gzvdk4Hwg@mail.gmail.com>
Message-ID: <4ADDD4BD-6D9C-4147-8659-CDDB78BA0C96@gmail.com>

Dear Jar Jar,

I couldn’t find the account you mentioned in the pending users.
Could you try again perhaps?

Cheers,
Rodrigo

> On 5 Mar 2025, at 09:07, Jar Jar <jjantura at gmail.com> wrote:
> 
> Hi ghc-devs,
> 
> Please accept gitlab access request for : spamdefence+haskell at torinthiel.pl <mailto:spamdefence%2Bhaskell at torinthiel.pl>
> 
> Kind Regards,
> JJ
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250319/371c3cef/attachment.html>

From ben at well-typed.com  Thu Mar 20 15:52:53 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 20 Mar 2025 11:52:53 -0400
Subject: Haskell.org mailing list status
Message-ID: <87bjtvsnqy.fsf@smart-cactus.org>

Hi all,

As you may have noticed, yesterday brought an unexpected influx of
traffic from haskell.org's mailing lists. This was the result of fixing
an interruption in mailing list message delivery which began in late
February as a result of on-going infrastructure migration efforts.

We are monitoring the situation to ensure that this issue does not recur
but if you see anything amiss don't hesitate to contact
admin at haskell.org.

Thank you for your understanding and help!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250320/c4870408/attachment.sig>

From chaowen.guo1 at gmail.com  Sun Mar 23 10:37:26 2025
From: chaowen.guo1 at gmail.com (chaowen guo)
Date: Sun, 23 Mar 2025 03:37:26 -0700
Subject: fail to build ghc in github action
Message-ID: <CAJ_jDJkpd29d=ch9Aj+ZrfXOxEHZ-NVcoKDfQbGXybrRYwCb-Q@mail.gmail.com>

i fork the ghc repo from github and use the following workflow

on: push

jobs:
    build:
        runs-on: ubuntu-24.04
        steps:
        - uses: actions/checkout at main
        - run: |
              git submodule update --init --recursive
              sudo apt install -y --no-install-recommends alex happy
              python3 boot
              ./configure
              hadrian/build

Warning: Specifying an absolute path to the project file is deprecated. Use
1178
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1179>--project-dir
to set the project's directory.
1179
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1180>Config
file path source is default config file.
1180
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1181>Config
file not found: /home/runner/.config/cabal/config
1181
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1182>Writing
default configuration to /home/runner/.config/cabal/config
1182
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1183>Configuration
is affected by the following files:
1183
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1184>-
cabal.project
1184
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1185>Warning:
The package list for 'hackage.haskell.org' does not exist. Run 'cabal
1185
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1186>update'
to download it.
1186
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1187>Warning:
There is no index-state for 'hackage.haskell.org' exactly at the
1187
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1188>requested
timestamp (2025-01-27T17:45:32Z). Also, there are no index-states
1188
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1189>before
the one requested, so the repository 'hackage.haskell.org' will be
1189
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1190>empty.

1190
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1191>Resolving
dependencies...
1191
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1192>Error:
[Cabal-7107]
1192
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1193>Could
not resolve dependencies:
1193
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1194>[__0]
trying: hadrian-0.1.0.0 (user goal)
1194
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1195>[__1]
trying: hadrian:+selftest
1195
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1196>[__2]
unknown package: QuickCheck (dependency of hadrian +selftest)
1196
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1197>[__2]
fail (backjumping, conflict set: QuickCheck, hadrian, hadrian:selftest)
1197
<https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1198>After
searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: hadrian, hadrian:selftest,
QuickCheck
i have no idea what happen. please help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250323/9ff31a06/attachment.html>

From sven.tennie at gmail.com  Sun Mar 23 10:50:57 2025
From: sven.tennie at gmail.com (Sven Tennie)
Date: Sun, 23 Mar 2025 11:50:57 +0100
Subject: fail to build ghc in github action
In-Reply-To: <CAJ_jDJkpd29d=ch9Aj+ZrfXOxEHZ-NVcoKDfQbGXybrRYwCb-Q@mail.gmail.com>
References: <CAJ_jDJkpd29d=ch9Aj+ZrfXOxEHZ-NVcoKDfQbGXybrRYwCb-Q@mail.gmail.com>
Message-ID: <CALgrwrY3WgLSgNLdj_jcPEjdQ5d42X=uxVCxLQJD5C3CjvMz3w@mail.gmail.com>

Hi Chaowen,

Have you tried the proposed "The package list for 'hackage.haskell.org'
does not exist. Run 'cabal update' to download it."?

I.e. I guess you only need to add `cabal update` to the list of commands to
run.

Best regards,

Sven


Am So., 23. März 2025 um 11:37 Uhr schrieb chaowen guo <
chaowen.guo1 at gmail.com>:

> i fork the ghc repo from github and use the following workflow
>
> on: push
>
> jobs:
>     build:
>         runs-on: ubuntu-24.04
>         steps:
>         - uses: actions/checkout at main
>         - run: |
>               git submodule update --init --recursive
>               sudo apt install -y --no-install-recommends alex happy
>               python3 boot
>               ./configure
>               hadrian/build
>
> Warning: Specifying an absolute path to the project file is deprecated.
> Use
> 1178
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1179>--project-dir
> to set the project's directory.
> 1179
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1180>Config
> file path source is default config file.
> 1180
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1181>Config
> file not found: /home/runner/.config/cabal/config
> 1181
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1182>Writing
> default configuration to /home/runner/.config/cabal/config
> 1182
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1183>Configuration
> is affected by the following files:
> 1183
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1184>-
> cabal.project
> 1184
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1185>Warning:
> The package list for 'hackage.haskell.org' does not exist. Run 'cabal
> 1185
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1186>update'
> to download it.
> 1186
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1187>Warning:
> There is no index-state for 'hackage.haskell.org' exactly at the
> 1187
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1188>requested
> timestamp (2025-01-27T17:45:32Z). Also, there are no index-states
> 1188
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1189>before
> the one requested, so the repository 'hackage.haskell.org' will be
> 1189
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1190>empty.
>
> 1190
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1191>Resolving
> dependencies...
> 1191
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1192>Error:
> [Cabal-7107]
> 1192
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1193>Could
> not resolve dependencies:
> 1193
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1194>[__0]
> trying: hadrian-0.1.0.0 (user goal)
> 1194
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1195>[__1]
> trying: hadrian:+selftest
> 1195
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1196>[__2]
> unknown package: QuickCheck (dependency of hadrian +selftest)
> 1196
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1197>[__2]
> fail (backjumping, conflict set: QuickCheck, hadrian, hadrian:selftest)
> 1197
> <https://github.com/chaowenguo1/ghc/actions/runs/14017990071/job/39246149896#step:3:1198>After
> searching the rest of the dependency tree exhaustively, these were the
> goals I've had most trouble fulfilling: hadrian, hadrian:selftest,
> QuickCheck
> i have no idea what happen. please help.
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250323/13c69c23/attachment.html>

From florian.ragwitz at gmail.com  Sun Mar 23 19:11:26 2025
From: florian.ragwitz at gmail.com (Florian Ragwitz)
Date: Sun, 23 Mar 2025 12:11:26 -0700
Subject: What should it mean for a record selector to be "covered"?
Message-ID: <CAEz9uMJcxEiyigtcwv9J3W-=dh00Jts1rCbprLz8O9TuGLXiKw@mail.gmail.com>

Let's say you have

    data Foo = Foo { fooX, fooY :: Int }

For coverage reporting, HPC creates a coverage box for each top-level
definition. These boxes will be ticked appropriately at runtime when
the fooX and fooY bindings are used directly.

However, they won't be ticked if you pattern match on the constructor, such as

  f (Foo x y) = ...
  f Foo{ fooX = fooX } = ...
  f Foo{ fooX = x } = ...
  f Foo{ fooX } = ...
  f Foo{..} = ...

and variations thereof.

This is understandable, but can lead to some undesirable or unexpected
behaviour for users of RecordWildCards or RecordPuns especially. E.g.
https://gitlab.haskell.org/ghc/ghc/-/issues/17834 and
https://github.com/PostgREST/postgrest/issues/2627#issuecomment-1435642297.

GHC already seems to acknowledge this, at least to some extent, via
its treatment of unused top-level binding warnings when using
RecordWildCards, RecordPuns, or record patterns, where

  f Foo{ fooX } = ...
or
  f Foo{ fooX = x } = ...

will not emit a -Wunused-top-binds warning for fooX while still
emitting one for fooY, and where

  f Foo{..} = ...

will not emit any -Wunused-top-bind warnings at all.

Given these observations, and assuming that the current HPC behaviour
is undesirable, I’d like some guidance on what the exact desired
behavior for HPC coverage should be for record selectors. In
particular:

* Should a record selector be considered "covered" simply by being
  bound in a pattern match?
* Or should it only be marked as covered if the bound symbol is actually used?

If the latter is preferable, would a change that initially marks them
as covered upon binding (thereby aligning HPC with the treatment of
unused binding warnings) be acceptable as an interim step toward the
larger goal?

Thanks for your time and insights!

From stegeman at gmail.com  Mon Mar 24 06:44:07 2025
From: stegeman at gmail.com (Luite Stegeman)
Date: Mon, 24 Mar 2025 07:44:07 +0100
Subject: GHC 9.6.7 is now available
Message-ID: <CALqQuojq2+oagX5yHcZU3emTJDYGZtLe3L0zOoHX_Qx+jjiBhg@mail.gmail.com>

The GHC developers are very pleased to announce the availability of
GHC 9.6.7. Binary distributions, source distributions, and
documentation are available at

            https://downloads.haskell.org/ghc/9.6.7

We hope to have this release available via ghcup shortly.

GHC 9.6.7 brings number of fixes, including:

- GHC’s internal Unique type has been widened to 64-bits on 32-bit
architectures, avoiding potential miscompilations on large projects.
- Fix a runtime crash when using the compacting GC, caused by black
holes in large objects.
- Added new flags -fspec-eval and -fspec-eval-dictfun to allow
switching off speculative evaluation.

The following libraries have been updated since GHC 9.6.6:

- base-4.18.3.0
- filepath-1.4.301.0
- unix-2.8.6.0
- bytestring-0.11.5.4
- array-0.5.8.0

A more detailed description can be found in the [release notes] and a
full list of changes in [GHC!13841] and [GHC!13891]

Note about Haskell Language Server and building GHC 9.8+:

The change of Unique to 64 bit [GHC#22010] adds the exported symbol
ghc_unique_counter64 to the RTS. Unfortunately it's impossible to
avoid this without breaking other things. If you encounter a linker
error related to ghc_unique_counter64 when building GHC (or building a
GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably
have to add this [fix] to the program you're building.

We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed,
Tweag I/O, Serokell, Equinix, SimSpace, the 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.

Please give this release a try and open a [ticket] if you see anything amiss.

~ Luite

[release notes]:
https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html
[GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841
[GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891
[GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010
[fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743
[ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new

From shayne.fletcher.50 at gmail.com  Mon Mar 24 10:42:00 2025
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Mon, 24 Mar 2025 06:42:00 -0400
Subject: GHC 9.6.7 is now available
In-Reply-To: <CALqQuojq2+oagX5yHcZU3emTJDYGZtLe3L0zOoHX_Qx+jjiBhg@mail.gmail.com>
References: <CALqQuojq2+oagX5yHcZU3emTJDYGZtLe3L0zOoHX_Qx+jjiBhg@mail.gmail.com>
Message-ID: <CAMsAzy_oen0kQXM-kFawmpYVmE0p_dAakbVmwFA+Tucn3dJOog@mail.gmail.com>

the tag ghc repo tag ghc-9.6.7-release has not been created. please fix.

On Mon, Mar 24, 2025 at 2:44 AM Luite Stegeman <stegeman at gmail.com> wrote:

> The GHC developers are very pleased to announce the availability of
> GHC 9.6.7. Binary distributions, source distributions, and
> documentation are available at
>
>             https://downloads.haskell.org/ghc/9.6.7
>
> We hope to have this release available via ghcup shortly.
>
> GHC 9.6.7 brings number of fixes, including:
>
> - GHC’s internal Unique type has been widened to 64-bits on 32-bit
> architectures, avoiding potential miscompilations on large projects.
> - Fix a runtime crash when using the compacting GC, caused by black
> holes in large objects.
> - Added new flags -fspec-eval and -fspec-eval-dictfun to allow
> switching off speculative evaluation.
>
> The following libraries have been updated since GHC 9.6.6:
>
> - base-4.18.3.0
> - filepath-1.4.301.0
> - unix-2.8.6.0
> - bytestring-0.11.5.4
> - array-0.5.8.0
>
> A more detailed description can be found in the [release notes] and a
> full list of changes in [GHC!13841] and [GHC!13891]
>
> Note about Haskell Language Server and building GHC 9.8+:
>
> The change of Unique to 64 bit [GHC#22010] adds the exported symbol
> ghc_unique_counter64 to the RTS. Unfortunately it's impossible to
> avoid this without breaking other things. If you encounter a linker
> error related to ghc_unique_counter64 when building GHC (or building a
> GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably
> have to add this [fix] to the program you're building.
>
> We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed,
> Tweag I/O, Serokell, Equinix, SimSpace, the 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.
>
> Please give this release a try and open a [ticket] if you see anything
> amiss.
>
> ~ Luite
>
> [release notes]:
> https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html
> [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841
> [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891
> [GHC#22010
> <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891%5BGHC#22010>]:
> https://gitlab.haskell.org/ghc/ghc/-/issues/22010
> [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743
> [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250324/1fa29424/attachment.html>

From shayne.fletcher.50 at gmail.com  Mon Mar 24 22:54:40 2025
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Mon, 24 Mar 2025 18:54:40 -0400
Subject: GHC 9.6.7 is now available
In-Reply-To: <CAMsAzy_oen0kQXM-kFawmpYVmE0p_dAakbVmwFA+Tucn3dJOog@mail.gmail.com>
References: <CALqQuojq2+oagX5yHcZU3emTJDYGZtLe3L0zOoHX_Qx+jjiBhg@mail.gmail.com>
 <CAMsAzy_oen0kQXM-kFawmpYVmE0p_dAakbVmwFA+Tucn3dJOog@mail.gmail.com>
Message-ID: <CAMsAzy-9n0L3UfyccAQSRafTHjXuO+rLtPfC4Q5H+-JVWHfChg@mail.gmail.com>

On Mon, Mar 24, 2025 at 6:42 AM Shayne Fletcher <
shayne.fletcher.50 at gmail.com> wrote:

> the tag ghc repo tag ghc-9.6.7-release has not been created. please fix.
>

this is looking resolved. thanks!

-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250324/732314e6/attachment.html>

From ben at well-typed.com  Wed Mar 26 20:38:13 2025
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 26 Mar 2025 16:38:13 -0400
Subject: gitlab.haskell.org outage this weekend
Message-ID: <87pli3sf2z.fsf@smart-cactus.org>

Hi all,

As you may know, Haskell.org is currently in the process of moving its
infrastructure to new hosting facilities. As part of this effort, GHC's
GitLab instance will be taken down for migration on Saturday 29 March
2025 from 09:00 to 17:00.

This includes our issue tracker, CI infrastructure, Docker registry,
serving of artifacts. Apologies for the inconvenience but we hope that
this will be the last time we need to have such a prolonged outage in
quite a while.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250326/2870d5b7/attachment.sig>

From andreash87 at gmx.ch  Thu Mar 27 10:14:36 2025
From: andreash87 at gmx.ch (Andreas Herrmann)
Date: Thu, 27 Mar 2025 11:14:36 +0100
Subject: CFP - Haskell Implementors' Workshop 2025
In-Reply-To: <CA+ouDUjVD8QbSQ7XjYn2z_rkQKBvt=wFQ6zi6W0eCG=AJEKnkw@mail.gmail.com>
References: <CA+ouDUjVD8QbSQ7XjYn2z_rkQKBvt=wFQ6zi6W0eCG=AJEKnkw@mail.gmail.com>
Message-ID: <CA+ouDUhsRbS8eh8euF4PSrVmv5=iSycV1rNmR=bhGHgt1iHW7g@mail.gmail.com>

This is a reminder that the call for proposals for the Haskell
Implementors’ Workshop 2025 is open and the deadline is approaching.
Please submit your proposals until April 4, 2025 using the following link.
https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYnoZ2hYsdw_ZpSfupQ/viewform?usp=header

---

Call for proposals for the
Haskell Implementors' Workshop
https://haskell.foundation/events/2025-haskell-implementors-workshop.html
June 6, 2025

Organized by the Haskell Community
Co-located with ZuriHac 2025 and Haskell Ecosystem Workshop 2025
Hosted by the Haskell Foundation
at Eastern Switzerland University of Applied Sciences (OST)
https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona-campus

## Overview

* Deadline: April 4, 2025
* Notification: May 5, 2025
* Workshop: June 6, 2025

The 17th Haskell Implementors' Workshop is to be held alongside ZuriHac
2025 this year near Zurich. It is a forum for people involved in the design
and development of Haskell implementations, tools, libraries, and
supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and selected by
a small program committee. There will be no published proceedings. The
workshop will be informal and interactive, with open spaces in the
timetable and room for ad-hoc discussion, demos, and lightning talks.

In the past the Haskell Implementors’ Workshop was co-located with ICFP
(International Conference on Functional Programming). However, in recent
years it has become more and more challenging to attract a large enough
audience and sufficiently many speakers for an appealing program. ZuriHac
and the Haskell Ecosystem Workshop have become an important annual
gathering of a large part of the Haskell community. This year the Haskell
Implementors’ Workshop will be co-located with these events to be
accessible to a broader audience.

## Scope and Target Audience

The Haskell Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool, or
even propose future lines of Haskell development. Members of the wider
Haskell community are encouraged to attend the workshop - we need your
feedback to keep the Haskell ecosystem thriving. Students working with
Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics that
people feel we've missed, so by all means submit a proposal even if it
doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimization and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

## Talks

We invite proposals from potential speakers for talks and demonstrations.
We are aiming for 20-minute talks with 5 minutes for questions and
changeovers. We want to hear from people writing compilers, tools, or
libraries, people with cool ideas for directions in which we should take
the platform, proposals for new features to be implemented, and half-baked
crazy ideas.

Submissions can be made via the form linked below until April 4, 2025
(anywhere on earth).
https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYnoZ2hYsdw_ZpSfupQ/viewform?usp=header

We will also have a lightning talks session. Lightning talks should be
~7mins and are scheduled on the day of the workshop. Suggested topics for
lightning talks are to present a single idea, a work-in-progress project, a
problem to intrigue and perplex Haskell implementors, or simply to ask for
feedback and collaborators.

## Program Committee

* Luite Stegeman
* Jaro Reinders
* Emily Pillmore
* Rodrigo Mesquita
* Ian-Woo Kim
* Andreas Herrmann (chair)

## Contact

* Andreas Herrmann

Am Fr., 21. Feb. 2025 um 16:54 Uhr schrieb Andreas Herrmann <
andreash87 at gmx.ch>:

> Call for proposals for the
> Haskell Implementors' Workshop
> https://haskell.foundation/events/2025-haskell-implementors-workshop.html
> June 6, 2025
>
> Organized by the Haskell Community
> Co-located with ZuriHac 2025 and Haskell Ecosystem Workshop 2025
> Hosted by the Haskell Foundation
> at Eastern Switzerland University of Applied Sciences (OST)
>
> https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona-campus
>
> ## Overview
>
> * Deadline: April 4, 2025
> * Notification: May 5, 2025
> * Workshop: June 6, 2025
>
> The 17th Haskell Implementors' Workshop is to be held alongside ZuriHac
> 2025 this year near Zurich. It is a forum for people involved in the design
> and development of Haskell implementations, tools, libraries, and
> supporting infrastructure to share their work and to discuss future
> directions and collaborations with others.
>
> Talks and/or demos are proposed by submitting an abstract, and selected by
> a small program committee. There will be no published proceedings. The
> workshop will be informal and interactive, with open spaces in the
> timetable and room for ad-hoc discussion, demos, and lightning talks.
>
> In the past the Haskell Implementors’ Workshop was co-located with ICFP
> (International Conference on Functional Programming). However, in recent
> years it has become more and more challenging to attract a large enough
> audience and sufficiently many speakers for an appealing program. ZuriHac
> and the Haskell Ecosystem Workshop have become an important annual
> gathering of a large part of the Haskell community. This year the Haskell
> Implementors’ Workshop will be co-located with these events to be
> accessible to a broader audience.
>
> ## Scope and Target Audience
>
> The Haskell Implementors' Workshop is an ideal place to describe a Haskell
> extension, describe works-in-progress, demo a new Haskell-related tool, or
> even propose future lines of Haskell development. Members of the wider
> Haskell community are encouraged to attend the workshop - we need your
> feedback to keep the Haskell ecosystem thriving. Students working with
> Haskell are especially encouraged to share their work.
>
> The scope covers any of the following topics. There may be some topics
> that people feel we've missed, so by all means submit a proposal even if it
> doesn't fit exactly into one of these buckets:
>
> * Compilation techniques
> * Language features and extensions
> * Type system implementation
> * Concurrency and parallelism: language design and implementation
> * Performance, optimization and benchmarking
> * Virtual machines and run-time systems
> * Libraries and tools for development or deployment
>
> ## Talks
>
> We invite proposals from potential speakers for talks and demonstrations.
> We are aiming for 20-minute talks with 5 minutes for questions and
> changeovers. We want to hear from people writing compilers, tools, or
> libraries, people with cool ideas for directions in which we should take
> the platform, proposals for new features to be implemented, and half-baked
> crazy ideas.
>
> Submissions can be made via the form linked below until April 4, 2025
> (anywhere on earth).
>
> https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYnoZ2hYsdw_ZpSfupQ/viewform?usp=header
>
> We will also have a lightning talks session. Lightning talks should be
> ~7mins and are scheduled on the day of the workshop. Suggested topics for
> lightning talks are to present a single idea, a work-in-progress project, a
> problem to intrigue and perplex Haskell implementors, or simply to ask for
> feedback and collaborators.
>
> ## Program Committee
>
> * Luite Stegeman
> * Jaro Reinders
> * Emily Pillmore
> * Rodrigo Mesquita
> * Ian-Woo Kim
> * Andreas Herrmann (chair)
>
> ## Contact
>
> * Andreas Herrmann
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250327/bddc9490/attachment.html>

From Gergo.Erdi at sc.com  Fri Mar 28 08:49:10 2025
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Fri, 28 Mar 2025 08:49:10 +0000
Subject: GHC memory usage when typechecking from source vs. loading
 ModIfaces
In-Reply-To: <CALuQ0m-3iB+2oY1x45FhT+G_OypYo2T0gyzjXUoo3yvm8H6JmA@mail.gmail.com>
References: <CAO7EwMoZPheo=ubP6S5VkTNEuWxSP-BiG0NkfJnMPwA_sg9AQQ@mail.gmail.com>
 <SEYPR03MB74634DE2A8BDE8A481B919AAE91B2@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <pom2vzn7ff2ntiwn7gub7tj2d7dghdfrcqqwjqylrstsv4kvuh@fnspm4m4ji3e>
 <CALuQ0m-fn3rTRs1PgK1WdoV3F8FJnF28HST5aOeEdyrK1L8JyQ@mail.gmail.com>
 <4f980efd-58bc-2814-b4cf-b5742c040b97@erdi.hu>
 <CALuQ0m-6RYuJAMT0kw272E2-R_9LsbJ4ZJPpr7m64ymYnaREVg@mail.gmail.com>
 <SEYPR03MB7463A4ED0988986744263839E9E02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m9FXh4fzhmVRBiFW82rS3W4dPuDnH+7u6yqs3Gwff=B_Q@mail.gmail.com>
 <SEYPR03MB74638EDF52238E57708B6C0EE9F72@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m8VJKXz3y3y3Mv+dK1pFdY2DDVgdWM_oTGPCC51JL5jTg@mail.gmail.com>
 <3a5dd981-7fdc-a814-88c9-6768395cae39@erdi.hu>
 <CALuQ0m__FtS-cfz4TcWXmv2JV1r4-sz1e73RK+JPridQTB0EVQ@mail.gmail.com>
 <CALuQ0m-3iB+2oY1x45FhT+G_OypYo2T0gyzjXUoo3yvm8H6JmA@mail.gmail.com>
Message-ID: <SEYPR03MB7463AABC8385A5FCCCAC330CE9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>

PUBLIC

Hi,

Unfortunately, I am forced to return to this problem. Everything below
is now in the context of GHC 9.12 plus the mutable HPT patch
backported.

My test case is typechecking a tree of 2294 modules that form the
transitive closure of a single module's dependencies, all in a single
process. I have done this typechecking three times, here's what `+RTS
-s -RTS` reports for max residency:

* "cold": With no on-disk `ModIface` files, i.e. from scratch: 537 MB

* "cold-top": With all `ModIface`s already on disk, except for the
  single top-level module: 302 MB

* "warm": With all `ModIface`s already on disk: 211 MB

So my stupidly naive question is, why is the "cold" case also not 302
MB?

In earlier discussion, `ModDetails` unfolding has come up. Dehydrating
`ModDetails` in the HPT all the time is disastrous for runtime, but
based on this model I would expect to see improvements from
dehydrating "every now and then". So I tried a stupid simple example
where after every 100th typechecked module, I run this function on the
topologically sorted list of modules processed so far:


```
dehydrateHpt :: HscEnv -> [ModuleName] -> IO ()
dehydrateHpt hsc_env mods = do
    let HPT{ table = hptr } = hsc_HPT hsc_env
    hpt <- readIORef hptr
    for_ mods \mod -> for_ (lookupUDFM hpt mod) \(HomeModInfo iface _details _linkable) -> do
        !details <- initModDetails hsc_env iface
        pure ()
```

Buuut the max residency is still 534 MB (see "cold-dehydrate"); in
fact, the profile looks exactly the same.

Speaking of the profile, in the "cold" case I see a lot of steadily
increasing heap usage from the `ModuleGraph`. I could see this
happening if typechecking from scratch involves more `modulesUnder`
calls which in turn force more and more of the `ModuleGraph`. If so,
then maybe this could be worked around by repeatedly remaking the
`ModuleGraph` just like I remake the `ModDetails` above. I tried
getting rid of this effect by `deepseq`'ing the `ModuleGraph` at the
start, with the idea being that this should "equalize" the three
scenarios if this really is a substantial source of extra memory
usage. This pushes up the warm case's memory usage to 381 MB, which is
promising, but I still see a `Word64Map` that is steadily increasing
in the "cold-force-modulegraph" case and contributes a lot to the
memory usage. Unfortunately, I don't know where that `Word64Map` is
(it could be any `Unique`-keyed environment...).

So I am now stuck at this point. To spell out my goal explicitly, I
would like to typecheck one module after another and not keep anything
more in memory around than if I loaded them from `ModIface` files.

Thanks,
        Gergo

p.s.: I couldn't find a way in the EventLog
output HTML to turn event markers on/off or filter them, so to avoid
covering the whole graph with gray lines, I mark only every 100th
module.




From: Matthew Pickering <matthewtpickering at gmail.com>
Sent: Wednesday, February 12, 2025 7:08 PM
To: ÉRDI Gergő <gergo at erdi.hu>
Cc: Erdi, Gergo <Gergo.Erdi at sc.com>; Zubin Duggal <zubin at well-typed.com>; Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>; GHC Devs <ghc-devs at haskell.org>
Subject: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

You do also raise a good point about rehydration costs.

In oneshot mode, you are basically rehydrating the entire transitive closure of each module when you compile it, which obviously results in a large amount of repeated work. This is why people are investigating ideas of a persistent worker to at least avoid rehydrating all external dependencies as well.

On Mon, Feb 10, 2025 at 12:13 PM Matthew Pickering <mailto:matthewtpickering at gmail.com> wrote:
Sure, you can remove them once you are sure they are not used anymore.

For clients like `GHCi` that doesn't work obviously as they can be used at any point in the future but for a batch compiler it would be fine.

On Mon, Feb 10, 2025 at 11:56 AM ÉRDI Gergő <mailto:gergo at erdi.hu> wrote:
On Mon, 10 Feb 2025, Matthew Pickering wrote:

> I wonder if you have got your condition the wrong way around.
>
> The only "safe" time to perform rehydration is AFTER the point it can never be used
> again.
>
> If you rehydrate it just before it is used then you will repeat work which has already
> been done. If you do this, you will always have a trade-off between space used and
> runtime.

Oops. Yes, I have misunderstood the idea. I thought the idea was that
after loading a given module into the HPT, its ModDetails would start
out small (because of laziness) and then keep
growing in size as more and more of it are traversed, and thus
forced, during the typechecking of its dependees, so at some point we
would want to reset that into the small initial representation as created
by initModDetails.

But if the idea is that I should rehydrate modules when they can't be used
anymore, then that brings up the question why even do that, instead of
straight removing the HomeModInfos from the HPT?

----------------------------------------------------------------------
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our public website.

----------------------------------------------------------------------
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our main Standard Chartered PLC (UK) website at sc. com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eventlogs.zip
Type: application/x-zip-compressed
Size: 5312675 bytes
Desc: eventlogs.zip
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250328/b69c3dd7/attachment-0001.bin>

From Gergo.Erdi at sc.com  Fri Mar 28 10:12:22 2025
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Fri, 28 Mar 2025 10:12:22 +0000
Subject: GHC memory usage when typechecking from source vs. loading
 ModIfaces
In-Reply-To: <SEYPR03MB7463AABC8385A5FCCCAC330CE9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
References: <CAO7EwMoZPheo=ubP6S5VkTNEuWxSP-BiG0NkfJnMPwA_sg9AQQ@mail.gmail.com>
 <SEYPR03MB74634DE2A8BDE8A481B919AAE91B2@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <pom2vzn7ff2ntiwn7gub7tj2d7dghdfrcqqwjqylrstsv4kvuh@fnspm4m4ji3e>
 <CALuQ0m-fn3rTRs1PgK1WdoV3F8FJnF28HST5aOeEdyrK1L8JyQ@mail.gmail.com>
 <4f980efd-58bc-2814-b4cf-b5742c040b97@erdi.hu>
 <CALuQ0m-6RYuJAMT0kw272E2-R_9LsbJ4ZJPpr7m64ymYnaREVg@mail.gmail.com>
 <SEYPR03MB7463A4ED0988986744263839E9E02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m9FXh4fzhmVRBiFW82rS3W4dPuDnH+7u6yqs3Gwff=B_Q@mail.gmail.com>
 <SEYPR03MB74638EDF52238E57708B6C0EE9F72@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m8VJKXz3y3y3Mv+dK1pFdY2DDVgdWM_oTGPCC51JL5jTg@mail.gmail.com>
 <3a5dd981-7fdc-a814-88c9-6768395cae39@erdi.hu>
 <CALuQ0m__FtS-cfz4TcWXmv2JV1r4-sz1e73RK+JPridQTB0EVQ@mail.gmail.com>
 <CALuQ0m-3iB+2oY1x45FhT+G_OypYo2T0gyzjXUoo3yvm8H6JmA@mail.gmail.com>
 <SEYPR03MB7463AABC8385A5FCCCAC330CE9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
Message-ID: <SEYPR03MB7463EC99669F8723A3156872E9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>

PUBLIC

Just to add that I get the same "equalizing" behaviour (but in a more "natural" way) if instead of deepseq-ing the ModuleGraph upfront, I just call `hugInstancesBelow` before processing each module. So that's definitely one source of extra memory usage. I wonder if it would be possible to rebuild the ModuleGraph periodically (similar to the ModDetails dehydration), or if there are references to it stored all over the place from `HscEnv`s scattered around in closures etc. (basically the same problem the HPT had before it was made into a mutable reference).

-----Original Message-----
From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Erdi, Gergo via ghc-devs
Sent: Friday, March 28, 2025 4:49 PM
To: Matthew Pickering <matthewtpickering at gmail.com>; GHC Devs <ghc-devs at haskell.org>
Cc: ÉRDI Gergő <gergo at erdi.hu>; Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>; Dijkstra, Atze <Atze.Dijkstra at sc.com>
Subject: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

Hi,

Unfortunately, I am forced to return to this problem. Everything below is now in the context of GHC 9.12 plus the mutable HPT patch backported.

My test case is typechecking a tree of 2294 modules that form the transitive closure of a single module's dependencies, all in a single process. I have done this typechecking three times, here's what `+RTS -s -RTS` reports for max residency:

* "cold": With no on-disk `ModIface` files, i.e. from scratch: 537 MB

* "cold-top": With all `ModIface`s already on disk, except for the
  single top-level module: 302 MB

* "warm": With all `ModIface`s already on disk: 211 MB

So my stupidly naive question is, why is the "cold" case also not 302 MB?

In earlier discussion, `ModDetails` unfolding has come up. Dehydrating `ModDetails` in the HPT all the time is disastrous for runtime, but based on this model I would expect to see improvements from dehydrating "every now and then". So I tried a stupid simple example where after every 100th typechecked module, I run this function on the topologically sorted list of modules processed so far:


```
dehydrateHpt :: HscEnv -> [ModuleName] -> IO () dehydrateHpt hsc_env mods = do
    let HPT{ table = hptr } = hsc_HPT hsc_env
    hpt <- readIORef hptr
    for_ mods \mod -> for_ (lookupUDFM hpt mod) \(HomeModInfo iface _details _linkable) -> do
        !details <- initModDetails hsc_env iface
        pure ()
```

Buuut the max residency is still 534 MB (see "cold-dehydrate"); in fact, the profile looks exactly the same.

Speaking of the profile, in the "cold" case I see a lot of steadily increasing heap usage from the `ModuleGraph`. I could see this happening if typechecking from scratch involves more `modulesUnder` calls which in turn force more and more of the `ModuleGraph`. If so, then maybe this could be worked around by repeatedly remaking the `ModuleGraph` just like I remake the `ModDetails` above. I tried getting rid of this effect by `deepseq`'ing the `ModuleGraph` at the start, with the idea being that this should "equalize" the three scenarios if this really is a substantial source of extra memory usage. This pushes up the warm case's memory usage to 381 MB, which is promising, but I still see a `Word64Map` that is steadily increasing in the "cold-force-modulegraph" case and contributes a lot to the memory usage. Unfortunately, I don't know where that `Word64Map` is (it could be any `Unique`-keyed environment...).

So I am now stuck at this point. To spell out my goal explicitly, I would like to typecheck one module after another and not keep anything more in memory around than if I loaded them from `ModIface` files.

Thanks,
        Gergo

p.s.: I couldn't find a way in the EventLog output HTML to turn event markers on/off or filter them, so to avoid covering the whole graph with gray lines, I mark only every 100th module.




From: Matthew Pickering <matthewtpickering at gmail.com>
Sent: Wednesday, February 12, 2025 7:08 PM
To: ÉRDI Gergő <gergo at erdi.hu>
Cc: Erdi, Gergo <Gergo.Erdi at sc.com>; Zubin Duggal <zubin at well-typed.com>; Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>; GHC Devs <ghc-devs at haskell.org>
Subject: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

You do also raise a good point about rehydration costs.

In oneshot mode, you are basically rehydrating the entire transitive closure of each module when you compile it, which obviously results in a large amount of repeated work. This is why people are investigating ideas of a persistent worker to at least avoid rehydrating all external dependencies as well.

On Mon, Feb 10, 2025 at 12:13 PM Matthew Pickering <mailto:matthewtpickering at gmail.com> wrote:
Sure, you can remove them once you are sure they are not used anymore.

For clients like `GHCi` that doesn't work obviously as they can be used at any point in the future but for a batch compiler it would be fine.

On Mon, Feb 10, 2025 at 11:56 AM ÉRDI Gergő <mailto:gergo at erdi.hu> wrote:
On Mon, 10 Feb 2025, Matthew Pickering wrote:

> I wonder if you have got your condition the wrong way around.
>
> The only "safe" time to perform rehydration is AFTER the point it can
> never be used again.
>
> If you rehydrate it just before it is used then you will repeat work
> which has already been done. If you do this, you will always have a
> trade-off between space used and runtime.

Oops. Yes, I have misunderstood the idea. I thought the idea was that after loading a given module into the HPT, its ModDetails would start out small (because of laziness) and then keep growing in size as more and more of it are traversed, and thus forced, during the typechecking of its dependees, so at some point we would want to reset that into the small initial representation as created by initModDetails.

But if the idea is that I should rehydrate modules when they can't be used anymore, then that brings up the question why even do that, instead of straight removing the HomeModInfos from the HPT?

----------------------------------------------------------------------
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our public website.

----------------------------------------------------------------------
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our main Standard Chartered PLC (UK) website at sc. com

----------------------------------------------------------------------
This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries together with Standard Chartered Bank’s Privacy Policy via our main Standard Chartered PLC (UK) website at sc. com

From matthewtpickering at gmail.com  Fri Mar 28 12:40:16 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 28 Mar 2025 12:40:16 +0000
Subject: GHC memory usage when typechecking from source vs. loading
 ModIfaces
In-Reply-To: <SEYPR03MB7463EC99669F8723A3156872E9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
References: <CAO7EwMoZPheo=ubP6S5VkTNEuWxSP-BiG0NkfJnMPwA_sg9AQQ@mail.gmail.com>
 <SEYPR03MB74634DE2A8BDE8A481B919AAE91B2@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <pom2vzn7ff2ntiwn7gub7tj2d7dghdfrcqqwjqylrstsv4kvuh@fnspm4m4ji3e>
 <CALuQ0m-fn3rTRs1PgK1WdoV3F8FJnF28HST5aOeEdyrK1L8JyQ@mail.gmail.com>
 <4f980efd-58bc-2814-b4cf-b5742c040b97@erdi.hu>
 <CALuQ0m-6RYuJAMT0kw272E2-R_9LsbJ4ZJPpr7m64ymYnaREVg@mail.gmail.com>
 <SEYPR03MB7463A4ED0988986744263839E9E02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m9FXh4fzhmVRBiFW82rS3W4dPuDnH+7u6yqs3Gwff=B_Q@mail.gmail.com>
 <SEYPR03MB74638EDF52238E57708B6C0EE9F72@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m8VJKXz3y3y3Mv+dK1pFdY2DDVgdWM_oTGPCC51JL5jTg@mail.gmail.com>
 <3a5dd981-7fdc-a814-88c9-6768395cae39@erdi.hu>
 <CALuQ0m__FtS-cfz4TcWXmv2JV1r4-sz1e73RK+JPridQTB0EVQ@mail.gmail.com>
 <CALuQ0m-3iB+2oY1x45FhT+G_OypYo2T0gyzjXUoo3yvm8H6JmA@mail.gmail.com>
 <SEYPR03MB7463AABC8385A5FCCCAC330CE9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <SEYPR03MB7463EC99669F8723A3156872E9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
Message-ID: <CALuQ0m_FHoDPF8ZV+-441AS22bQbLDrS9GsX-+vaUYD9okrKXA@mail.gmail.com>

HI Gergo,

Do you have a (synthetic?) reproducer? You have probably identified some
memory leak. However, without any means to reproduce it becomes very
difficult to investigate. I feel like we are getting into very precise
details now, where speculating is not going to be so useful.

It seems like this is an important thing for you and your company. Is there
any budget to pay for some investigation? If that was the case then some
effort could be made to create a synthetic producer and make the situation
more robust going into the future if your requirements were precisely
understood.

Cheers,

Matt

On Fri, Mar 28, 2025 at 10:12 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:

> PUBLIC
>
> Just to add that I get the same "equalizing" behaviour (but in a more
> "natural" way) if instead of deepseq-ing the ModuleGraph upfront, I just
> call `hugInstancesBelow` before processing each module. So that's
> definitely one source of extra memory usage. I wonder if it would be
> possible to rebuild the ModuleGraph periodically (similar to the ModDetails
> dehydration), or if there are references to it stored all over the place
> from `HscEnv`s scattered around in closures etc. (basically the same
> problem the HPT had before it was made into a mutable reference).
>
> -----Original Message-----
> From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Erdi, Gergo
> via ghc-devs
> Sent: Friday, March 28, 2025 4:49 PM
> To: Matthew Pickering <matthewtpickering at gmail.com>; GHC Devs <
> ghc-devs at haskell.org>
> Cc: ÉRDI Gergő <gergo at erdi.hu>; Montelatici, Raphael Laurent <
> Raphael.Montelatici at sc.com>; Dijkstra, Atze <Atze.Dijkstra at sc.com>
> Subject: [External] Re: GHC memory usage when typechecking from source vs.
> loading ModIfaces
>
> Hi,
>
> Unfortunately, I am forced to return to this problem. Everything below is
> now in the context of GHC 9.12 plus the mutable HPT patch backported.
>
> My test case is typechecking a tree of 2294 modules that form the
> transitive closure of a single module's dependencies, all in a single
> process. I have done this typechecking three times, here's what `+RTS -s
> -RTS` reports for max residency:
>
> * "cold": With no on-disk `ModIface` files, i.e. from scratch: 537 MB
>
> * "cold-top": With all `ModIface`s already on disk, except for the
>   single top-level module: 302 MB
>
> * "warm": With all `ModIface`s already on disk: 211 MB
>
> So my stupidly naive question is, why is the "cold" case also not 302 MB?
>
> In earlier discussion, `ModDetails` unfolding has come up. Dehydrating
> `ModDetails` in the HPT all the time is disastrous for runtime, but based
> on this model I would expect to see improvements from dehydrating "every
> now and then". So I tried a stupid simple example where after every 100th
> typechecked module, I run this function on the topologically sorted list of
> modules processed so far:
>
>
> ```
> dehydrateHpt :: HscEnv -> [ModuleName] -> IO () dehydrateHpt hsc_env mods
> = do
>     let HPT{ table = hptr } = hsc_HPT hsc_env
>     hpt <- readIORef hptr
>     for_ mods \mod -> for_ (lookupUDFM hpt mod) \(HomeModInfo iface
> _details _linkable) -> do
>         !details <- initModDetails hsc_env iface
>         pure ()
> ```
>
> Buuut the max residency is still 534 MB (see "cold-dehydrate"); in fact,
> the profile looks exactly the same.
>
> Speaking of the profile, in the "cold" case I see a lot of steadily
> increasing heap usage from the `ModuleGraph`. I could see this happening if
> typechecking from scratch involves more `modulesUnder` calls which in turn
> force more and more of the `ModuleGraph`. If so, then maybe this could be
> worked around by repeatedly remaking the `ModuleGraph` just like I remake
> the `ModDetails` above. I tried getting rid of this effect by `deepseq`'ing
> the `ModuleGraph` at the start, with the idea being that this should
> "equalize" the three scenarios if this really is a substantial source of
> extra memory usage. This pushes up the warm case's memory usage to 381 MB,
> which is promising, but I still see a `Word64Map` that is steadily
> increasing in the "cold-force-modulegraph" case and contributes a lot to
> the memory usage. Unfortunately, I don't know where that `Word64Map` is (it
> could be any `Unique`-keyed environment...).
>
> So I am now stuck at this point. To spell out my goal explicitly, I would
> like to typecheck one module after another and not keep anything more in
> memory around than if I loaded them from `ModIface` files.
>
> Thanks,
>         Gergo
>
> p.s.: I couldn't find a way in the EventLog output HTML to turn event
> markers on/off or filter them, so to avoid covering the whole graph with
> gray lines, I mark only every 100th module.
>
>
>
>
> From: Matthew Pickering <matthewtpickering at gmail.com>
> Sent: Wednesday, February 12, 2025 7:08 PM
> To: ÉRDI Gergő <gergo at erdi.hu>
> Cc: Erdi, Gergo <Gergo.Erdi at sc.com>; Zubin Duggal <zubin at well-typed.com>;
> Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>; GHC Devs <
> ghc-devs at haskell.org>
> Subject: [External] Re: GHC memory usage when typechecking from source vs.
> loading ModIfaces
>
> You do also raise a good point about rehydration costs.
>
> In oneshot mode, you are basically rehydrating the entire transitive
> closure of each module when you compile it, which obviously results in a
> large amount of repeated work. This is why people are investigating ideas
> of a persistent worker to at least avoid rehydrating all external
> dependencies as well.
>
> On Mon, Feb 10, 2025 at 12:13 PM Matthew Pickering <mailto:
> matthewtpickering at gmail.com> wrote:
> Sure, you can remove them once you are sure they are not used anymore.
>
> For clients like `GHCi` that doesn't work obviously as they can be used at
> any point in the future but for a batch compiler it would be fine.
>
> On Mon, Feb 10, 2025 at 11:56 AM ÉRDI Gergő <mailto:gergo at erdi.hu> wrote:
> On Mon, 10 Feb 2025, Matthew Pickering wrote:
>
> > I wonder if you have got your condition the wrong way around.
> >
> > The only "safe" time to perform rehydration is AFTER the point it can
> > never be used again.
> >
> > If you rehydrate it just before it is used then you will repeat work
> > which has already been done. If you do this, you will always have a
> > trade-off between space used and runtime.
>
> Oops. Yes, I have misunderstood the idea. I thought the idea was that
> after loading a given module into the HPT, its ModDetails would start out
> small (because of laziness) and then keep growing in size as more and more
> of it are traversed, and thus forced, during the typechecking of its
> dependees, so at some point we would want to reset that into the small
> initial representation as created by initModDetails.
>
> But if the idea is that I should rehydrate modules when they can't be used
> anymore, then that brings up the question why even do that, instead of
> straight removing the HomeModInfos from the HPT?
>
> ----------------------------------------------------------------------
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries together with Standard Chartered Bank’s Privacy
> Policy via our public website.
>
> ----------------------------------------------------------------------
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries together with Standard Chartered Bank’s Privacy
> Policy via our main Standard Chartered PLC (UK) website at sc. com
>
> ----------------------------------------------------------------------
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries together with Standard Chartered Bank’s Privacy
> Policy via our main Standard Chartered PLC (UK) website at sc. com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250328/86f34eb1/attachment.html>

From matthewtpickering at gmail.com  Fri Mar 28 17:52:32 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 28 Mar 2025 17:52:32 +0000
Subject: GHC memory usage when typechecking from source vs. loading
 ModIfaces
In-Reply-To: <CALuQ0m_FHoDPF8ZV+-441AS22bQbLDrS9GsX-+vaUYD9okrKXA@mail.gmail.com>
References: <CAO7EwMoZPheo=ubP6S5VkTNEuWxSP-BiG0NkfJnMPwA_sg9AQQ@mail.gmail.com>
 <SEYPR03MB74634DE2A8BDE8A481B919AAE91B2@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <pom2vzn7ff2ntiwn7gub7tj2d7dghdfrcqqwjqylrstsv4kvuh@fnspm4m4ji3e>
 <CALuQ0m-fn3rTRs1PgK1WdoV3F8FJnF28HST5aOeEdyrK1L8JyQ@mail.gmail.com>
 <4f980efd-58bc-2814-b4cf-b5742c040b97@erdi.hu>
 <CALuQ0m-6RYuJAMT0kw272E2-R_9LsbJ4ZJPpr7m64ymYnaREVg@mail.gmail.com>
 <SEYPR03MB7463A4ED0988986744263839E9E02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m9FXh4fzhmVRBiFW82rS3W4dPuDnH+7u6yqs3Gwff=B_Q@mail.gmail.com>
 <SEYPR03MB74638EDF52238E57708B6C0EE9F72@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m8VJKXz3y3y3Mv+dK1pFdY2DDVgdWM_oTGPCC51JL5jTg@mail.gmail.com>
 <3a5dd981-7fdc-a814-88c9-6768395cae39@erdi.hu>
 <CALuQ0m__FtS-cfz4TcWXmv2JV1r4-sz1e73RK+JPridQTB0EVQ@mail.gmail.com>
 <CALuQ0m-3iB+2oY1x45FhT+G_OypYo2T0gyzjXUoo3yvm8H6JmA@mail.gmail.com>
 <SEYPR03MB7463AABC8385A5FCCCAC330CE9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <SEYPR03MB7463EC99669F8723A3156872E9A02@SEYPR03MB7463.apcprd03.prod.outlook.com>
 <CALuQ0m_FHoDPF8ZV+-441AS22bQbLDrS9GsX-+vaUYD9okrKXA@mail.gmail.com>
Message-ID: <CALuQ0m9Cj3dqaOdxUxn_0Vz3rOChzBGu5xpZMVV=N8gd2cZMsQ@mail.gmail.com>

Hi Gergo,

I quickly tried building `Cabal` with the master branch. There is precisely
1 ModuleGraph allocated for the home session, and precisely one loaded per
interface loaded into the EPS. No leaky behaviour like you can see in your
eventlogs.

It seems there are about 2000 live module graphs in your program, are you
doing something with the API to create this many?

Cheers,

Matt

On Fri, Mar 28, 2025 at 12:40 PM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> HI Gergo,
>
> Do you have a (synthetic?) reproducer? You have probably identified some
> memory leak. However, without any means to reproduce it becomes very
> difficult to investigate. I feel like we are getting into very precise
> details now, where speculating is not going to be so useful.
>
> It seems like this is an important thing for you and your company. Is
> there any budget to pay for some investigation? If that was the case then
> some effort could be made to create a synthetic producer and make the
> situation more robust going into the future if your requirements were
> precisely understood.
>
> Cheers,
>
> Matt
>
> On Fri, Mar 28, 2025 at 10:12 AM Erdi, Gergo <Gergo.Erdi at sc.com> wrote:
>
>> PUBLIC
>>
>> Just to add that I get the same "equalizing" behaviour (but in a more
>> "natural" way) if instead of deepseq-ing the ModuleGraph upfront, I just
>> call `hugInstancesBelow` before processing each module. So that's
>> definitely one source of extra memory usage. I wonder if it would be
>> possible to rebuild the ModuleGraph periodically (similar to the ModDetails
>> dehydration), or if there are references to it stored all over the place
>> from `HscEnv`s scattered around in closures etc. (basically the same
>> problem the HPT had before it was made into a mutable reference).
>>
>> -----Original Message-----
>> From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Erdi, Gergo
>> via ghc-devs
>> Sent: Friday, March 28, 2025 4:49 PM
>> To: Matthew Pickering <matthewtpickering at gmail.com>; GHC Devs <
>> ghc-devs at haskell.org>
>> Cc: ÉRDI Gergő <gergo at erdi.hu>; Montelatici, Raphael Laurent <
>> Raphael.Montelatici at sc.com>; Dijkstra, Atze <Atze.Dijkstra at sc.com>
>> Subject: [External] Re: GHC memory usage when typechecking from source
>> vs. loading ModIfaces
>>
>> Hi,
>>
>> Unfortunately, I am forced to return to this problem. Everything below is
>> now in the context of GHC 9.12 plus the mutable HPT patch backported.
>>
>> My test case is typechecking a tree of 2294 modules that form the
>> transitive closure of a single module's dependencies, all in a single
>> process. I have done this typechecking three times, here's what `+RTS -s
>> -RTS` reports for max residency:
>>
>> * "cold": With no on-disk `ModIface` files, i.e. from scratch: 537 MB
>>
>> * "cold-top": With all `ModIface`s already on disk, except for the
>>   single top-level module: 302 MB
>>
>> * "warm": With all `ModIface`s already on disk: 211 MB
>>
>> So my stupidly naive question is, why is the "cold" case also not 302 MB?
>>
>> In earlier discussion, `ModDetails` unfolding has come up. Dehydrating
>> `ModDetails` in the HPT all the time is disastrous for runtime, but based
>> on this model I would expect to see improvements from dehydrating "every
>> now and then". So I tried a stupid simple example where after every 100th
>> typechecked module, I run this function on the topologically sorted list of
>> modules processed so far:
>>
>>
>> ```
>> dehydrateHpt :: HscEnv -> [ModuleName] -> IO () dehydrateHpt hsc_env mods
>> = do
>>     let HPT{ table = hptr } = hsc_HPT hsc_env
>>     hpt <- readIORef hptr
>>     for_ mods \mod -> for_ (lookupUDFM hpt mod) \(HomeModInfo iface
>> _details _linkable) -> do
>>         !details <- initModDetails hsc_env iface
>>         pure ()
>> ```
>>
>> Buuut the max residency is still 534 MB (see "cold-dehydrate"); in fact,
>> the profile looks exactly the same.
>>
>> Speaking of the profile, in the "cold" case I see a lot of steadily
>> increasing heap usage from the `ModuleGraph`. I could see this happening if
>> typechecking from scratch involves more `modulesUnder` calls which in turn
>> force more and more of the `ModuleGraph`. If so, then maybe this could be
>> worked around by repeatedly remaking the `ModuleGraph` just like I remake
>> the `ModDetails` above. I tried getting rid of this effect by `deepseq`'ing
>> the `ModuleGraph` at the start, with the idea being that this should
>> "equalize" the three scenarios if this really is a substantial source of
>> extra memory usage. This pushes up the warm case's memory usage to 381 MB,
>> which is promising, but I still see a `Word64Map` that is steadily
>> increasing in the "cold-force-modulegraph" case and contributes a lot to
>> the memory usage. Unfortunately, I don't know where that `Word64Map` is (it
>> could be any `Unique`-keyed environment...).
>>
>> So I am now stuck at this point. To spell out my goal explicitly, I would
>> like to typecheck one module after another and not keep anything more in
>> memory around than if I loaded them from `ModIface` files.
>>
>> Thanks,
>>         Gergo
>>
>> p.s.: I couldn't find a way in the EventLog output HTML to turn event
>> markers on/off or filter them, so to avoid covering the whole graph with
>> gray lines, I mark only every 100th module.
>>
>>
>>
>>
>> From: Matthew Pickering <matthewtpickering at gmail.com>
>> Sent: Wednesday, February 12, 2025 7:08 PM
>> To: ÉRDI Gergő <gergo at erdi.hu>
>> Cc: Erdi, Gergo <Gergo.Erdi at sc.com>; Zubin Duggal <zubin at well-typed.com>;
>> Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>; GHC Devs <
>> ghc-devs at haskell.org>
>> Subject: [External] Re: GHC memory usage when typechecking from source
>> vs. loading ModIfaces
>>
>> You do also raise a good point about rehydration costs.
>>
>> In oneshot mode, you are basically rehydrating the entire transitive
>> closure of each module when you compile it, which obviously results in a
>> large amount of repeated work. This is why people are investigating ideas
>> of a persistent worker to at least avoid rehydrating all external
>> dependencies as well.
>>
>> On Mon, Feb 10, 2025 at 12:13 PM Matthew Pickering <mailto:
>> matthewtpickering at gmail.com> wrote:
>> Sure, you can remove them once you are sure they are not used anymore.
>>
>> For clients like `GHCi` that doesn't work obviously as they can be used
>> at any point in the future but for a batch compiler it would be fine.
>>
>> On Mon, Feb 10, 2025 at 11:56 AM ÉRDI Gergő <mailto:gergo at erdi.hu> wrote:
>> On Mon, 10 Feb 2025, Matthew Pickering wrote:
>>
>> > I wonder if you have got your condition the wrong way around.
>> >
>> > The only "safe" time to perform rehydration is AFTER the point it can
>> > never be used again.
>> >
>> > If you rehydrate it just before it is used then you will repeat work
>> > which has already been done. If you do this, you will always have a
>> > trade-off between space used and runtime.
>>
>> Oops. Yes, I have misunderstood the idea. I thought the idea was that
>> after loading a given module into the HPT, its ModDetails would start out
>> small (because of laziness) and then keep growing in size as more and more
>> of it are traversed, and thus forced, during the typechecking of its
>> dependees, so at some point we would want to reset that into the small
>> initial representation as created by initModDetails.
>>
>> But if the idea is that I should rehydrate modules when they can't be
>> used anymore, then that brings up the question why even do that, instead of
>> straight removing the HomeModInfos from the HPT?
>>
>> ----------------------------------------------------------------------
>> This email and any attachments are confidential and may also be
>> privileged. If you are not the intended recipient, please delete all copies
>> and notify the sender immediately. You may wish to refer to the
>> incorporation details of Standard Chartered PLC, Standard Chartered Bank
>> and their subsidiaries together with Standard Chartered Bank’s Privacy
>> Policy via our public website.
>>
>> ----------------------------------------------------------------------
>> This email and any attachments are confidential and may also be
>> privileged. If you are not the intended recipient, please delete all copies
>> and notify the sender immediately. You may wish to refer to the
>> incorporation details of Standard Chartered PLC, Standard Chartered Bank
>> and their subsidiaries together with Standard Chartered Bank’s Privacy
>> Policy via our main Standard Chartered PLC (UK) website at sc. com
>>
>> ----------------------------------------------------------------------
>> This email and any attachments are confidential and may also be
>> privileged. If you are not the intended recipient, please delete all copies
>> and notify the sender immediately. You may wish to refer to the
>> incorporation details of Standard Chartered PLC, Standard Chartered Bank
>> and their subsidiaries together with Standard Chartered Bank’s Privacy
>> Policy via our main Standard Chartered PLC (UK) website at sc. com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250328/9ba11ce3/attachment.html>

From ben at well-typed.com  Sat Mar 29 13:17:26 2025
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 29 Mar 2025 09:17:26 -0400
Subject: gitlab.haskell.org outage this weekend
In-Reply-To: <87pli3sf2z.fsf@smart-cactus.org>
References: <87pli3sf2z.fsf@smart-cactus.org>
Message-ID: <87bjtkrn6v.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hi all,
>
> As you may know, Haskell.org is currently in the process of moving its
> infrastructure to new hosting facilities. As part of this effort, GHC's
> GitLab instance will be taken down for migration on Saturday 29 March
> 2025 from 09:00 to 17:00.
>
Hi all,

I will be taking down GitLab shortly for the final migration.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250329/1fb34cff/attachment.sig>

From ben at well-typed.com  Sun Mar 30 03:02:06 2025
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 29 Mar 2025 23:02:06 -0400
Subject: gitlab.haskell.org outage this weekend
In-Reply-To: <87bjtkrn6v.fsf@smart-cactus.org>
References: <87pli3sf2z.fsf@smart-cactus.org> <87bjtkrn6v.fsf@smart-cactus.org>
Message-ID: <878qonrzkv.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Ben Gamari <ben at well-typed.com> writes:
>
>> Hi all,
>>
>> As you may know, Haskell.org is currently in the process of moving its
>> infrastructure to new hosting facilities. As part of this effort, GHC's
>> GitLab instance will be taken down for migration on Saturday 29 March
>> 2025 from 09:00 to 17:00.
>>
> Hi all,
>
> I will be taking down GitLab shortly for the final migration.
>
Hi all,

GItLab has been up since 17:30 but I have been a bit quiet since CI is
still a bit wobbly due to Docker issues. I am looking into the issue but
I am afraid I will need to suspend work for today. I'll be returning
this for what time I can tomorrow and otherwise will continue on Monday.

Apologies for the inconvenience.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250329/1e068bce/attachment.sig>

From ben at well-typed.com  Mon Mar 31 20:31:44 2025
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 31 Mar 2025 16:31:44 -0400
Subject: gitlab.haskell.org reboot this evening
Message-ID: <875xjprlgf.fsf@smart-cactus.org>

Hi all,

As part of finalizing the migration I will be rebooting
gitlab.haskell.org at 17:00 EDT today. I expect the outage will last
around 5 minutes.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 861 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250331/bfb14de3/attachment.sig>