GSOC Idea: Bytecode serialization and/or Fat Interface files

Ben Gamari ben at smart-cactus.org
Sun Mar 14 01:00:48 UTC 2021


John Ericson <john.ericson at obsidian.systems> writes:

> Yes, see 
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output 
> where we (Obsidian) and IOHK have been planning together.
>
> I must saw, I am a bit skeptical about a GSOC being able to take this on 
> successfully. I thought Fendor did a great job with multiple home units, 
> for example, but we have still to finish merging all his work! The 
> driver is perhaps the biggest cesspool of technical debt in GHC, and it 
> will take a while to untangle let alone implement new features.
>
> I forget what the rules are for more incremental or multifaceted 
> projects, but I would prefer an approach of trying to untangle things 
> with no singular large goal. Or maybe we can involve a student with 
> efforts to improve CI, attacking the root cause for why it's so hard to 
> land things in the first place .
>
I think this would be ill-suited to a GSoC project. GSoC projects are
strongly encouraged to be measurable projects with a clear development
trajectory from the outset and multiple concrete checkpoints. If we want
the project to be successful I think it would be a mistake to wander
from this guidance.

Cheers,

- Ben

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


More information about the ghc-devs mailing list