Nice!
Other good news is that I lost track of all the Mac runners we actually
have, and our current capacity is actually 3/6 rather than 1/4.
On Wed, 28 Jun 2023 at 09:15, Rodrigo Mesquita
wrote:
> The root of the second problem was !10723, which started failing on its
> own pipeline after bein
The root of the second problem was !10723, which started failing on its own
pipeline after being rebased.
I’m pushing a fix.
- Rodrigo
> On 28 Jun 2023, at 06:41, Bryan Richter via ghc-devs
> wrote:
>
> Two things are negatively impacting GHC CI right now:
>
> Darwin runner capacity is down
Two things are negatively impacting GHC CI right now:
Darwin runner capacity is down to one machine, since the other three are
paused. The problem and solution are known[1], but until the fix is
implemented in GHC, expect pipelines to get backed up. I will work on a
patch this morning
[1]: https:
On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:
> In short, why are the design considerations for stack frames different to
> heap objects? I think of a stack frame simply as a heap object that
> happens to be allocated on the stack
>
I agree with this pe
Moritz Angermann writes:
> Hi Shiwei,
>
> Let me try to draw up a more visual representation do the current pipelines
> over the weekend. That might also explain why I think the subset might work
> as the intermediate steps *do* carry register width.
>
> Cheers,
> Moritz
>
> On Thu, 8 Jun 2023 a
Adding David fyi, who is working on riscv64 bootstrapping for Fedora
On Wed, 14 Jun 2023 at 20:59, Bryan Richter via ghc-devs <
ghc-devs@haskell.org> wrote:
> Hello!
>
> I can't assist with RISC-V, but let me know if you have any trouble with
> https://gitlab.haskell.org. In particular, approving
Ah - my bet is that the hospital's IT department were simply blocking ssh
as a "better safe than sorry" infosec policy.
On Tue, 27 Jun 2023 at 12:37, Simon Peyton Jones <
simon.peytonjo...@gmail.com> wrote:
> Thanks for following up.
>
> I came home from hospital, and it was fine at home. Maybe
One common technique is to put all the MR instructions gobbedlygook into a
, so they don't end up in the actual description. I
kind of agree the gobbeldy gook should be on the wiki, though, with a
simple in the
actual template itself. But even that kind of falls down because the link
wouldn't actu
Thanks for following up.
I came home from hospital, and it was fine at home. Maybe there was
something strange in their Wifi. If I was there for longer I'd have had
to investigate more (somehow) but it was a thankfully brief stay.
Simon
On Tue, 27 Jun 2023 at 07:29, Bryan Richter
wrote:
> H
>
> The majority of contributors don't have the rights to modify labels on
> merge requests. It might be good to add a few words of advice for that
> group: What should *they* do if their MR needs attention?
>
Oh! That is bad. It's no good us saying "add label X" if they can't add a
label. Can
Thanks for a clear writeup, Alexis.
My instinct is to do it all with closure types, not pointer comparison.
-
>
> Con: Adding more closure types unnecessarily pollutes code that branches
> on closure types, like the garbage collector.
>
-
>
> Con: Adding more closure types unnecessarily pollutes c
11 matches
Mail list logo
