June 2022 - ghc-devs - Haskell.org

Re: GHC code size
by Bryan Richter 15 Jun '22

15 Jun '22

A quick googling discovered https://githubnext.com/projects/repo-visualization, which has some of the desired features. :) (CC'ing the author and team mentioned in the article, too.) Has: * very visual * subdirectory breakdown * filetype breakdown Doesn't have: * Separating code from comments * History is listed under "future work" * Drop-in support for gitlab (it's presented as a GitHub Action) The article has an interactive widget you can point at a repo. I pointed it at ghc/ghc, and although my browser is still churning ten minutes later, here's a preview. It's pretty cool! On 14/06/2022 16:20, Hécate wrote: > > I'm taking the liberty of forwarding this to Bryan, as he's in a > unique position to help on this front. :) > > Le 14/06/2022 à 16:18, Simon Peyton Jones a écrit : >> Thanks Hecate. I used your figures in my talk. Really helpful. >> >> A note to all ghc-devs: it's be lovely to have a regularly-updated >> summary visualisation of GHC's source code: >> >> * Separating code from comments >> * Broken up by sub-directory >> * As visual as possible >> * Ideally with some kind of historical time-line ability >> >> This can't be new. Zillions of GitHub repositories could be >> visualised like this. There must be prior art; probably a lot of >> it. Can we just press a button and get it? >> >> Simon >> >> On Fri, 10 Jun 2022 at 17:45, Hécate <hecate(a)glitchbra.in> wrote: >> >> If you don't have a nix shell handy, here is what I'm getting: >> >> ❯ cloc compiler rts driver >> 1148 text files. >> 1137 unique files. >> 108 files ignored. >> >> github.com/AlDanial/cloc <http://github.com/AlDanial/cloc> v >> 1.88 T=1.31 s (794.3 files/s, 431269.4 lines/s) >> --------------------------------------------------------------------------------------- >> Language files blank >> comment code >> --------------------------------------------------------------------------------------- >> Haskell 635 68541 >> 140216 231567 >> C 158 10529 >> 16953 51162 >> C/C++ Header 209 4329 >> 8984 14536 >> yacc 2 971 >> 10 5024 >> Logos 3 530 >> 0 3642 >> Pascal 1 661 >> 936 2312 >> make 14 252 >> 409 850 >> Windows Module Definition 7 27 >> 0 489 >> Assembly 5 76 >> 269 478 >> Puppet 1 106 >> 0 445 >> Python 1 32 >> 19 162 >> D 1 16 >> 42 60 >> YAML 1 6 10 18 >> Lisp 1 2 4 7 >> Windows Resource File 1 0 0 1 >> --------------------------------------------------------------------------------------- >> SUM: 1040 86078 >> 167852 310753 >> --------------------------------------------------------------------------------------- >> >> Le 10/06/2022 à 18:29, chessai a écrit : >>> You might be able to do something with cloc and a shell script >>> for a rough estimate. >>> >>> ``` >>> $ cd ghc >>> $ nix-shell -p clock --run "cloc ." >>> ``` >>> >>> will output a detailed report of the loc and language breakdown >>> of the top level ghc directory (it is comment-aware and aware of >>> many languages). there might be a way to get cloc or a similar >>> tool to output something more inspect able (eg json), and then >>> use a shell script to gather everything from the appropriate >>> directories/files. >>> >>> I suspect something could be hacked up in less than a day, but >>> it would require a bit of research. Hopefully this is helpful >>> and gets you going - I'd be happy to hear of better solutions. >>> >>> Thanks >>> >>> On Fri, Jun 10, 2022, 11:20 Simon Peyton Jones >>> <simon.peytonjones(a)gmail.com> wrote: >>> >>> Dear GHC devs >>> >>> Is it possible to get a "lines-of-code" summary of GHC these >>> days? Like the one below, from 2011. >>> >>> It needs more than `wc` because it's helpful to split lines >>> of code from lines of comments and notes. >>> >>> We used to have `count_lines` but I'm not sure whether it is >>> still extant. >>> >>> I'm giving a talk at Zurihac on Sunday morning, about the >>> internals of GHC. Any data before then, preferably in a >>> form comparable to that below, would be terrific. >>> >>> But you have a lot else to do. This isn't do-or-die, just >>> nice to have. >>> >>> Thanks >>> >>> Simon >>> >>> image.png >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)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(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW:https://glitchbra.in > RUN: BSD

6 5

Type vs Constraint
by Simon Peyton Jones 13 Jun '22

13 Jun '22

Dear GHC devs and Core Libraries folk The tension between Type and Constraint (are they equal or not?) has plaugued GHC for years. This GHC proposal #518 <https://github.com/ghc-proposals/ghc-proposals/pull/518> suggests how to fix it. Please do offer your thoughts. Simon

1 0

GHC code size
by Simon Peyton Jones 10 Jun '22

10 Jun '22

Dear GHC devs Is it possible to get a "lines-of-code" summary of GHC these days? Like the one below, from 2011. It needs more than `wc` because it's helpful to split lines of code from lines of comments and notes. We used to have `count_lines` but I'm not sure whether it is still extant. I'm giving a talk at Zurihac on Sunday morning, about the internals of GHC. Any data before then, preferably in a form comparable to that below, would be terrific. But you have a lot else to do. This isn't do-or-die, just nice to have. Thanks Simon [image: image.png]

3 2

GitLab bullets
by Simon Peyton Jones 10 Jun '22

10 Jun '22

Ben GitLab's rendering has become broken. See this ticket https://gitlab.haskell.org/ghc/ghc/-/issues/20686 - look under "Common ground...". The bullets all have a newline after them - Ditto the numbered points under "Generalisation" - But some bullets under "Generalisation" are OK. - Bullets have a handle that seems to let you drag the bullet around. But if you do so, it messa up the format completely! Ben, can you revert this Gitlab change? Simon

3 3

Haddock needs help
by Hécate 09 Jun '22

09 Jun '22

Hi everyone, Haddock needs help. Since I joined the Haddock team to help triage the tickets and interact with the community, we lost all of our experts, and I didn't have time to level up quickly enough to handle the mass of incoming tickets, let alone actually reduce the number of tickets to number below two hundred. As things stand now, the Haddock code base is in a disastrous state, largely not understood and its CI is in shambles. There are things that we can improve on the short and longer term – see https://github.com/haskell/haddock/issues/1465 – but the greater lack of expertise means that any project involving some core business logic is bound to be utterly and unnecessarily painful. The Hi Haddock GSOC proposal, whilst fully implemented in GHC, cannot be brought in Haddock at this moment in a reasonable timeline without any help. At present time, I need: * People who can refactor the code base, following modern software engineering practices, like domain-driven design and test-driven development. * UI developers, proficient in CSS and web accessibility. If you feel like you fit some of these criteria, please do contact me at this address. If your company can spare some engineering hours for you to give a hand, you're most welcome to do so. Just so we are clear, I am immensely grateful to the people who have submitted fixes and patches these past months, but this situation is untenable. Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

3 3

GitLab upgrade starting shortly
by Ben Gamari 09 Jun '22

09 Jun '22

Hello all, I will be starting the GitLab upgrade shortly. Expect approximately 30 minutes of downtime. Cheers, - Ben

2 5

Two-factor authentication enforced on gitlab.haskell.org
by Ben Gamari 08 Jun '22

08 Jun '22

Hi all, Due to a recent up-tick in spam activity, we have started enforcing two-factor authentication on gitlab.haskell.org. We hope that this isn't too much of a burden, but do let us know if so and we can evaluate other options. Cheers, - Ben

1 1

GitLab upgrade tonight
by Ben Gamari 07 Jun '22

07 Jun '22

Hello everyone, Tonight, around 20:00 EST, I will be performing a GitLab upgrade. As always, the downtime should be minimal (less than 30 minutes) but I will provide status updates as necessary. Cheers, - Ben

1 0

error codes in GHC
by Richard Eisenberg 02 Jun '22

02 Jun '22

Hi devs, I just wanted to call your attention to https://gitlab.haskell.org/ghc/ghc/-/issues/21684, which will add a little more bureaucracy to adding error messages in the future, but all for a good cause. Please take a look and offer any feedback! Thanks, Richard

1 0

The GHC(i)/RTS linker and Template Haskell
by Alexis King 01 Jun '22

01 Jun '22

Hi all, I’ve recently been trying to better understand how and where time is spent at compile-time when running Template Haskell splices, and one of the areas I’ve been struggling to figure out is the operation of the linker. From reading the source code, here’s a summary of what I think I’ve figured out so far: - TH splices are executed using the GHCi interpreter, though it may be internal or external (if -fexternal-interpreter is used). - Regardless of which mode is used, TH splices need their dependencies loaded into the interpreter context before they can be run. This is handled by the call to loadDecls in hscCompileCoreExpr', which in turn calls loadDependencies in GHC.Linker.Loader. - loadDependencies loads packages and modules in different ways. Package dependencies are just loaded via the appropriate built shared libraries, but modules from the current package have to be loaded a different way, via loadObjects (also in GHC.Linker.Loader). Here, however, is where I get a bit lost. GHC has two strategies for loading individual objects, which it chooses between depending on whether the current value of interpreterDynamic is True. But I don’t actually understand what interpreterDynamic means! The Haddock comment just says that it determines whether or not the “interpreter uses the Dynamic way”, but I don’t see why that matters. My understanding was that GHCi *always* requires dynamic linking, since it is, after all, loading code dynamically. Under what circumstances would interpreterDynamic ever be False? Furthermore, I don’t actually understand precisely how and why this influences the choice of loading strategy. In the case that interpreterDynamic is True, GHC appears to convert the desired dyn_o object into a shared library by calling the system linker, then loads that, which can be very slow but otherwise works. However, when interpreterDynamic is False, it loads the object directly. Both paths eventually call into “the RTS linker”, implemented in rts/Linker.c, to actually load the resulting object. I have found precious little information on what the RTS linker does, in which contexts it’s used, or how precisely it works. Note [runtime-linker-phases] at the top of Linker.c has some information, but it’s mostly a high-level description of what the code actually does rather than an explanation of its role in the bigger picture. Does anyone know of any resources they could possibly point me to that help to explain how all the pieces fit together here? I’ve spent quite a bit of time reading the code, but I’m afraid I still haven’t managed to see the forest for the trees. Thanks, Alexis

3 2