- ghc-devs - Haskell.org

[HIW'20] Third Call for Talks
by Ben Gamari 25 Jun '20

25 Jun '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is next week, July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben

1 0

Fixing type synonyms to Uniq(D)FM newtypes
by Andreas Klebinger 24 Jun '20

24 Jun '20

There was a discussion about making UniqFM typed for the keys here a while ago. (https://mail.haskell.org/pipermail/ghc-devs/2020-January/018451.html and following) I wrote up an MR for one possible approach here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3577 It implements solution 2 from that discussion. Just while getting the patch to typecheck I've already seen a number of cases where this increased readability of the code quite a bit so I think it's a good improvement. If there are strong objections to this solution let me know. In that case I'm happy to abandon the patch. If not I will clean it up and get it ready for merging.

2 2

Re: GitLab status
by Ryan Scott 23 Jun '20

23 Jun '20

Just as an FYI, there appears to be some data loss from this migration. For example, I pushed a commit to !3536 [1] that appears to have been dropped, leading to confusion here [2]. To make things worse, I never received an e-mail notification for this comment—I only discovered it by chance. I also opened an issue about FUN, but that appears to have been lost. I could try to resubmit it, but perhaps the data still exists somewhere on servers somewhere? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3536#note_283322

2 1

Introducing GHC whole program compiler (GHC-WPC)
by Csaba Hruska 22 Jun '20

22 Jun '20

Hello, I've created a whole program compilation pipeline for GHC via STG. Please read my blog post for the details: Introducing GHC whole program compiler (GHC-WPC) <https://www.patreon.com/posts/introducing-ghc-38173710> Regards, Csaba Hruska

3 5

RE: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372)
by Simon Peyton Jones 22 Jun '20

22 Jun '20

I get a 404 for https://gitlab.haskell.org/ghc/ghc/-/issues/18372 You may need to re-submit this… s From: Andrzej Rybczak <gitlab(a)gitlab.haskell.org> Sent: 21 June 2020 15:44 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372) Andrzej Rybczak<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> created an issue: Summary When profiling is enabled, GHC doesn't inline small type class methods which prevents further optimizations and specialization from happening. Steps to reproduce When the following module: module Main where import Optics.Core data T = T { _t1 :: Int , _t2 :: Int } t1 :: Lens' T Int t1 = lensVL $ \f s -> (\n -> s { _t1 = n}) <$> f (_t1 s) {-# INLINE t1 #-} t2 :: Lens' T Int t2 = lensVL $ \f s -> (\n -> s { _t2 = n}) <$> f (_t2 s) {-# INLINE t2 #-} t_val :: T t_val = T 1 2 {-# NOINLINE t_val #-} main :: IO () main = putStrLn . show $ view t1 t_val + view t2 t_val is compiled with profiling enabled, here's how core of main looks: main1 = case ((($fStrongForget_$clinear main_l1) (id `cast` <Co:41>)) `cast` <Co:42>) t_val of { I# x_a2c8 -> case ((($fStrongForget_$clinear main_l2) (id `cast` <Co:41>)) `cast` <Co:42>) t_val of { I# y_a2cb -> case $wshowSignedInt 0# (+# x_a2c8 y_a2cb) [] of { (# ww5_a277, ww6_a278 #) -> : ww5_a277 ww6_a278 } } } So linear doesn't get inlined even though it's a small function that is even explicitly marked INLINE<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. This prevents further optimizations from happening and leaves optics-related code in semi-optimized state, making looking at cost centers unreliable (see well-typed/optics#324<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>). When profiling is disabled, everything inlines and optimizes away as expected: main1 = case t_val of { T ds_d25F ds1_d25G -> case ds_d25F of { I# x_a2c7 -> case ds1_d25G of { I# y_a2ca -> case $wshowSignedInt 0# (+# x_a2c7 y_a2ca) [] of { (# ww5_a276, ww6_a277 #) -> : ww5_a276 ww6_a277 } } } } I'm attaching archive with cabal project that contains above module for easy reproduction: prof_test.tar.gz<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> Profiling build was tested with profiling: True in cabal.project.local. Expected behavior GHC should inline class methods marked as INLINE when profiling is enabled. Environment * GHC version used: 8.10.1 Optional: * Operating System: Arch Linux * System Architecture: x86_64 — Reply to this email directly or view it on GitLab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. You're receiving this email because of your account on gitlab.haskell.org. If you'd like to receive fewer emails, you can unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> from this thread or adjust your notification settings.

1 0

Merge window logistics and relaxation of submodule policy
by Ben Gamari 22 Jun '20

22 Jun '20

Hi everyone, At this point we are in the home stretch of the GHC 8.12 preparation phase. The merge queue has progressed a bit more slowly than I would have liked over the last few weeks but nevertheless I think we are converging. Regardless, if you have a patch which you believe should go in to 8.12 and doesn't already bear the %8.12 GitLab milestone, please do let me know. # Submodule policy One matter that is currently holding us up is a few submodules which haven't yet had necessary patches merged upstream. As there hasn't yet been much motion on the part of maintainer, I propose that we temporarily relax our policy that GHC submodules refer to upstream commits. That is, we allow GHC to temporarily track a non-upstream branch, ensuring that the branch is merged upstream before the final GHC release. Are there any objections to this policy relaxation? It will require a bit more care on our part, but I think it is a sensible compromise way to give upstream maintainers the time they need while ensuring that GHC isn't subject to unpredictable schedules. Cheers, - Ben

2 1

GitLab status
by Ben Gamari 22 Jun '20

22 Jun '20

Hi everyone, As you may have noticed, yesterday was marked by rather consistent CI failures. I believe I have now fixed the root cause but do let me know if you see any further issues. Below I have included a brief post-mortem describing the incident and what we plan to do to prevent it recurring in the future. Cheers, - Ben # Post-mortem Early Friday morning our storage provider experienced a hiccup which rendered the volume which backed our GitLab repositories unavailable for a few minutes. The interruption was long enough that the filesystem remounted as read-only. This caused a bit of filesystem damage affecting a handful of objects in the ghc/perf-notes repository. This resulted in CI failures when attempts to `git push` to this repository failed. To address this I started by ensuring we had an up-to-date backup of our data and began sorting through the various observed errors. Once I had established that the storage volume had been interrupted I went looking for additional corruption. A integrity check of all GitLab repositories revealed no further corruption. This isn't terribly surprising given that the perf notes repository sees the most commit traffic of all repositories hosted on GitLab. While it would likely be possible to recover the corrupted perf-notes objects from clones on the CI builders, I deemed this to be not worth the effort given that these commits hold replaceable performance metric data and the last good commit appears to have been produced mere hours prior to the corrupted HEAD commit. Consequently, I rather reverted the ghc-notes repository to the last-known-good commit (8154013bfdce86fedf2863cb96ccbb723f1144f8). # Planned changes for future mitigation While this incident didn't result in any significant data loss, it was nevertheless a significant headache and resulted in CI failing for the better part of a day. Moreover, this isn't the first time that the network block storage backing GitLab has let us down. At this point, I have lost confidence that network block storage can be trusted. For this reason, in the future we will eliminate this failure mode by adjusting our deployment to avoid relying on network block storage for any deployment-critical data. We hope that we will be able to carry out this change in the coming weeks.

1 2

[ghc-lib] internal error after removal of integer-simple
by Shayne Fletcher 20 Jun '20

20 Jun '20

With the recent MR that removes integer-simple in favor of ghc-bignum, I find that I get a runtime failure when I try to use ghc-lib to generate core: ``` # Running: stack --no-terminal exec -- mini-compile examples/mini-compile/test/MiniCompileTest.hs examples/mini-compile/test/MiniCompileTest.hs:66:5: error: * GHC internal error: `One' is not in scope during type checking, but it passed the renamer tcl_env of environment: [628 :-> ATcTyCon TrName :: *, 62b :-> APromotionErr RecDataConPE, 62e :-> APromotionErr RecDataConPE] * In the definition of data constructor `TrNameS' In the data declaration for `TrName' | 66 | = TrNameS Addr# -- Static | ^^^^^^^^^^^^^ mini-compile: GHC internal error: `One' is not in scope during type checking, but it passed the renamer tcl_env of environment: [628 :-> ATcTyCon TrName :: *, 62b :-> APromotionErr RecDataConPE, 62e :-> APromotionErr RecDataConPE] ``` Anyone have any pointers on what is going wrong and what I should be looking at? -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.com/>* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

4 9

Gitlab is stuck
by Simon Peyton Jones 20 Jun '20

20 Jun '20

Something is badly wrong with gitlab. I'm trying to push a branch. Is some disk full? I am fully stalled. Thanks Simon bash$ git push --force Counting objects: 79, done. Delta compression using up to 20 threads. Compressing objects: 100% (65/65), done. Writing objects: 100% (79/79), 46.21 KiB | 3.55 MiB/s, done. Total 79 (delta 68), reused 16 (delta 14) error: remote unpack failed: unable to create temporary object directory remote: warning: The last gc run reported the following. Please correct the root cause remote: and remove gc.log. remote: Automatic cleanup will not be performed until the file is removed. remote: remote: warning: There are too many unreachable loose objects; run 'git prune' to remove them. remote: To gitlab.haskell.org:ghc/ghc.git ! [remote rejected] wip/T18282 -> wip/T18282 (unpacker error) error: failed to push some refs to 'git@gitlab.haskell.org:ghc/ghc.git'

2 3

Gitlab corrupt
by Simon Peyton Jones 20 Jun '20

20 Jun '20

Ben Something is amiss. "corrupt" sounds bad! Simon bash$ git fetch error: garbage at end of loose object '62be92e5be07b34fc25c77e36223268c4a6eadec' fatal: loose object 62be92e5be07b34fc25c77e36223268c4a6eadec (stored in ./objects/62/be92e5be07b34fc25c77e36223268c4a6eadec) is corrupt fatal: The remote end hung up unexpectedly

2 1