Re: gitlab spam

The second one is an issue if it consumes CI Ressource. Ideally we’d have only “blessed” repos allowed to consume CI. The issue with this is that (random) new users can’t fork GHC and have CI run against their change. I’d still very much like to see a solution to this; it is a security concern. M

Re: ambiguous record field (but not *that* kind of ambiguous record field)

Hi, Am Montag, dem 16.05.2022 um 19:09 + schrieb Richard Eisenberg: > Hi all, > > On a project I'm working on, I wish to declare something like > > data Rec = MkRec { field :: forall a. SomeConstraint a => ... } > > where the ... contains no mention of `a`. > > Even with https://github.com

Re: ambiguous record field (but not *that* kind of ambiguous record field)

> On May 16, 2022, at 3:45 PM, Sebastian Graf wrote: > > MkRec { field = \@a -> ... } Hm -- perhaps you're right. I may have gotten myself all worked up over nothing. I was worried that unification would get confused, not sure that the `a`s match up. But I now think I was wrong -- it should

Re: ambiguous record field (but not *that* kind of ambiguous record field)

Hi Richard, I'm not sure if I'm missing something, but my adolescent naivety in frontend matters would try to reach for https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0155-type-lambda.rst#motivation and write MkRec { field = \@a -> ... } and I hope that will do the ri

ambiguous record field (but not *that* kind of ambiguous record field)

Hi all, On a project I'm working on, I wish to declare something like data Rec = MkRec { field :: forall a. SomeConstraint a => ... } where the ... contains no mention of `a`. Even with https://github.com/ghc-proposals/ghc-proposals/pull/448

Re: gitlab spam

Bryan and I discussed this in person but I'll repeat what I said there here: In short, there are two kinds of spam: * user creation without the creation of any other content * spam content (primarily projects and snippets) My sense is that the former has thusfar been harmless and consequently

Re: gitlab spam

No visible effect on my part, but I would agree that it's not something we should keep. :) Le 16/05/2022 à 15:52, Bryan a écrit : While familiarizing myself with gitlab.haskell.org, I noticed there's a ton of spam users and projects. Does this have any practical effect on any of you? Who (if

gitlab spam

While familiarizing myself with gitlab.haskell.org, I noticed there's a ton of spam users and projects. Does this have any practical effect on any of you? Who (if anyone) is the moderation team that handles abuse reports? While I don't think it's a high-priority concern for myself and I don't i

Re: Welcome to Bryan (Devops Engineer)

Hello, glad to be here with the new role! I've transitioned from lurker to active participant. :) I'm looking forward to stabilizing CI and making it more useful to you all. My HF address is bryan@haskell.foundation, although in the blurry space of open source development I'll probably keep usi

Re: Welcome to Bryan (Devops Engineer)

Hi Bryan, welcome aboard! Le 16/05/2022 à 11:57, Matthew Pickering a écrit : Hi all, Bryan has been hired by the Haskell foundation to work on devops problems in the Haskell ecosystem. His first day is today! At least initially he will be working closely with the GHC team to shore up CI infrast

Welcome to Bryan (Devops Engineer)

Hi all, Bryan has been hired by the Haskell foundation to work on devops problems in the Haskell ecosystem. His first day is today! At least initially he will be working closely with the GHC team to shore up CI infrastructure and other devops tasks. If you see him around make sure to say hello, es