GHC plugin authors?

Wed Sep 1 09:37:44 UTC 2021

> With regards to point 2. if I understand correctly, the gitlab CI creates
> bindists as build artifacts, is that correct?
> I guess it would be helpful if that were advertised more prominently, so
> it's easier to test a new branch without having to build GHC.

Yes, they are. Let's take this MR for example (I just picked a random green
one)
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6452
If you look at the associated CI pipeline:
https://gitlab.haskell.org/ghc/ghc/-/pipelines/40166
You'll find the x86_64-deb-debug validate build here:
https://gitlab.haskell.org/ghc/ghc/-/jobs/774465
Which on the right side has "Job artifacts", clicking "browse" there leads
us to: https://gitlab.haskell.org/ghc/ghc/-/jobs/774465/artifacts/browse
from where we can obtain
https://gitlab.haskell.org/ghc/ghc/-/jobs/774465/artifacts/file/ghc-x86_64-deb9-linux-debug.tar.xz

Hope this helps, it's not very trivial, but at least this should give
directions on how to get the artifacts.
There are also nightly builds which have the artifacts attached as well.

On Wed, Sep 1, 2021 at 10:46 AM Christiaan Baaij <christiaan.baaij at gmail.com>
wrote:

> Hi Richard,
>
> So there's multiple reasons/aspects as to why I haven't responded
> 1. Sam's question/seeking feedback on changing the return type for
> constraint solver plugins is something Sam and I discussed at HIW using
> ICFPs airmeet instance, as in, it was something I suggested.
>
> And the TL;DR of next three reasons: I can't find enough time / need to
> get better at time management / need to hand over work
> 2. While I've had to maintain the
> ghc-typelits-{natnormalize;knownnat;extra} constraint solver plugins as
> part of maintaining my (and our company's) livelihood, I usually only try
> the next version of the GHC module collection (API) when there's a binary
> dist of like an alpha or RC.
> 3. I guess I've become conditioned to just do the regular impedance
> matching for every new major GHC release, as can be witnessed by the
> following CPP extravaganza:
> https://github.com/clash-lang/ghc-typelits-natnormalise/blob/3f3ae60a796061b7a496f64ba71f4d57dedd01db/src/GHC/TypeLits/Normalise.hs#L181-L316
> 4. I'm a day-time-only programmer, and with our company growing I've had
> less time for coding and maintaining software.
>
> With regards to point 2. if I understand correctly, the gitlab CI creates
> bindists as build artifacts, is that correct?
> I guess it would be helpful if that were advertised more prominently, so
> it's easier to test a new branch without having to build GHC.
>
> With regards to point 3. The "blessed" GHC API, i.e. the module called
> "GHC", "Plugins", "TcPlugins" (I forgot what their new names are in the
> post ghc 9.0 era), were never enough to get everything done that needed to
> be done.
> That meant one had to reach out to the GHC module collection, which, for
> good reasons (the type and constraint system is always under heavy
> development), is changing with every major GHC release.
> I guess (constraint solving) plugin creators whose day-job or hobby
> doesn't include maintaining plugins got burned out by having to keep up
> with these changes.
> So I wonder how many constraint-solving plugins currently compile against
> GHC 9.0, let alone GHC 9.2; and as a consequence I wonder how many people
> are interested in these API changes (since they stopped maintaining their
> plugins).
>
> Perhaps they are interested though! But simply not registered to this
> mailing list. So asking for feedback on both the haskell discourse and the
> haskell sub-reddit certainly wouldn't hurt!
>
> Finally, with regards to point 4. Constraint-solving plugins certainly
> required some time to get into.
> So often my colleagues look to me whenever there's a new alpha or RC out
> to upgrade the plugins.
> But Sam's changes for solving type family constraints certainly give the
> impression that things will easier going forward!
> So now is probably the best time to hand over the baton to one of my
> colleagues and hopefully they can provide the asked-for feedback.
>
> On Wed, 1 Sept 2021 at 09:21, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Hi Richard,
>>
>> I believe that this is mostly due to plugin development happening to
>> satisfy a plugin need.  I doubt there is a grand unified vision for
>> plugins.  And I don't have one either.  I've dabbled with codegen plugins a
>> long time ago, these days I'm primarily concerned with plugins having a
>> chance to work in cross compilation settings, and even that is still a very
>> uncharted area, but Luite has come up with a hack and Sylvain is making
>> progress :-) We still don't have the cabal side fixes, where we'd need some
>> `plugin-depends` stanza, but all that only makes sense, once we have the
>> fundamentals for plugins disentangled in ghc.
>>
>> I agree that a discussion on discourse might help.  But we won't know
>> without trying.
>>
>> On Tue, Aug 31, 2021 at 9:34 PM Richard Eisenberg <lists at richarde.dev>
>> wrote:
>>
>>> Hi all,
>>>
>>> I have seen a few posts from Sam Derbyshire here asking for feedback
>>> about plugin API design, and the responses have been minimal. This poses a
>>> design challenge, because the GHC folk who design the interface are
>>> sometimes distinct from the people who use the interface. We're trying to
>>> be good, seeking feedback from real, live clients. Is there a better way to
>>> do so than this mailing list? Example: we could create a Category on
>>> discourse.haskell.org, if that would reach the audience better. Or we
>>> could make a repo with issue trackers somewhere simply to track plugin
>>> design. What would work?
>>>
>>> (I recognize that I'm asking in a perhaps-ineffective channel for
>>> advice, but I really don't have a better idea right now. Maybe some of you
>>> plugin authors are here and will point us in a better direction.)
>>>
>>> Thanks,
>>> Richard
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> 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/20210901/f9218cb5/attachment.html>