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. Moritz On Tue, 17 May 2022 at 1:27 AM, Ben Gamari wrote: > 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 > we shouldn't worry lose any sleep over it. On the other hand, spam > content is quite problematic and we should strive to eliminate it. > Once every few months I take a bit of time and do some cleaning (with > some mechanical help [1]). It's also helpful when users use GitLab's > "Report Abuse" feature to flag spam accounts as these cases are very > easy to handle. > > Cheers, > > - Ben > > > [1] > https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/gitlab-utils/gitlab_utils/spam_util.py > > ___ > 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: 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/ghc-proposals/ghc-proposals/pull/448, I
> think there is no way to avoid the ambiguity when setting `field`. Is
> that correct? If so, what shall we do about it? The natural answer is
> somehow to write ... MkRec { field @a = ... } ... but that would
> break significant new syntactic ground. (Maybe it's good new
> syntactic ground, but it would still be very new.)
I’m probably revealing ignorance of #448 this way, but why would
MkRec { field = \@a -> ...}
not work with -XTypeAbstractions
Cheers,
Joachim
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 be OK.
Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 right thing. Indeed, I interpret your
proposed `field @a = ...` as much the same.
Sebastian
-- Originalnachricht --
Von: "Richard Eisenberg"
An: "Erdi, Gergo via ghc-devs"
Gesendet: 16.05.2022 21:09:33
Betreff: 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, I
think there is no way to avoid the ambiguity when setting `field`. Is
that correct? If so, what shall we do about it? The natural answer is
somehow to write ... MkRec { field @a = ... } ... but that would break
significant new syntactic ground. (Maybe it's good new syntactic
ground, but it would still be very new.)
Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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
, I think there is no
way to avoid the ambiguity when setting `field`. Is that correct? If so, what
shall we do about it? The natural answer is somehow to write ... MkRec { field
@a = ... } ... but that would break significant new syntactic ground. (Maybe
it's good new syntactic ground, but it would still be very new.)
Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 we shouldn't worry lose any sleep over it. On the other hand, spam content is quite problematic and we should strive to eliminate it. Once every few months I take a bit of time and do some cleaning (with some mechanical help [1]). It's also helpful when users use GitLab's "Report Abuse" feature to flag spam accounts as these cases are very easy to handle. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/gitlab-utils/gitlab_utils/spam_util.py signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 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 intend to address it right now, I'd like to at least know what kind of effect this is having on GHC devs. There have already been 50+ users added today, and a random sample was 100% spam. There are 84,000 users and 1700 projects in the system in total. I assume 90-99% of them are spam. Not really conducive to a balanced diet. -Bryan "eat more veggies" Richter ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 intend to address it right now, I'd like to at least know what kind of effect this is having on GHC devs. There have already been 50+ users added today, and a random sample was 100% spam. There are 84,000 users and 1700 projects in the system in total. I assume 90-99% of them are spam. Not really conducive to a balanced diet. -Bryan "eat more veggies" Richter___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 using this email address (and chreekat / @b:chreekat.net on IRC, Slack, and Matrix) for contact points. Feel free to reach out to say hi or complain about failed CI jobs. :) See ya, -Bryan --- Original Message --- On Monday, May 16th, 2022 at 12:58, Hécate wrote: > > > 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 > > infrastructure and other devops tasks. If you see him around make sure > > to say hello, especially if you've got a complaint about CI ;) > > > > His username is chreekat. > > > > Cheers, > > > > Matt > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- > Hécate ✨ > : @TechnoEmpress > IRC: Hecate > WWW: https://glitchbra.in > RUN: BSD > > ___ > 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: 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 infrastructure and other devops tasks. If you see him around make sure to say hello, especially if you've got a complaint about CI ;) His username is chreekat. Cheers, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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, especially if you've got a complaint about CI ;) His username is chreekat. Cheers, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
