From hecate at glitchbra.in Tue Aug 1 21:03:09 2023 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 1 Aug 2023 23:03:09 +0200 Subject: Something to learn from: On Telemetry in the Rust compiler Message-ID: We should all certainly learn something from reading this post on telemetry and user trust. I know I did: https://estebank.github.io/rustc-metrics.html Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From ryan.gl.scott at gmail.com Wed Aug 2 13:43:08 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 2 Aug 2023 09:43:08 -0400 Subject: Call for Lightning Talks: Haskell Implementors' Workshop 2023 Message-ID: ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ --------------- The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. 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 to discuss future directions and collaborations with others. We have a number of slots for lightning talks. Lightning talks will be ~7 minutes 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. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Accepted lightning talks will be posted on the workshop’s website. Submissions should be made via this Google form: https://forms.gle/2jGceompwNghbRQR9 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- 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 are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially 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, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Contact ------- * Ryan Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrberen at cisco.com Thu Aug 3 12:16:51 2023 From: chrberen at cisco.com (Christian Berentsen (chrberen)) Date: Thu, 3 Aug 2023 12:16:51 +0000 Subject: Request for account approval for GHC non-moving GC bug reporting Message-ID: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> We may have encountered a bug in the non-moving GC runtime, triggering: congregat-exe: internal error: nonmovingCollect: failed to spawn mark thread: Resource temporarily unavailable (GHC version 9.2.6 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Need account approval for jc.berentsen at gmail.com to report, if this is not a duplicate Regards, Christian From bryan at haskell.foundation Thu Aug 3 12:20:42 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 3 Aug 2023 15:20:42 +0300 Subject: Request for account approval for GHC non-moving GC bug reporting In-Reply-To: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> References: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> Message-ID: Approved! Thanks for joining. On Thu, 3 Aug 2023 at 15:17, Christian Berentsen (chrberen) via ghc-devs < ghc-devs at haskell.org> wrote: > We may have encountered a bug in the non-moving GC runtime, triggering: > > congregat-exe: internal error: nonmovingCollect: failed to spawn mark > thread: Resource temporarily unavailable > (GHC version 9.2.6 for x86_64_unknown_linux) > Please report this as a GHC bug: > https://www.haskell.org/ghc/reportabug > > Need account approval for jc.berentsen at gmail.com to report, if this is > not a duplicate > > Regards, Christian > > _______________________________________________ > 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: From ben at smart-cactus.org Thu Aug 3 13:58:28 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 03 Aug 2023 09:58:28 -0400 Subject: Request for account approval for GHC non-moving GC bug reporting In-Reply-To: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> References: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> Message-ID: <87zg38ns78.fsf@smart-cactus.org> "Christian Berentsen \(chrberen\) via ghc-devs" writes: > We may have encountered a bug in the non-moving GC runtime, triggering: > > congregat-exe: internal error: nonmovingCollect: failed to spawn mark thread: Resource temporarily unavailable > (GHC version 9.2.6 for x86_64_unknown_linux) > Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug > > Need account approval for jc.berentsen at gmail.com to report, if this is not a duplicate > Very interesting; thanks in advance for your ticket and apologies for the inconvenience in registering! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From chrberen at cisco.com Fri Aug 4 06:05:55 2023 From: chrberen at cisco.com (Christian Berentsen (chrberen)) Date: Fri, 4 Aug 2023 06:05:55 +0000 Subject: Request for account approval for GHC non-moving GC bug reporting In-Reply-To: <87zg38ns78.fsf@smart-cactus.org> References: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> <87zg38ns78.fsf@smart-cactus.org> Message-ID: <48B0C205-B389-4D40-90B9-BD9FAA1D2A96@cisco.com> I was unfortunately not able to get signed in to report the bug. Something messed up with the browser storing the gitlab login password, and after using the "forgot password" I couldn't find the follow up email anywhere (including spam) Maybe something messed up with my mixing the work email for the mailing list and my personal for gitlab, causing the gitlab account to not be in the proper approval state? I can add some additional info about the bug event: This was running on a shared cluster where IT identified there were a lot of unrelated zombie processes, so the "Resource temporarily unavailable" result was probably real. I'd expect this context to lower the severity of this bug. But anyway, this may possibly trigger in OS environments with resource constraints or bumping into syslimits. -- Christian On 03/08/2023, 15:58, "Ben Gamari" wrote: "Christian Berentsen \(chrberen\) via ghc-devs" writes: > We may have encountered a bug in the non-moving GC runtime, triggering: > > congregat-exe: internal error: nonmovingCollect: failed to spawn mark thread: Resource temporarily unavailable > (GHC version 9.2.6 for x86_64_unknown_linux) > Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug > > Need account approval for jc.berentsen at gmail.com to report, if this is not a duplicate > Very interesting; thanks in advance for your ticket and apologies for the inconvenience in registering! Cheers, - Ben From rodrigo.m.mesquita at gmail.com Sun Aug 6 10:02:27 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Sun, 6 Aug 2023 11:02:27 +0100 Subject: Getting all variables in scope in CoreM Message-ID: <95ABFDFD-37E1-4327-8B3E-BB12EFE453CA@gmail.com> Dear GHC devs, I’m trying to invoke the GHC.Core.Lint linting functions from a Core GHC plugin. These functions take a LintConfig that can m <>ostly be constructed from DynFlags, <> the exception being <> <> l_vars :: ![Var] — ^ Ids that should be treated as being in scope My question is then “How can I get all variables in scope in the module underlying this CoreM computation, to pass in the LintConfig?”. My ultimate goal is to run LintM to determine the usage environment of a given core expression. In that sense, the “Id out of scope” errors aren’t that important to me, but they do make the linting action fail. Thanks in advance! Rodrigo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Sun Aug 6 16:12:46 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sun, 6 Aug 2023 17:12:46 +0100 Subject: Getting all variables in scope in CoreM In-Reply-To: <95ABFDFD-37E1-4327-8B3E-BB12EFE453CA@gmail.com> References: <95ABFDFD-37E1-4327-8B3E-BB12EFE453CA@gmail.com> Message-ID: > > My question is then “How can I get all variables in scope in the module > underlying this CoreM computation, to pass in the LintConfig?”. > What do you have in your hand? A [CoreBinding]? If so, just do `bindersOfBinds`. You only need the LocalIds. You don't need (imported) GlobalIds Simon On Sun, 6 Aug 2023 at 11:02, Rodrigo Mesquita wrote: > Dear GHC devs, > > I’m trying to invoke the GHC.Core.Lint linting functions from a Core GHC > plugin. > These functions take a LintConfig that can mostly be constructed from > DynFlags, > the exception being > > * l_vars :: ![Var]* — ^ Ids that should be treated as being in scope > > My question is then “How can I get all variables in scope in the module > underlying this CoreM computation, to pass in the LintConfig?”. > > My ultimate goal is to run LintM to determine the usage environment of a > given core expression. > In that sense, the “Id out of scope” errors aren’t that important to me, > but they do make the linting action fail. > > Thanks in advance! > Rodrigo > _______________________________________________ > 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: From simon.peytonjones at gmail.com Mon Aug 7 09:50:31 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 7 Aug 2023 10:50:31 +0100 Subject: Configure errors Message-ID: Rodrigo I'm getting lots of errors from ./configure, see below. Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? Simon Entering: checking for C compiler checking for -Qunused-arguments support... Entering: checking for -Qunused-arguments support Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc supports --target... Entering: checking whether Cc supports --target Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c Exited with code 1 found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking whether Cc works... Entering: checking whether Cc works Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found whether Cc works: () checking for C99 support... Entering: checking for C99 support Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c found for C99 support: () checking whether cc supports extra via-c flags... Entering: checking whether cc supports extra via-c flags Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c found whether cc supports extra via-c flags: () found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} checking for C++ compiler... Entering: checking for C++ compiler x86_64-unknown-linux-g++ not found in search path x86_64-unknown-linux-clang++ not found in search path x86_64-unknown-linux-c++ not found in search path checking whether C++ supports --target... Entering: checking whether C++ supports --target Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp Exited with code 1 found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} checking for C preprocessor... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.m.mesquita at gmail.com Mon Aug 7 09:57:17 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Mon, 7 Aug 2023 10:57:17 +0100 Subject: Configure errors In-Reply-To: References: Message-ID: Thanks for pointing this out, Simon What you’ve pasted is the trace of the ghc-toolchain program. We should probably lower the verbosity after !10976 lands, but in the meantime it’s just useful to debug mostly CI. At the end of the configure step there might be a message that starts with “Don’t worry! This will not affect your build in any way”. That’s as less alarming as I could make it :). If you do see the warning, it’s due to a discrepancy between the output produced by configure and the one produced by ghc-toolchain: We’re fixing all the discrepancies caught by CI in !10976 — after which we’ll always validate these discrepancies in CI, to ensure ghc-toolchain is kept up to date with configure, while configure still configures toolchains. I’ve also been busy writing the blog about this. It should come out soon enough. Rodrigo > On 7 Aug 2023, at 10:50, Simon Peyton Jones wrote: > > Rodrigo > > I'm getting lots of errors from ./configure, see below. > > Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? > > Simon > > Entering: checking for C compiler > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking whether Cc supports --target... > Entering: checking whether Cc supports --target > Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking whether Cc works... > Entering: checking whether Cc works > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found whether Cc works: () > checking for C99 support... > Entering: checking for C99 support > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found for C99 support: () > checking whether cc supports extra via-c flags... > Entering: checking whether cc supports extra via-c flags > Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c > found whether cc supports extra via-c flags: () > found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking for C++ compiler... > Entering: checking for C++ compiler > x86_64-unknown-linux-g++ not found in search path > x86_64-unknown-linux-clang++ not found in search path > x86_64-unknown-linux-c++ not found in search path > checking whether C++ supports --target... > Entering: checking whether C++ supports --target > Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Exited with code 1 > > found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} > Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} > checking for C preprocessor... -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Aug 7 10:01:39 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 7 Aug 2023 11:01:39 +0100 Subject: Configure errors In-Reply-To: References: Message-ID: > > At the end of the configure step there might be a message that starts with > “Don’t worry! This will not affect your build in any way”. That’s as less > alarming as I could make it :). > I do see that message, but apparently it refers only to the immediately preceding warning, namely > configure: WARNING: > There are some differences between the toolchain configured by "configure" > (hadrian/cfg/default.target) and the toolchain configured by the > "ghc-toolchain" program (hadrian/cfg/default.target.ghc-toolchain). > It did nothing to reassure me about earlier errors in the configure stuff; it seemed to be about something different. Suggestion - Instead of "This will not affect..." say "This difference in toolchain output won't affect...", so the target of "This" is clearer. - Suppress these gcc errors. You can switch them on in your build! Simon On Mon, 7 Aug 2023 at 10:57, Rodrigo Mesquita wrote: > Thanks for pointing this out, Simon > > What you’ve pasted is the trace of the ghc-toolchain program. > We should probably lower the verbosity after !10976 lands, but in the > meantime it’s just useful to debug mostly CI. > > At the end of the configure step there might be a message that starts with > “Don’t worry! This will not affect your build in any way”. That’s as less > alarming as I could make it :). > > If you do see the warning, it’s due to a discrepancy between the output > produced by configure and the one produced by ghc-toolchain: > We’re fixing all the discrepancies caught by CI in !10976 — after which > we’ll always validate these discrepancies in CI, to ensure ghc-toolchain is > kept up to date with configure, while configure still configures toolchains. > > I’ve also been busy writing the blog about this. It should come out soon > enough. > > Rodrigo > > On 7 Aug 2023, at 10:50, Simon Peyton Jones > wrote: > > Rodrigo > > I'm getting lots of errors from ./configure, see below. > > Seems to be something to do with your toolchain stuff? I'm lost. Should > I worry? If not, could they be made to look less alarming somehow? > > Simon > > Entering: checking for C compiler > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Exited with code 1 > > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = > "/usr/bin/gcc", prgFlags = []}} > checking whether Cc supports --target... > Entering: checking whether Cc supports --target > Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o > /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c > -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found whether Cc supports --target: Cc {ccProgram = Program {prgPath = > "/usr/bin/gcc", prgFlags = []}} > checking whether Cc works... > Entering: checking whether Cc works > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found whether Cc works: () > checking for C99 support... > Entering: checking for C99 support > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found for C99 support: () > checking whether cc supports extra via-c flags... > Entering: checking whether cc supports extra via-c flags > Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o > /tmp/tmp0/test.o /tmp/tmp0/test.c > found whether cc supports extra via-c flags: () > found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", > prgFlags = []}} > checking for C++ compiler... > Entering: checking for C++ compiler > x86_64-unknown-linux-g++ not found in search path > x86_64-unknown-linux-clang++ not found in search path > x86_64-unknown-linux-c++ not found in search path > checking whether C++ supports --target... > Entering: checking whether C++ supports --target > Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o > /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c > -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Exited with code 1 > > found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath > = "/usr/bin/g++", prgFlags = []}} > Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > found for C++ compiler: Cxx {cxxProgram = Program {prgPath = > "/usr/bin/g++", prgFlags = []}} > checking for C preprocessor... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.m.mesquita at gmail.com Mon Aug 7 10:07:46 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Mon, 7 Aug 2023 11:07:46 +0100 Subject: Configure errors In-Reply-To: References: Message-ID: <8071962F-65B2-4BAE-B203-04829E8A803A@gmail.com> The trace is akin to the configure trace — it shows invocations of the toolchain in trying to determine properties of said toolchain e.g. which flags are supported. For example > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} Is the trace of invoking the C compiler with -Qunused-arguments, checking whether the C compiler supports such an option. That command exited with code 1 likely because the compiler doesn’t indeed support -Qunused-arguments. That’s fine, it means we won’t pass -Qunused-arguments to your C compiler. Rodrigo > On 7 Aug 2023, at 10:50, Simon Peyton Jones wrote: > > Rodrigo > > I'm getting lots of errors from ./configure, see below. > > Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? > > Simon > > Entering: checking for C compiler > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking whether Cc supports --target... > Entering: checking whether Cc supports --target > Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking whether Cc works... > Entering: checking whether Cc works > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found whether Cc works: () > checking for C99 support... > Entering: checking for C99 support > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found for C99 support: () > checking whether cc supports extra via-c flags... > Entering: checking whether cc supports extra via-c flags > Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c > found whether cc supports extra via-c flags: () > found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} > checking for C++ compiler... > Entering: checking for C++ compiler > x86_64-unknown-linux-g++ not found in search path > x86_64-unknown-linux-clang++ not found in search path > x86_64-unknown-linux-c++ not found in search path > checking whether C++ supports --target... > Entering: checking whether C++ supports --target > Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Exited with code 1 > > found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} > Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} > checking for C preprocessor... -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Aug 7 10:11:54 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 7 Aug 2023 11:11:54 +0100 Subject: Configure errors In-Reply-To: <8071962F-65B2-4BAE-B203-04829E8A803A@gmail.com> References: <8071962F-65B2-4BAE-B203-04829E8A803A@gmail.com> Message-ID: But the other tests look like checking for gnutar... no checking for gtar... no checking for tar... /usr/bin/tar checking for gpatch... no checking for patch... /usr/bin/patch checking for autoreconf... /usr/bin/autoreconf Can't you say checking for -Qunused-arguments... no You can explain this to me, now, and that helps me, today. But I'm trying to save you from having to explain it to many future GHC devs, and/or save them time in hunting for answers to the same question. No rush Simon On Mon, 7 Aug 2023 at 11:07, Rodrigo Mesquita wrote: > The trace is akin to the configure trace — it shows invocations of the > toolchain in trying to determine properties of said toolchain e.g. which > flags are supported. > > For example > > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Exited with code 1 > > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = > "/usr/bin/gcc", prgFlags = []}} > > > Is the trace of invoking the C compiler with -Qunused-arguments, checking > whether the C compiler supports such an option. > That command exited with code 1 likely because the compiler doesn’t indeed > support -Qunused-arguments. > That’s fine, it means we won’t pass -Qunused-arguments to your C compiler. > > Rodrigo > > On 7 Aug 2023, at 10:50, Simon Peyton Jones > wrote: > > Rodrigo > > I'm getting lots of errors from ./configure, see below. > > Seems to be something to do with your toolchain stuff? I'm lost. Should > I worry? If not, could they be made to look less alarming somehow? > > Simon > > Entering: checking for C compiler > checking for -Qunused-arguments support... > Entering: checking for -Qunused-arguments support > Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o > /tmp/tmp0/test.o.c > Exited with code 1 > > found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = > "/usr/bin/gcc", prgFlags = []}} > checking whether Cc supports --target... > Entering: checking whether Cc supports --target > Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o > /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c > -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > Exited with code 1 > > found whether Cc supports --target: Cc {ccProgram = Program {prgPath = > "/usr/bin/gcc", prgFlags = []}} > checking whether Cc works... > Entering: checking whether Cc works > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found whether Cc works: () > checking for C99 support... > Entering: checking for C99 support > Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c > found for C99 support: () > checking whether cc supports extra via-c flags... > Entering: checking whether cc supports extra via-c flags > Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o > /tmp/tmp0/test.o /tmp/tmp0/test.c > found whether cc supports extra via-c flags: () > found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", > prgFlags = []}} > checking for C++ compiler... > Entering: checking for C++ compiler > x86_64-unknown-linux-g++ not found in search path > x86_64-unknown-linux-clang++ not found in search path > x86_64-unknown-linux-c++ not found in search path > checking whether C++ supports --target... > Entering: checking whether C++ supports --target > Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o > /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c > -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > Exited with code 1 > > found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath > = "/usr/bin/g++", prgFlags = []}} > Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp > found for C++ compiler: Cxx {cxxProgram = Program {prgPath = > "/usr/bin/g++", prgFlags = []}} > checking for C preprocessor... > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.m.mesquita at gmail.com Mon Aug 7 10:15:25 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Mon, 7 Aug 2023 11:15:25 +0100 Subject: Configure errors In-Reply-To: References: <8071962F-65B2-4BAE-B203-04829E8A803A@gmail.com> Message-ID: <31CEC7F7-CF3B-43AF-8A3E-955230847DCB@gmail.com> I agree. The alarming trace is due to the verbosity being too high. I’ve opened #23794 to track lowering the verbosity. Then we should get a simpler trace, like the configure one. Rodrigo > On 7 Aug 2023, at 11:11, Simon Peyton Jones wrote: > > But the other tests look like > > checking for gnutar... no > checking for gtar... no > checking for tar... /usr/bin/tar > checking for gpatch... no > checking for patch... /usr/bin/patch > checking for autoreconf... /usr/bin/autoreconf > > Can't you say > > checking for -Qunused-arguments... no > > You can explain this to me, now, and that helps me, today. But I'm trying to save you from having to explain it to many future GHC devs, and/or save them time in hunting for answers to the same question. > > No rush > > Simon > > On Mon, 7 Aug 2023 at 11:07, Rodrigo Mesquita > wrote: >> The trace is akin to the configure trace — it shows invocations of the toolchain in trying to determine properties of said toolchain e.g. which flags are supported. >> >> For example >> >>> checking for -Qunused-arguments support... >>> Entering: checking for -Qunused-arguments support >>> Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Exited with code 1 >>> found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} >> >> Is the trace of invoking the C compiler with -Qunused-arguments, checking whether the C compiler supports such an option. >> That command exited with code 1 likely because the compiler doesn’t indeed support -Qunused-arguments. >> That’s fine, it means we won’t pass -Qunused-arguments to your C compiler. >> >> Rodrigo >> >>> On 7 Aug 2023, at 10:50, Simon Peyton Jones > wrote: >>> >>> Rodrigo >>> >>> I'm getting lots of errors from ./configure, see below. >>> >>> Seems to be something to do with your toolchain stuff? I'm lost. Should I worry? If not, could they be made to look less alarming somehow? >>> >>> Simon >>> >>> Entering: checking for C compiler >>> checking for -Qunused-arguments support... >>> Entering: checking for -Qunused-arguments support >>> Execute: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Command failed: /usr/bin/gcc -Qunused-arguments -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Exited with code 1 >>> >>> found for -Qunused-arguments support: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} >>> checking whether Cc supports --target... >>> Entering: checking whether Cc supports --target >>> Execute: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Command failed: /usr/bin/gcc -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> Exited with code 1 >>> >>> found whether Cc supports --target: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} >>> checking whether Cc works... >>> Entering: checking whether Cc works >>> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> found whether Cc works: () >>> checking for C99 support... >>> Entering: checking for C99 support >>> Execute: /usr/bin/gcc -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.c >>> found for C99 support: () >>> checking whether cc supports extra via-c flags... >>> Entering: checking whether cc supports extra via-c flags >>> Execute: /usr/bin/gcc -c -fwrapv -fno-builtin -Werror -x c -o /tmp/tmp0/test.o /tmp/tmp0/test.c >>> found whether cc supports extra via-c flags: () >>> found for C compiler: Cc {ccProgram = Program {prgPath = "/usr/bin/gcc", prgFlags = []}} >>> checking for C++ compiler... >>> Entering: checking for C++ compiler >>> x86_64-unknown-linux-g++ not found in search path >>> x86_64-unknown-linux-clang++ not found in search path >>> x86_64-unknown-linux-c++ not found in search path >>> checking whether C++ supports --target... >>> Entering: checking whether C++ supports --target >>> Execute: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp >>> Command failed: /usr/bin/g++ -Werror --target=x86_64-unknown-linux -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp >>> Exited with code 1 >>> >>> found whether C++ supports --target: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} >>> Execute: /usr/bin/g++ -c -o /tmp/tmp0/test.o /tmp/tmp0/test.o.cpp >>> found for C++ compiler: Cxx {cxxProgram = Program {prgPath = "/usr/bin/g++", prgFlags = []}} >>> checking for C preprocessor... >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Aug 7 15:57:43 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 07 Aug 2023 11:57:43 -0400 Subject: [ANNOUNCE] GHC 9.4.6 is now available Message-ID: <87edke7slk.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.4.6. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.4.6 This release is primarily a bugfix release addressing some issues found in 9.4.6. These include: * Many bug fixes for the simplifier, preventing compiler panics, loops and incorrect code generation (#22761, #22549, #23208, #22761, #22272, #23146, #23012, #22547). * Bug fixes for the typechecker involving newtype family instances, making type equalities more robust and bugs having to do with defaulting representation polymorphic type variables (#23329, #23333, #23143, #23154, #23176). * Some bug fixes for code generation, particularly on the aarch64 backend, including adding more memory barriers for array read operations (#23541, #23749). * Some bug fixes for windows builds, ensuring the reliablility of IO manager shutdown and a bug fix for the RTS linker on windows (#23691, #22941). * A bug fix for the non-moving GC ensuring mutator allocations are properly accounted for (#23312). * A bug fix preventing some segfaults by ensuring that pinned allocations respect block size (#23400). * Many bug fixes for the bytecode interpreter, allowing a greater subset of the language to be interpreted (#22376, #22840, #22051, #21945, #23068, #22958). * ... and a few more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin & Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Tue Aug 8 12:56:38 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 08 Aug 2023 08:56:38 -0400 Subject: Request for account approval for GHC non-moving GC bug reporting In-Reply-To: <48B0C205-B389-4D40-90B9-BD9FAA1D2A96@cisco.com> References: <88934479-8203-426D-9922-A0997DFC9C91@cisco.com> <87zg38ns78.fsf@smart-cactus.org> <48B0C205-B389-4D40-90B9-BD9FAA1D2A96@cisco.com> Message-ID: <87a5v17kvx.fsf@smart-cactus.org> "Christian Berentsen (chrberen)" writes: > I was unfortunately not able to get signed in to report the bug. > Something messed up with the browser storing the gitlab login > password, and after using the "forgot password" I couldn't find the > follow up email anywhere (including spam) > Hmm, this is quite unfortunate. I have checked the mail server and gmail claims that the message was successfully delivered to jc.berentsen at gmail.com. Is this the expected address? > Maybe something messed up with my mixing the work email for the > mailing list and my personal for gitlab, causing the gitlab account to > not be in the proper approval state? > > I can add some additional info about the bug event: > This was running on a shared cluster where IT identified there were a > lot of unrelated zombie processes, so the "Resource temporarily > unavailable" result was probably real. > > I'd expect this context to lower the severity of this bug. But anyway, > this may possibly trigger in OS environments with resource constraints > or bumping into syslimits. > While I'm not certain precisely what has failed here, I suspect that the fact that we spawn and kill a fresh OS thread for each marking cycle likely doesn't help matters. This is something that I have wanted to fix for quite some time. Over the weekend I carried out the refactoring; the result is !11048 [1] Thanks again for your bug report. It would be great if we could get to the bottom of why your account creation request is stuck. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11048 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ietf-dane at dukhovni.org Tue Aug 8 15:33:52 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Aug 2023 11:33:52 -0400 Subject: Problem building 9.4.7 on Fedora 36 (bytestring/cbits/is-valid-utf8.c) Message-ID: The build was failing, because rts/OSThreads.h via Rts.h from libraries/bytestring/cbits/is-valid-utf8.c had no definition of `clockid_t`. This type is not exposed with _POSIX_C_SOURCE is not defined to a sufficiently high value: SYNOPSIS #include int clock_getres(clockid_t clockid, struct timespec *res); int clock_gettime(clockid_t clockid, struct timespec *tp); int clock_settime(clockid_t clockid, const struct timespec *tp); Link with -lrt (only for glibc versions before 2.17). Feature Test Macro Requirements for glibc (see feature_test_macros(7)): clock_getres(), clock_gettime(), clock_settime(): _POSIX_C_SOURCE >= 199309L I quick-and-dirty work-around was: --- a/libraries/bytestring/cbits/is-valid-utf8.c +++ b/libraries/bytestring/cbits/is-valid-utf8.c @@ -27,6 +27,10 @@ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#undef _POSIX_C_SOURCE +#define _POSIX_C_SOURCE 200809L +#undef _XOPEN_SOURCE +#define _XOPEN_SOURCE 700 #pragma GCC push_options #pragma GCC optimize("-O2") #include There's surely a better solution. -- Viktor. From ietf-dane at dukhovni.org Tue Aug 8 15:43:56 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Aug 2023 11:43:56 -0400 Subject: Problem building 9.4.6 on Fedora 36 (bytestring/cbits/is-valid-utf8.c) In-Reply-To: References: Message-ID: On Tue, Aug 08, 2023 at 11:33:52AM -0400, Viktor Dukhovni wrote: > The build was failing, because rts/OSThreads.h via Rts.h from > libraries/bytestring/cbits/is-valid-utf8.c had no definition of > `clockid_t`. This type is not exposed when _POSIX_C_SOURCE is > not defined to a sufficiently high value: Apologies, original $subject should have said 9.4.6. -- Viktor. From rodrigo.m.mesquita at gmail.com Tue Aug 8 15:48:03 2023 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Tue, 8 Aug 2023 16:48:03 +0100 Subject: Problem building 9.4.7 on Fedora 36 (bytestring/cbits/is-valid-utf8.c) In-Reply-To: References: Message-ID: Unfortunately you’re not the only developer facing these build errors. They've been reported in #23810 and #23789 . It might be worth pasting your workaround there too. Thanks, Rodrigo > On 8 Aug 2023, at 16:33, Viktor Dukhovni wrote: > > The build was failing, because rts/OSThreads.h via Rts.h from > libraries/bytestring/cbits/is-valid-utf8.c had no definition of > `clockid_t`. This type is not exposed with _POSIX_C_SOURCE is > not defined to a sufficiently high value: > > SYNOPSIS > #include > > int clock_getres(clockid_t clockid, struct timespec *res); > > int clock_gettime(clockid_t clockid, struct timespec *tp); > int clock_settime(clockid_t clockid, const struct timespec *tp); > > Link with -lrt (only for glibc versions before 2.17). > > Feature Test Macro Requirements for glibc (see feature_test_macros(7)): > > clock_getres(), clock_gettime(), clock_settime(): > _POSIX_C_SOURCE >= 199309L > > I quick-and-dirty work-around was: > > --- a/libraries/bytestring/cbits/is-valid-utf8.c > +++ b/libraries/bytestring/cbits/is-valid-utf8.c > @@ -27,6 +27,10 @@ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY > OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > SUCH DAMAGE. > */ > +#undef _POSIX_C_SOURCE > +#define _POSIX_C_SOURCE 200809L > +#undef _XOPEN_SOURCE > +#define _XOPEN_SOURCE 700 > #pragma GCC push_options > #pragma GCC optimize("-O2") > #include > > > There's surely a better solution. > > -- > Viktor. > _______________________________________________ > 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: From cydparser at gmail.com Wed Aug 9 03:55:01 2023 From: cydparser at gmail.com (cydparser) Date: Tue, 8 Aug 2023 20:55:01 -0700 Subject: GitLab approval Message-ID: Can a GitLab admin please approve my account (@cydparser). Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Aug 9 07:07:37 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 09 Aug 2023 03:07:37 -0400 Subject: GitLab approval In-Reply-To: References: Message-ID: I am a bit confused. It appears that you account has been active since 2018. On August 8, 2023 11:55:01 PM EDT, cydparser wrote: >Can a GitLab admin please approve my account (@cydparser). Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdecacqu at redhat.com Wed Aug 9 19:06:28 2023 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Wed, 09 Aug 2023 19:06:28 +0000 Subject: Analyzing Haskell call graph (was: Thread on Discourse - HIE file processing) In-Reply-To: <87tttkvygs.tristanC@fedora> References: <87tttkvygs.tristanC@fedora> Message-ID: <87350s6nnv.tristanC@fedora> On Mon, Jul 31, 2023 at 16:26 Tristan Cacqueray wrote: > On Mon, Jul 31, 2023 at 11:05 David Christiansen via ghc-devs wrote: >> Dear GHC devs, >> >> I think that having automated security advisory warnings from build tools >> is important for Haskell adoption in certain industries. This can be done >> based on build plans, but a package is really the wrong granularity - a >> large, widely-used package might export a little-used definition that is >> the subject of an advisory, and it would be good to warn only the users of >> said definition (cf base and readFloat). >> >> Tristan is exploring using HIE files to do this check, but I don't know if >> you read Discourse, where he posted the question: >> https://discourse.haskell.org/t/rfc-using-hie-files-to-list-external-declarations-for-cabal-audit/7147 >> > > Thank you David for bringing this up here. One thing to note is that we > would need hie files for ghc libraries, as proposed in: > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1337 > > Cheers, > -Tristan Dear GHC devs, To recap, the goal of this project is to check if a given declaration is used by a package. For example, I would like to check if such definition: "package:Module.name" is reachable from another module. In this post I list the considered options, and raise some questions about using the simplified core from .hi files. I would appreciate if you could have a look and help me figure out the remaining blockers. Note that I'm not very familiar with the GHC internals and how to properly read Core expressions, so any feedback would be appreciated. # Context and Problem Statement We would like to check if a package is affected by a known vulnerability. Instead of looking at the build dependencies names and versions, we would like to search for individual functions. This is particularly important to avoid false alarm when a given vulnerability only appears in a rarely used declaration of a popular package. Therefor, we need a way to search the whole call graph to assert with confidence that a given declaration is not used (e.g. reachable). # Considered Options To obtain the call graph data, the following options are considered: * .hie files produced when using the `-fwrite-ide-info` flag. * .modpack files produced by the [wpc-plugin][grin]. * custom GHC plugin. * .hi files containing the simplified core when using the `-fwrite-if-simplified-core` flag. # Pros and Cons of the Options ### Hie files This option is similar to what [weeder][weeder] already implements. However this file format is designed for IDE, and it may not be suitable for our problem. For example, RULES, deriving, RebindableSyntax and template haskell are not well captured. [weeder]: https://github.com/ocharles/weeder/ ### Modpack This option appears to work, but it seems overkill. I don't think we need to reach for STG representation. [grin]: https://github.com/grin-compiler/ghc-whole-program-compiler-project ### Custom GHC plugin This option enables extra metadata to be collected, but if using the simplified core is enough, then it is just an extra step compared to using .hi files. ### Hi files Using .hi files is the only option that doesn't require an extra compilation artifacts, the necessary files are already part of the packages. To collect hie files or files generated by a GHC plugin, ghc/cabal/stack all need some extra work: - ghc libraries doesn't ship hie files ([issue!16901](https://gitlab.haskell.org/ghc/ghc/-/issues/16901)). - cabal needs recent changes for hie files ([PR#9019](https://github.com/haskell/cabal/pull/9019)) and plugin artifacts ([PR#8662](https://github.com/haskell/cabal/pull/8662)). - stack doesn't seem to install hie files for global library. Moreover, creating artifacts with a plugin for ghc libraries may requires manual steps because these libraries are not built by the end user. Therefor, using .hi files is the most straightforward solution. # Questions In this section I present the current implementation of [cabal-audit](https://github.com/TristanCacqueray/cabal-audit/). ## Collecting dependencies from core In the [cabal-audit-core:CabalAudit.Core](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-core/src/CabalAudit/Core.hs) module I implemented the logic to extract the call graph from core expression into a list of declarations composed of `UnitId:ModuleName.OccName` and their dependencies. Here is an example output for the [cabal-audit-test:CabalAudit.Test.User](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-test/src/CabalAudit/Test/User.hs) module: ```ShellSession $ cabal run -O0 --write-ghc-environment=always cabal-audit-hi -- CabalAudit.Test.User cabal-audit-test:CabalAudit.Test.Inline.fonctionInlined: base:GHC.Num.$fNumInt, base:GHC.Num.-, ghc-prim:GHC.Types.I# cabal-audit-test:CabalAudit.Test.Instance.$fTestClassTea: cabal-audit-test:CabalAudit.Test.Instance.$ctasty1 cabal-audit-test:CabalAudit.Test.Instance.$fTestClassCofee: cabal-audit-test:CabalAudit.Test.Instance.$ctasty cabal-audit-test:CabalAudit.Test.Instance.$ctasty: ghc-prim:GHC.Classes.&&, ghc-prim:GHC.Types.True cabal-audit-test:CabalAudit.Test.Instance.$ctasty1: base:GHC.Base.., cabal-audit-test:CabalAudit.Test.Instance.alwaysTrue, ghc-prim:GHC.Classes.not cabal-audit-test:CabalAudit.Test.Instance.alwaysTrue: base:GHC.Base.const, ghc-prim:GHC.Types.True cabal-audit-test:CabalAudit.Test.User.monDoubleDecr: base:GHC.Num.$fNumInt, base:GHC.Num.-, cabal-audit-test:CabalAudit.Test.Inline.fonctionInlined, ghc-prim:GHC.Types.I# cabal-audit-test:CabalAudit.Test.User.useAlwaysTrue: cabal-audit-test:CabalAudit.Test.Instance.Tea, cabal-audit-test:CabalAudit.Test.Instance.$fTestClassTea cabal-audit-test:CabalAudit.Test.User.useCofeeInstance: cabal-audit-test:CabalAudit.Test.Instance.Cofee, cabal-audit-test:CabalAudit.Test.Instance.$fTestClassCofee ``` This appears correct, in particular: - Type class instances are uniquely identified (that was not working well when using a custom plugin). - Inlined declaration are not inlined in the simplified core when built with `-O0`. However this is collecting extra definitions that are not part of the source file. I understand that '$fTestClassTea' means the 'TestClass' instance of 'Tea'. But it seems like the actual implementation is behind the extra '$ctasty' declaration. Moreover, when analyzing the other test modules, I see many declarations named 'lvlXX', which I guess are local names that have been floated out. This is not ideal because the resulting graph contains extra edges that are not relevant for the end user. I tried to tidy this using 'isExportedId' and 'idDetails' from 'GHC.Types.Var' but I worry that this not a good strategy. So my question is: how to recover the original declarations context of core expressions, so that the resulting dependency graph only contains edges that are part of the source declaration? I assume this can be done by dissolving the declarations starting with '$' or 'lvl', but it would be good to know how to do that reliably. ## Handling inlined declaration When compiling with `-O1`, declarations seem to be inlined in the simplified core. In that case, is it possible to recover the original inlined OccName? If not, I guess we have to use a GHC plugin. I investigated this strategy in [cabal-audit-plugin:CabalAudit.Plugin](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-plugin/src/CabalAudit/Plugin.hs). However I am not sure this is done correctly and I could use some guidances on how to proceed. ## Loading hidden module If I understand correctly, accessing the ModIface mi_extra_decls to get the simplified core requires an HscEnv. In the [cabal-audit-hi:GhcExtras](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-hi/src/GhcExtras.hs) module, I put together the following helpers using GHC as a library: ```haskell -- | Setup a Ghc session using the packages found in the local environment file runGhcWithEnv :: Ghc a -> IO a -- | Lookup a module and extract the simplified core. getCoreBind :: ModuleName -> Maybe FastString -> Ghc (Maybe (Module, [CoreBind])) ``` However this doesn't work for hidden modules, trying to load them with 'GHC.lookupModule' fails with this error: ```ShellSession Could not load module `GHC.Event.Thread' it is a hidden module in the package `base-4.18.0.0' ``` I tried to reset the hsc_env.hsc_dflags.hiddenModules but without luck. Is there a trick to access the ModIface of hidden modules? ## Including simplified core in .hi files by default In the cabal-audit flake, I am using a nix override to set the `-fwrite-if-simplified-core` ghc-options by default and to patch the ghc build phase to use the `+hi_core` hadrian transformers. To avoid rebuilding the dependencies, it would be great to have the simplified core in the hi file by default. Is there an issue or a downside when enabling the flag by default? Could the libraries shipped with GHC contains the simplified core in the future? ## Declaration identifications In the [cabal-audit-command:CabalAudit.Command](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-command/src/CabalAudit/Command.hs) module, I implemented a proof of concept reverse lookup to find reachable declarations. For example using this command: ```ShellSession $ cabal-audit-hi --target GHC.Exception.throw CabalAudit.Test.Simple base:GHC.Exception.throw | `- base:GHC.IO.Handle.Internals.ioe_finalizedHandle | `- base:GHC.IO.Handle.FD.$wstdHandleFinalizer | `- base:GHC.IO.Handle.FD.stdout | +- base:System.IO.putStrLn1 | | | `- base:System.IO.putStrLn | | | `- cabal-audit-test:CabalAudit.Test.Simple.afficheNombre | `- base:System.IO.putStr1 | `- base:System.IO.putStr | `- cabal-audit-test:CabalAudit.Test.Simple.maFonction ``` In the event a vulnerability happens in a type class instance, how to identify the affected instance? Instead of using 'package:Module.$fClassNameDataName', is there an established format we could use (for example "Typeclass X instance of T"). What about data types or type families, would it makes sense to include them in the graph? If so, how to identify them in the advisory database? Please let me know if I miss something. Thanks for your time! -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From sylvain at haskus.fr Wed Aug 9 19:36:04 2023 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 9 Aug 2023 21:36:04 +0200 Subject: [SPAM] Re: Analyzing Haskell call graph (was: Thread on Discourse - HIE file processing) In-Reply-To: <87350s6nnv.tristanC@fedora> References: <87tttkvygs.tristanC@fedora> <87350s6nnv.tristanC@fedora> Message-ID: <2adad4b7-f4e8-4dae-91e4-2c0d8be9fa85@haskus.fr> Hi Tristan, ⁣I wouldn't do this with Core (cf inlining issue and issue associating what you find with source syntax). I think you should use the output of the renamer instead. Either with a GHC plugin using `renamedResultAction` or just by dumping the renamed AST (fully qualified) with -ddump-rn-ast -ddump-to-file and grepping for the names you want. Cheers, Sylvain Le 9 août 2023 à 21:07, à 21:07, Tristan Cacqueray a écrit: > >On Mon, Jul 31, 2023 at 16:26 Tristan Cacqueray wrote: >> On Mon, Jul 31, 2023 at 11:05 David Christiansen via ghc-devs wrote: >>> Dear GHC devs, >>> >>> I think that having automated security advisory warnings from build >tools >>> is important for Haskell adoption in certain industries. This can be >done >>> based on build plans, but a package is really the wrong granularity >- a >>> large, widely-used package might export a little-used definition >that is >>> the subject of an advisory, and it would be good to warn only the >users of >>> said definition (cf base and readFloat). >>> >>> Tristan is exploring using HIE files to do this check, but I don't >know if >>> you read Discourse, where he posted the question: >>> >https://discourse.haskell.org/t/rfc-using-hie-files-to-list-external-declarations-for-cabal-audit/7147 >>> >> >> Thank you David for bringing this up here. One thing to note is that >we >> would need hie files for ghc libraries, as proposed in: >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1337 >> >> Cheers, >> -Tristan > >Dear GHC devs, > >To recap, the goal of this project is to check if a given declaration >is >used by a package. For example, I would like to check if such >definition: "package:Module.name" is reachable from another module. > >In this post I list the considered options, and raise some questions >about using the simplified core from .hi files. > >I would appreciate if you could have a look and help me figure out the >remaining blockers. Note that I'm not very familiar with the GHC >internals and how to properly read Core expressions, so any feedback >would be appreciated. > > ># Context and Problem Statement > >We would like to check if a package is affected by a known >vulnerability. Instead of looking at the build dependencies names and >versions, we would like to search for individual functions. This is >particularly important to avoid false alarm when a given vulnerability >only appears in a rarely used declaration of a popular package. > >Therefor, we need a way to search the whole call graph to assert with >confidence that a given declaration is not used (e.g. reachable). > > ># Considered Options > >To obtain the call graph data, the following options are considered: > >* .hie files produced when using the `-fwrite-ide-info` flag. >* .modpack files produced by the [wpc-plugin][grin]. >* custom GHC plugin. >* .hi files containing the simplified core when using the > `-fwrite-if-simplified-core` flag. > > ># Pros and Cons of the Options > >### Hie files > >This option is similar to what [weeder][weeder] already implements. >However this file format is designed for IDE, and it may not be >suitable >for our problem. For example, RULES, deriving, RebindableSyntax and >template haskell are not well captured. > >[weeder]: https://github.com/ocharles/weeder/ > >### Modpack > >This option appears to work, but it seems overkill. I don't think we >need to reach for STG representation. > >[grin]: >https://github.com/grin-compiler/ghc-whole-program-compiler-project > >### Custom GHC plugin > >This option enables extra metadata to be collected, but if using the >simplified core is enough, then it is just an extra step compared to >using .hi files. > >### Hi files > >Using .hi files is the only option that doesn't require an extra >compilation artifacts, the necessary files are already part of the >packages. > >To collect hie files or files generated by a GHC plugin, >ghc/cabal/stack >all need some extra work: > >- ghc libraries doesn't ship hie files >([issue!16901](https://gitlab.haskell.org/ghc/ghc/-/issues/16901)). >- cabal needs recent changes for hie files >([PR#9019](https://github.com/haskell/cabal/pull/9019)) and plugin >artifacts ([PR#8662](https://github.com/haskell/cabal/pull/8662)). >- stack doesn't seem to install hie files for global library. > >Moreover, creating artifacts with a plugin for ghc libraries may >requires manual steps because these libraries are not built by the >end user. > >Therefor, using .hi files is the most straightforward solution. > > ># Questions > >In this section I present the current implementation of >[cabal-audit](https://github.com/TristanCacqueray/cabal-audit/). > > >## Collecting dependencies from core > >In the >[cabal-audit-core:CabalAudit.Core](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-core/src/CabalAudit/Core.hs) >module I implemented the logic to extract the call graph from core >expression into a list of declarations composed of > `UnitId:ModuleName.OccName` and their dependencies. > >Here is an example output for the >[cabal-audit-test:CabalAudit.Test.User](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-test/src/CabalAudit/Test/User.hs) >module: > >```ShellSession >$ cabal run -O0 --write-ghc-environment=always cabal-audit-hi -- >CabalAudit.Test.User >cabal-audit-test:CabalAudit.Test.Inline.fonctionInlined: >base:GHC.Num.$fNumInt, base:GHC.Num.-, ghc-prim:GHC.Types.I# >cabal-audit-test:CabalAudit.Test.Instance.$fTestClassTea: >cabal-audit-test:CabalAudit.Test.Instance.$ctasty1 >cabal-audit-test:CabalAudit.Test.Instance.$fTestClassCofee: >cabal-audit-test:CabalAudit.Test.Instance.$ctasty >cabal-audit-test:CabalAudit.Test.Instance.$ctasty: >ghc-prim:GHC.Classes.&&, ghc-prim:GHC.Types.True >cabal-audit-test:CabalAudit.Test.Instance.$ctasty1: base:GHC.Base.., >cabal-audit-test:CabalAudit.Test.Instance.alwaysTrue, >ghc-prim:GHC.Classes.not >cabal-audit-test:CabalAudit.Test.Instance.alwaysTrue: >base:GHC.Base.const, ghc-prim:GHC.Types.True >cabal-audit-test:CabalAudit.Test.User.monDoubleDecr: >base:GHC.Num.$fNumInt, base:GHC.Num.-, >cabal-audit-test:CabalAudit.Test.Inline.fonctionInlined, >ghc-prim:GHC.Types.I# >cabal-audit-test:CabalAudit.Test.User.useAlwaysTrue: >cabal-audit-test:CabalAudit.Test.Instance.Tea, >cabal-audit-test:CabalAudit.Test.Instance.$fTestClassTea >cabal-audit-test:CabalAudit.Test.User.useCofeeInstance: >cabal-audit-test:CabalAudit.Test.Instance.Cofee, >cabal-audit-test:CabalAudit.Test.Instance.$fTestClassCofee >``` > >This appears correct, in particular: > >- Type class instances are uniquely identified (that was not working >well when using a custom plugin). >- Inlined declaration are not inlined in the simplified core when built >with `-O0`. > >However this is collecting extra definitions that are not part of the >source file. I understand that '$fTestClassTea' means the 'TestClass' >instance of 'Tea'. But it seems like the actual implementation is >behind >the extra '$ctasty' declaration. Moreover, when analyzing the other >test >modules, I see many declarations named 'lvlXX', which I guess are local >names that have been floated out. > >This is not ideal because the resulting graph contains extra edges that >are not relevant for the end user. I tried to tidy this using >'isExportedId' and 'idDetails' from 'GHC.Types.Var' but I worry that >this not a good strategy. So my question is: how to recover the >original >declarations context of core expressions, so that the resulting >dependency graph only contains edges that are part of the source >declaration? I assume this can be done by dissolving the declarations >starting with '$' or 'lvl', but it would be good to know how to do that >reliably. > > >## Handling inlined declaration > >When compiling with `-O1`, declarations seem to be inlined in the >simplified core. In that case, is it possible to recover the original >inlined OccName? > >If not, I guess we have to use a GHC plugin. >I investigated this strategy in >[cabal-audit-plugin:CabalAudit.Plugin](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-plugin/src/CabalAudit/Plugin.hs). > >However I am not sure this is done correctly and I could use some >guidances on how to proceed. > > >## Loading hidden module > >If I understand correctly, accessing the ModIface mi_extra_decls to get >the simplified core requires an HscEnv. >In the >[cabal-audit-hi:GhcExtras](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-hi/src/GhcExtras.hs) >module, I put together the following helpers using GHC as a library: > >```haskell >-- | Setup a Ghc session using the packages found in the local >environment file >runGhcWithEnv :: Ghc a -> IO a > >-- | Lookup a module and extract the simplified core. >getCoreBind :: ModuleName -> Maybe FastString -> Ghc (Maybe (Module, >[CoreBind])) >``` > >However this doesn't work for hidden modules, trying to load them with >'GHC.lookupModule' fails with this error: > >```ShellSession > Could not load module `GHC.Event.Thread' > it is a hidden module in the package `base-4.18.0.0' >``` > >I tried to reset the hsc_env.hsc_dflags.hiddenModules but without luck. >Is there a trick to access the ModIface of hidden modules? > > >## Including simplified core in .hi files by default > >In the cabal-audit flake, I am using a nix override to set the >`-fwrite-if-simplified-core` ghc-options by default and to patch the >ghc >build phase to use the `+hi_core` hadrian transformers. > >To avoid rebuilding the dependencies, it would be great to have the >simplified core in the hi file by default. >Is there an issue or a downside when enabling the flag by default? >Could the libraries shipped with GHC contains the simplified core in >the >future? > > >## Declaration identifications > >In the >[cabal-audit-command:CabalAudit.Command](https://github.com/TristanCacqueray/cabal-audit/blob/main/cabal-audit-command/src/CabalAudit/Command.hs) >module, I implemented a proof of concept reverse lookup to find >reachable declarations. For example using this command: > >```ShellSession >$ cabal-audit-hi --target GHC.Exception.throw CabalAudit.Test.Simple >base:GHC.Exception.throw >| >`- base:GHC.IO.Handle.Internals.ioe_finalizedHandle > | > `- base:GHC.IO.Handle.FD.$wstdHandleFinalizer > | > `- base:GHC.IO.Handle.FD.stdout > | > +- base:System.IO.putStrLn1 > | | > | `- base:System.IO.putStrLn > | | > | `- cabal-audit-test:CabalAudit.Test.Simple.afficheNombre > | > `- base:System.IO.putStr1 > | > `- base:System.IO.putStr > | > `- cabal-audit-test:CabalAudit.Test.Simple.maFonction >``` > >In the event a vulnerability happens in a type class instance, how to >identify the affected instance? >Instead of using 'package:Module.$fClassNameDataName', is there an >established format we could use (for example "Typeclass X instance of >T"). > >What about data types or type families, would it makes sense to include >them in the graph? If so, how to identify them in the advisory >database? > > >Please let me know if I miss something. >Thanks for your time! >-Tristan > > >------------------------------------------------------------------------ > >_______________________________________________ >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: From cydparser at gmail.com Thu Aug 10 06:19:29 2023 From: cydparser at gmail.com (cydparser) Date: Wed, 9 Aug 2023 23:19:29 -0700 Subject: GitLab approval In-Reply-To: References: Message-ID: I have a GitLab account, but am unable to perform basic actions like fixing broken links on wiki pages or adding a label to a MR that I created. The GHC project overview has a link with "Withdraw Access Request" at the top, so perhaps I need access rather than approval. ---------- Forwarded message ---------- > From: Ben Gamari > To: ghc-devs at haskell.org > Cc: > Bcc: > Date: Wed, 09 Aug 2023 03:07:37 -0400 > Subject: Re: GitLab approval > I am a bit confused. It appears that you account has been active since > 2018. > > > On August 8, 2023 11:55:01 PM EDT, cydparser wrote: > >> Can a GitLab admin please approve my account (@cydparser). Thanks! >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Thu Aug 10 06:36:30 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 10 Aug 2023 09:36:30 +0300 Subject: GitLab approval In-Reply-To: References: Message-ID: Ahhh yes, that explains it. You need (and have requested) the Developer role on the GHC project. I've approved the request, so you should be able to do those things now. On Thu, 10 Aug 2023 at 09:19, cydparser wrote: > I have a GitLab account, but am unable to perform basic actions like > fixing broken links on wiki pages or adding a label to a MR that I created. > The GHC project overview has a link with "Withdraw Access Request" at the > top, so perhaps I need access rather than approval. > > ---------- Forwarded message ---------- >> From: Ben Gamari >> To: ghc-devs at haskell.org >> Cc: >> Bcc: >> Date: Wed, 09 Aug 2023 03:07:37 -0400 >> Subject: Re: GitLab approval >> I am a bit confused. It appears that you account has been active since >> 2018. >> >> >> On August 8, 2023 11:55:01 PM EDT, cydparser wrote: >> >>> Can a GitLab admin please approve my account (@cydparser). Thanks! >>> >> _______________________________________________ > 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: From ben at well-typed.com Thu Aug 10 15:08:14 2023 From: ben at well-typed.com (Ben Gamari) Date: Thu, 10 Aug 2023 11:08:14 -0400 Subject: [ANNOUNCE] GHC 9.8.1-alpha2 is now available Message-ID: <87jzu35415.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha2 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes around two dozen bug-fixes relative to alpha 1. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tdecacqu at redhat.com Thu Aug 10 17:51:41 2023 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 10 Aug 2023 17:51:41 +0000 Subject: Analyzing Haskell call graph (was: Thread on Discourse - HIE file processing) In-Reply-To: <2adad4b7-f4e8-4dae-91e4-2c0d8be9fa85@haskus.fr> References: <87tttkvygs.tristanC@fedora> <87350s6nnv.tristanC@fedora> <2adad4b7-f4e8-4dae-91e4-2c0d8be9fa85@haskus.fr> Message-ID: <87wmy26b0y.tristanC@fedora> Hi Sylvain, Using the output of the renamer looks good. However it doesn't seem like it contains the typeclass instances: when calling a typeclass method for a given type, the AST contains the name of the method and the type, but not the instance. Is it complicated to lookup the relevant instance from the renamer output? Thanks, -Tristan On Wed, Aug 09, 2023 at 21:36 Sylvain Henry wrote: > Hi Tristan, > > ⁣I wouldn't do this with Core (cf inlining issue and issue associating what you find with source syntax). > > I think you should use the output of the renamer instead. Either with a GHC plugin using `renamedResultAction` or just by dumping the renamed AST (fully qualified) with -ddump-rn-ast -ddump-to-file and grepping for the names you want. > > Cheers, > Sylvain > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From alan.zimm at gmail.com Sat Aug 12 14:24:54 2023 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 12 Aug 2023 14:24:54 +0000 Subject: BoxedRep UNPACK pragma Message-ID: I have seen the following warning on master for some time compiler/GHC/Core/TyCon.hs:1540:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘BoxedRep’ • In the definition of data constructor ‘BoxedRep’ In the data type declaration for ‘PrimRep’ | 1540 | | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is it something that needs to be fixed? Can the code be updated to remove the warning? Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 12 15:19:34 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 12 Aug 2023 11:19:34 -0400 Subject: BoxedRep UNPACK pragma In-Reply-To: References: Message-ID: The warning sounds correct to me: `Maybe` has two constructors? On Sat, Aug 12, 2023 at 10:25 AM Alan & Kim Zimmerman wrote: > > I have seen the following warning on master for some time > > compiler/GHC/Core/TyCon.hs:1540:5: warning: > • Ignoring unusable UNPACK pragma > on the first argument of ‘BoxedRep’ > • In the definition of data constructor ‘BoxedRep’ > In the data type declaration for ‘PrimRep’ > | > 1540 | | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Is it something that needs to be fixed? Can the code be updated to remove the warning? > > Alan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b at gmail.com From mikolaj at well-typed.com Sat Aug 12 16:54:26 2023 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sat, 12 Aug 2023 18:54:26 +0200 Subject: BoxedRep UNPACK pragma In-Reply-To: References: Message-ID: On Sat, Aug 12, 2023 at 5:20 PM Brandon Allbery wrote: > > The warning sounds correct to me: `Maybe` has two constructors? It says at https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#unpack-pragma "Since 9.6.1, data types with multiple constructors can also be unpacked, effectively transforming the field into an unboxed sum of the unpackings of each constructor (see UnboxedSums)." > On Sat, Aug 12, 2023 at 10:25 AM Alan & Kim Zimmerman > wrote: > > > > I have seen the following warning on master for some time > > > > compiler/GHC/Core/TyCon.hs:1540:5: warning: > > • Ignoring unusable UNPACK pragma > > on the first argument of ‘BoxedRep’ > > • In the definition of data constructor ‘BoxedRep’ > > In the data type declaration for ‘PrimRep’ > > | > > 1540 | | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value > > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Is it something that needs to be fixed? Can the code be updated to remove the warning? > > > > Alan > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From juhpetersen at gmail.com Tue Aug 15 06:28:29 2023 From: juhpetersen at gmail.com (Jens Petersen) Date: Tue, 15 Aug 2023 14:28:29 +0800 Subject: Problem building 9.4.6 on Fedora 36 (bytestring/cbits/is-valid-utf8.c) In-Reply-To: References: Message-ID: I believe 9.4.7 is coming with a fix for this On Tue, 8 Aug 2023 at 23:44, Viktor Dukhovni wrote: > On Tue, Aug 08, 2023 at 11:33:52AM -0400, Viktor Dukhovni wrote: > > > The build was failing, because rts/OSThreads.h via Rts.h from > > libraries/bytestring/cbits/is-valid-utf8.c had no definition of > > `clockid_t`. This type is not exposed when _POSIX_C_SOURCE is > > not defined to a sufficiently high value: > > Apologies, original $subject should have said 9.4.6. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gergo.Erdi at sc.com Tue Aug 22 06:18:13 2023 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Tue, 22 Aug 2023 06:18:13 +0000 Subject: Weird pipeline failures Message-ID: PUBLIC Hi, On e.g. https://gitlab.haskell.org/ghc/ghc/-/commit/9b4fe2a39952b0a463bcf67f1b357b8364f6725e/pipelines I am seeing very weird failures tagged "yaml invalid": Unable to create pipeline * 'test-primops-validate' job needs 'x86_64-linux-deb10-validate+debug_info' job, but 'x86_64-linux-deb10-validate+debug_info' is not in any previous stage * 'test-primops-validate' job needs 'x86_64-darwin-validate' job, but 'x86_64-darwin-validate' is not in any previous stage Is the CI setup experiencing some temporary hiccup, or is `master` broken? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Aug 22 10:43:58 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 22 Aug 2023 11:43:58 +0100 Subject: Weird pipeline failures In-Reply-To: References: Message-ID: A bad commit made it into master (my fault) and I have now fixed this and rebased your patch over it. Matt On Tue, Aug 22, 2023 at 7:19 AM Erdi, Gergo via ghc-devs wrote: > > PUBLIC > > > Hi, > > > > On e.g. https://gitlab.haskell.org/ghc/ghc/-/commit/9b4fe2a39952b0a463bcf67f1b357b8364f6725e/pipelines I am seeing very weird failures tagged “yaml invalid”: > > > > Unable to create pipeline > > 'test-primops-validate' job needs 'x86_64-linux-deb10-validate+debug_info' job, but 'x86_64-linux-deb10-validate+debug_info' is not in any previous stage > 'test-primops-validate' job needs 'x86_64-darwin-validate' job, but 'x86_64-darwin-validate' is not in any previous stage > > Is the CI setup experiencing some temporary hiccup, or is `master` broken? > > > > Thanks, > > Gergo > > > This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations > > Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From gergo at erdi.hu Tue Aug 22 10:50:48 2023 From: gergo at erdi.hu (=?UTF-8?B?R2VyZ8WRIMOJcmRp?=) Date: Tue, 22 Aug 2023 18:50:48 +0800 Subject: Weird pipeline failures In-Reply-To: References: Message-ID: Thanks! It seems all good now. On Tue, Aug 22, 2023, 18:45 Matthew Pickering wrote: > A bad commit made it into master (my fault) and I have now fixed this > and rebased your patch over it. > > Matt > > On Tue, Aug 22, 2023 at 7:19 AM Erdi, Gergo via ghc-devs > wrote: > > > > PUBLIC > > > > > > Hi, > > > > > > > > On e.g. > https://gitlab.haskell.org/ghc/ghc/-/commit/9b4fe2a39952b0a463bcf67f1b357b8364f6725e/pipelines > I am seeing very weird failures tagged “yaml invalid”: > > > > > > > > Unable to create pipeline > > > > 'test-primops-validate' job needs > 'x86_64-linux-deb10-validate+debug_info' job, but > 'x86_64-linux-deb10-validate+debug_info' is not in any previous stage > > 'test-primops-validate' job needs 'x86_64-darwin-validate' job, but > 'x86_64-darwin-validate' is not in any previous stage > > > > Is the CI setup experiencing some temporary hiccup, or is `master` > broken? > > > > > > > > Thanks, > > > > Gergo > > > > > > This email and any attachments are confidential and may also be > privileged. If you are not the intended recipient, please delete all copies > and notify the sender immediately. You may wish to refer to the > incorporation details of Standard Chartered PLC, Standard Chartered Bank > and their subsidiaries at https: //www.sc.com/en/our-locations > > > > Where you have a Financial Markets relationship with Standard Chartered > PLC, Standard Chartered Bank and their subsidiaries (the "Group"), > information on the regulatory standards we adhere to and how it may affect > you can be found in our Regulatory Compliance Statement at https: // > www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: // > www.sc.com/rcs/fm > > > > Insofar as this communication is not sent by the Global Research team > and contains any market commentary, the market commentary has been prepared > by the sales and/or trading desk of Standard Chartered Bank or its > affiliate. It is not and does not constitute research material, independent > research, recommendation or financial advice. Any market commentary is for > information purpose only and shall not be relied on for any other purpose > and is subject to the relevant disclaimers available at https: // > www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > > > Insofar as this communication is sent by the Global Research team and > contains any research materials prepared by members of the team, the > research material is for information purpose only and shall not be relied > on for any other purpose, and is subject to the relevant disclaimers > available at https: // > research.sc.com/research/api/application/static/terms-and-conditions. > > > > Insofar as this e-mail contains the term sheet for a proposed > transaction, by responding affirmatively to this e-mail, you agree that you > have understood the terms and conditions in the attached term sheet and > evaluated the merits and risks of the transaction. We may at times also > request you to sign the term sheet to acknowledge the same. > > > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ > for important information with respect to derivative products. > > _______________________________________________ > > 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: From arnaud.spiwack at tweag.io Tue Aug 22 12:29:48 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 22 Aug 2023 14:29:48 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: <87jzu35415.fsf@smart-cactus.org> References: <87jzu35415.fsf@smart-cactus.org> Message-ID: Thanks Ben. For the sake of the future announcements, the first item should have s/TypeApplications/TypeApplications/ On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: > > The GHC developers are very pleased to announce the availability of the > second alpha prerelease of GHC 9.8.1. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.8.1-alpha2 > > GHC 9.8 will bring a number of new features and improvements, including: > > * Preliminary support the `TypeApplications` language extension > [type-binders], > allowing types to be bound in type declarations. > > * Support for the `ExtendedLiterals` extension, providing syntax for > non-word-sized numeric literals in the surface language > [extended-literals] > > * Improved rewrite rule matching behavior, allowing limited matching of > higher-order patterns > > * Better support for user-defined warnings by way of the `WARNING` pragma > [warnings] > > * The introduction of the new `GHC.TypeError.Unsatisfiable` > constraint, allowing more predictable user-defined type errors > [unsatisfiable] > > * Implementation of the export deprecation proposal, allowing module > exports to be marked with `DEPRECATE` pragmas [deprecated-exports] > > * The addition of build semaphore support for parallel compilation; > with coming support in `cabal-install` this will allow better use of > parallelism in multi-package builds [jsem] > > * More efficient representation of info table provenance information, > reducing binary sizes by over 50% in some cases when > `-finfo-table-map` is in use > > A full accounting of changes can be found in the [release notes]. > This alpha includes around two dozen bug-fixes relative to alpha 1. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy compiling, > > ~ Ben > > > [type-binders]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst > [extended-literals > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst > [unsatisfiable]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst > [warnings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst > [deprecated-exports > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst > [jsem]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst > [release notes]: > https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.derbyshire at gmail.com Tue Aug 22 12:35:41 2023 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Tue, 22 Aug 2023 14:35:41 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: ... and by that, you presumably mean s/TypeApplications/TypeAbstractions. On Tue, 22 Aug 2023 at 14:30, Arnaud Spiwack wrote: > Thanks Ben. > > For the sake of the future announcements, the first item should have > s/TypeApplications/TypeApplications/ > > > On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: > >> >> The GHC developers are very pleased to announce the availability of the >> second alpha prerelease of GHC 9.8.1. Binary distributions, source >> distributions, and documentation are available at >> >> https://downloads.haskell.org/ghc/9.8.1-alpha2 >> >> GHC 9.8 will bring a number of new features and improvements, including: >> >> * Preliminary support the `TypeApplications` language extension >> [type-binders], >> allowing types to be bound in type declarations. >> >> * Support for the `ExtendedLiterals` extension, providing syntax for >> non-word-sized numeric literals in the surface language >> [extended-literals] >> >> * Improved rewrite rule matching behavior, allowing limited matching of >> higher-order patterns >> >> * Better support for user-defined warnings by way of the `WARNING` >> pragma [warnings] >> >> * The introduction of the new `GHC.TypeError.Unsatisfiable` >> constraint, allowing more predictable user-defined type errors >> [unsatisfiable] >> >> * Implementation of the export deprecation proposal, allowing module >> exports to be marked with `DEPRECATE` pragmas [deprecated-exports] >> >> * The addition of build semaphore support for parallel compilation; >> with coming support in `cabal-install` this will allow better use of >> parallelism in multi-package builds [jsem] >> >> * More efficient representation of info table provenance information, >> reducing binary sizes by over 50% in some cases when >> `-finfo-table-map` is in use >> >> A full accounting of changes can be found in the [release notes]. >> This alpha includes around two dozen bug-fixes relative to alpha 1. >> >> We would like to thank GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell >> Foundation, and other anonymous contributors whose on-going financial >> and in-kind support has facilitated GHC maintenance and release >> management over the years. Finally, this release would not have been >> possible without the hundreds of open-source contributors whose work >> comprise this release. >> >> As always, do give this release a try and open a [ticket] if you see >> anything amiss. >> >> Happy compiling, >> >> ~ Ben >> >> >> [type-binders]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst >> [extended-literals >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst >> [unsatisfiable]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst >> [warnings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst >> [deprecated-exports >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst >> [jsem]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst >> [release notes]: >> https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > 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: From arnaud.spiwack at tweag.io Tue Aug 22 16:32:35 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 22 Aug 2023 18:32:35 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: 😱 Thanks Sam and Noon! I'm obviously great at copy-pasting. On Tue, 22 Aug 2023 at 14:36, Noon van der Silk wrote: > Hey Arnaud, > > > For the sake of the future announcements, the first item should have > s/TypeApplications/TypeApplications/ > > I assume you mean "TypeApplications" instead of "TypeApplications", right? > > :D > > -- > Noon > > > On Tue, 22 Aug 2023 at 13:30, Arnaud Spiwack > wrote: > >> Thanks Ben. >> >> For the sake of the future announcements, the first item should have >> s/TypeApplications/TypeApplications/ >> >> >> On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: >> >>> >>> The GHC developers are very pleased to announce the availability of the >>> second alpha prerelease of GHC 9.8.1. Binary distributions, source >>> distributions, and documentation are available at >>> >>> https://downloads.haskell.org/ghc/9.8.1-alpha2 >>> >>> GHC 9.8 will bring a number of new features and improvements, including: >>> >>> * Preliminary support the `TypeApplications` language extension >>> [type-binders], >>> allowing types to be bound in type declarations. >>> >>> * Support for the `ExtendedLiterals` extension, providing syntax for >>> non-word-sized numeric literals in the surface language >>> [extended-literals] >>> >>> * Improved rewrite rule matching behavior, allowing limited matching of >>> higher-order patterns >>> >>> * Better support for user-defined warnings by way of the `WARNING` >>> pragma [warnings] >>> >>> * The introduction of the new `GHC.TypeError.Unsatisfiable` >>> constraint, allowing more predictable user-defined type errors >>> [unsatisfiable] >>> >>> * Implementation of the export deprecation proposal, allowing module >>> exports to be marked with `DEPRECATE` pragmas [deprecated-exports] >>> >>> * The addition of build semaphore support for parallel compilation; >>> with coming support in `cabal-install` this will allow better use of >>> parallelism in multi-package builds [jsem] >>> >>> * More efficient representation of info table provenance information, >>> reducing binary sizes by over 50% in some cases when >>> `-finfo-table-map` is in use >>> >>> A full accounting of changes can be found in the [release notes]. >>> This alpha includes around two dozen bug-fixes relative to alpha 1. >>> >>> We would like to thank GitHub, IOG, the Zw3rk stake pool, >>> Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell >>> Foundation, and other anonymous contributors whose on-going financial >>> and in-kind support has facilitated GHC maintenance and release >>> management over the years. Finally, this release would not have been >>> possible without the hundreds of open-source contributors whose work >>> comprise this release. >>> >>> As always, do give this release a try and open a [ticket] if you see >>> anything amiss. >>> >>> Happy compiling, >>> >>> ~ Ben >>> >>> >>> [type-binders]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst >>> [extended-literals >>> ]: >>> >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst >>> [unsatisfiable]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst >>> [warnings]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst >>> [deprecated-exports >>> ]: >>> >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst >>> [jsem]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst >>> [release notes]: >>> https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html >>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Arnaud Spiwack >> Director, Research at https://moduscreate.com and https://tweag.io. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Aug 23 19:07:40 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 23 Aug 2023 15:07:40 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: <87350937d3.fsf@smart-cactus.org> Arnaud Spiwack writes: > 😱 > Thanks Sam and Noon! I'm obviously great at copy-pasting. > Regardless, thanks for bringing the mistake to my attention. It will be fixed with the next alpha. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu Aug 24 01:30:10 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 23 Aug 2023 21:30:10 -0400 Subject: [ANNOUNCE] GHC 9.8.1-alpha3 is now available Message-ID: <87zg2h1b39.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha3 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes roughly a dozen changes relative to alpha 2, including what we believe should be nearly the last changes to GHC's boot libraries. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha3/docs/users_guide/9.8.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.peytonjones at gmail.com Thu Aug 24 16:47:26 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 24 Aug 2023 17:47:26 +0100 Subject: Library module naming Message-ID: Friends I am keen to complete discussion on HF tech proposal 53 which is about the naming convention for modules in base, ghc-experimental, ghc-internal, etc. I think it's done. Any views? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Aug 25 22:04:59 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 25 Aug 2023 18:04:59 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.6 is now available In-Reply-To: <87edke7slk.fsf@smart-cactus.org> References: <87edke7slk.fsf@smart-cactus.org> Message-ID: you like to 9.4.6 instead of .7 ... On Mon, Aug 7, 2023 at 11:58 AM Ben Gamari wrote: > > The GHC developers are happy to announce the availability of GHC 9.4.6. > Binary > distributions, source distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.4.6 > > This release is primarily a bugfix release addressing some issues > found in 9.4.6. These include: > > * Many bug fixes for the simplifier, preventing compiler panics, loops and > incorrect code generation (#22761, #22549, #23208, #22761, #22272, > #23146, > #23012, #22547). > * Bug fixes for the typechecker involving newtype family instances, making > type equalities more robust and bugs having to do with defaulting > representation > polymorphic type variables (#23329, #23333, #23143, #23154, #23176). > * Some bug fixes for code generation, particularly on the aarch64 backend, > including adding more memory barriers for array read operations > (#23541, #23749). > * Some bug fixes for windows builds, ensuring the reliablility of IO > manager shutdown > and a bug fix for the RTS linker on windows (#23691, #22941). > * A bug fix for the non-moving GC ensuring mutator allocations are > properly > accounted for (#23312). > * A bug fix preventing some segfaults by ensuring that pinned allocations > respect > block size (#23400). > * Many bug fixes for the bytecode interpreter, allowing a greater subset > of the language to be interpreted (#22376, #22840, #22051, #21945, > #23068, #22958). > * ... and a few more. See the [release notes] for a full accounting. > > As some of the fixed issues do affect correctness users are encouraged to > upgrade promptly. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, > Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and > other anonymous contributors whose on-going financial and in-kind support > has > facilitated GHC maintenance and release management over the years. Finally, > this release would not have been possible without the hundreds of > open-source > contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy compiling, > > - Zubin & Ben > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: > https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sat Aug 26 10:38:46 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 26 Aug 2023 16:08:46 +0530 Subject: [ANNOUNCE] GHC 9.4.7 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.4.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.4.7 The GHC developers are happy to announce the availability of GHC 9.4.7. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.7). This release is primarily a bugfix release addressing some issues found in 9.4.6. These include: * A bump to bytestring-0.11.5.2 allowing GHC to be bootstrapped on systems where the bootstrap compiler is built with the `pthread_condattr_setclock` symbol available (#23789). * A number of bug fixes for scoping bugs in the specialiser, preventing simplifier panics (#21391, #21689, #21828, #23762). * Distributing dynamically linked alpine bindists (#23349, #23828). * A bug fix for the release notes syntax, allowing them to built on systems with older python and sphinx versions (#23807, #23818). * ... and a few more. See the [release notes] for a full accounting. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.7/docs/users_guide/9.4.7-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: