From ben at well-typed.com Fri Mar 3 21:57:11 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 03 Mar 2023 16:57:11 -0500 Subject: [ANNOUNCE] GHC 9.6.1-rc1 is now available Message-ID: <87a60tqz1h.fsf@smart-cactus.org> The GHC team is very pleased to announce the availability of the first (and likely final) release candidate of GHC 9.6.1. As usual, binaries and source distributions are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.6.1-rc1/). Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes][] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket][] if you see anything amiss. If all goes well we expect the final release should be available by late next week. Happy Haskelling, ~ Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-rc1/docs/users_guide/9.6.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From ryan.gl.scott at gmail.com Wed Mar 8 12:24:22 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 8 Mar 2023 07:24:22 -0500 Subject: Call for 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/ Important dates --------------- Deadline: July 4, 2023 (AoE) Notification: August 4, 2023 Workshop: September 4, 2023 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. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and short lightning talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2023. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides, and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community 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 Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com until July 4 (anywhere on earth). We will also have a lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Gergő Érdi (Standard Chartered Bank) * Sebastian Graf (Karlsruhe Institute of Technology) * Wen Kokke (University of Strathclyde) * Ryan Scott (Galois, Inc.) * Rebecca Skinner (Mercury) * Li-yao Xia (University of Edinburgh) Contact ------- * Ryan Scott From ben at well-typed.com Sun Mar 12 02:14:12 2023 From: ben at well-typed.com (Ben Gamari) Date: Sat, 11 Mar 2023 21:14:12 -0500 Subject: [ANNOUNCE] GHC 9.6.1 is now available Message-ID: <87edpupvhh.fsf@smart-cactus.org> The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 includes: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively. Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC's first step towards supporting web targets, we are very excited to have this release out the door! Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From laurent.decotret at outlook.com Sun Mar 12 13:39:23 2023 From: laurent.decotret at outlook.com (=?iso-8859-1?Q?Laurent_P=2E_Ren=E9_de_Cotret?=) Date: Sun, 12 Mar 2023 13:39:23 +0000 Subject: Buy-in for technical proposal 47 which affect GHC devs Message-ID: Dear GHC developers, In recent weeks, John Ericson has fine-tuned a Haskell Foundation Technical Proposal to split `base` into two libraries: `ghc-base` and `base`, the latter simply re-exporting everything for `ghc-base` (for now). You can read about the rationale and specifics more in details in the proposal itself: https://github.com/haskellfoundation/tech-proposals/pull/47 Note that this proposal has recently been streamlined into a form which is more focused than its initial state, and might be worth a re-read. The Haskell Foundation Technical Working Group has reached a consensus that this work will benefit the Haskell community. Moreover, the Haskell Foundation has agreed to spend some of its resources to implement this proposal, which would start by ensuring the completion of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898). This work will affect GHC developers. Therefore, the Technical Working Group would like to get buy-in from the GHC developers before formally accepting this proposal. Best regards, Laurent P. René de Cotret on behalf of the Haskell Foundation Technical Working Group From ietf-dane at dukhovni.org Sun Mar 12 21:23:47 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 12 Mar 2023 17:23:47 -0400 Subject: [ANNOUNCE] GHC 9.6.1 is now available In-Reply-To: <87edpupvhh.fsf@smart-cactus.org> References: <87edpupvhh.fsf@smart-cactus.org> Message-ID: On Sat, Mar 11, 2023 at 09:14:12PM -0500, Ben Gamari wrote: > The GHC team is very pleased to announce the availability of GHC 9.6.1. > As usual, binaries and source distributions are available at > downloads.haskell.org: > > https://downloads.haskell.org/ghc/9.6.1/ Is anyone else having trouble building 9.6.1 from upstream source. a58c028a18 (HEAD -> ghc-9.6, tag: ghc-9.6.1-release, origin/ghc-9.6) Fix TBA in base changelog 1f5bce0db8 Set RELEASE=YES 87ab8e353f Bump haddock submodule to 2.28 ... My attempts on a Fedora 36 system are so far unsuccessful, with both GCC and Clang-14 as the C compilers, and GHC 9.4.4 as the bootstrap GHC. The build fails when "HsBase.h" is not found during the "stage1" build of the ghc-bignum library. -- Viktor. From harendra.kumar at gmail.com Tue Mar 14 16:51:51 2023 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 14 Mar 2023 22:21:51 +0530 Subject: GHC API documentation Message-ID: Hi, There used to be a GHC API documentation along with other documentation in the GHC release. But I cannot find it any more. For example, in GHC 9.6.1 this link - https://downloads.haskell.org/ghc/9.6.1/docs/libraries/ghc/index.html is broken. What happened to this? Is this now available at some alternate location? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From rraghu.11502 at gmail.com Tue Mar 14 17:13:28 2023 From: rraghu.11502 at gmail.com (Razetime) Date: Tue, 14 Mar 2023 22:43:28 +0530 Subject: Understanding how warnings on unused functions work Message-ID: This message is related to a feature in the futhark compiler , which is a language with a similar module system. I am trying to create a tool to detect unused top-level functions in Futhark, and I have been looking in the ghc codebase to find out how it does so. So far I have found these areas: 1. warning flag 2. WarnUnusedTopBinds The project is a bit too big for my machine to take, so HLS is not helping me with finding where the computation of unused bindings (specifically functions) is done. I would like some help with finding where ghc does this computation, and maybe some help with the naming conventions of the code. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Mar 14 17:49:44 2023 From: ben at well-typed.com (Ben Gamari) Date: Tue, 14 Mar 2023 13:49:44 -0400 Subject: GHC API documentation In-Reply-To: References: Message-ID: <87bkkvp6jz.fsf@smart-cactus.org> Harendra Kumar writes: > Hi, > > > There used to be a GHC API documentation along with other documentation in > the GHC release. But I cannot find it any more. For example, in GHC 9.6.1 > this link - > https://downloads.haskell.org/ghc/9.6.1/docs/libraries/ghc/index.html is > broken. > > What happened to this? Is this now available at some alternate location? > The URL is now https://downloads.haskell.org/ghc/9.6.1/docs/libraries/ghc-9.6.1/index.html. However, it is rather concerning that the link on https://downloads.haskell.org/ghc/9.6.1/docs/ is broken. I've opened #23121 to track this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From harendra.kumar at gmail.com Tue Mar 14 18:42:01 2023 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 15 Mar 2023 00:12:01 +0530 Subject: GHC API documentation In-Reply-To: <87bkkvp6jz.fsf@smart-cactus.org> References: <87bkkvp6jz.fsf@smart-cactus.org> Message-ID: Thanks Ben. The link is broken in GHC 9.4.4 as well. But works in 9.2.x . On Tue, 14 Mar 2023 at 23:19, Ben Gamari wrote: > Harendra Kumar writes: > > > Hi, > > > > > > There used to be a GHC API documentation along with other documentation > in > > the GHC release. But I cannot find it any more. For example, in GHC 9.6.1 > > this link - > > https://downloads.haskell.org/ghc/9.6.1/docs/libraries/ghc/index.html is > > broken. > > > > What happened to this? Is this now available at some alternate location? > > > The URL is now > https://downloads.haskell.org/ghc/9.6.1/docs/libraries/ghc-9.6.1/index.html > . > > However, it is rather concerning that the link on > https://downloads.haskell.org/ghc/9.6.1/docs/ is broken. > I've opened #23121 to track this. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Mar 15 11:23:29 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 15 Mar 2023 11:23:29 +0000 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Redirecting this query to ghc-devs. Can anyone help William? Thanks! Will GHC run on my new MacBook Air? After installing the compiler, my > laptop said its processor was wrong for the binary distribution I chose. If > there is a dmg file for MacOS 12.5.1, please please link your reply to it. > Simon On Tue, 14 Mar 2023 at 23:33, William McEnaney wrote: > Dear Dr. Jones, > > Will GHC run on my new MacBook Air? After installing the compiler, my > laptop said its processor was wrong for the binary distribution I chose. If > there is a dmg file for MacOS 12.5.1, please please link your reply to it. > > Thanks for your help. > > Best, > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Mar 15 11:59:03 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 08:59:03 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Hi Bill Yes,GHC will run on your new MacBook Air. The cpu in that is Apple Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, the x86_64-apple-darwin platform. I'm not sure how you installed the compiler. I believe the standard way is described on https://www.haskell.org/ghcup/. Can you tell us how you installed it? Thanks George On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Redirecting this query to ghc-devs. Can anyone help William? Thanks! > > Will GHC run on my new MacBook Air? After installing the compiler, my >> laptop said its processor was wrong for the binary distribution I chose. If >> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >> > > Simon > > On Tue, 14 Mar 2023 at 23:33, William McEnaney > wrote: > >> Dear Dr. Jones, >> >> Will GHC run on my new MacBook Air? After installing the compiler, my >> laptop said its processor was wrong for the binary distribution I chose. If >> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >> >> Thanks for your help. >> >> Best, >> Bill >> > _______________________________________________ > 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 george.colpitts at gmail.com Wed Mar 15 12:09:16 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 09:09:16 -0300 Subject: Installing GHC on my MacBook Air Message-ID: Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi Bill I just noticed that you said you installed a binary distribution. If for example you chose the 9.4.4 distribution at https://www.haskell.org/ghc/download_ghc_9_4_4.html#macosx_x86_64 you should choose one of: [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (george.colpitts[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: George Colpitts Subject: Re: Installing GHC on my MacBook Air Date: Wed, 15 Mar 2023 09:09:16 -0300 Size: 13459 URL: From simon.peytonjones at gmail.com Wed Mar 15 12:38:29 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 15 Mar 2023 12:38:29 +0000 Subject: Help! Can't build HEAD Message-ID: Aargh! I can't build HEAD! I get this: ./hadrian/build Up to date ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no rule available: utils/hpc/hpc-bin.cabal Build failed. This is after hadrian/build clean ./boot ./configure I'm very stalled. All my trees are borked. Can anyone help? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Wed Mar 15 12:40:50 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 15 Mar 2023 12:40:50 +0000 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: You need to run `git submodule update` I think. On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones wrote: > > Aargh! I can't build HEAD! > > I get this: > ./hadrian/build > Up to date > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no rule available: > utils/hpc/hpc-bin.cabal > Build failed. > > > This is after > hadrian/build clean > ./boot > ./configure > > I'm very stalled. All my trees are borked. Can anyone help? > > Simon From sam.derbyshire at gmail.com Wed Mar 15 12:46:00 2023 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Wed, 15 Mar 2023 13:46:00 +0100 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: Perhaps even `git submodule update --init`. On Wed, 15 Mar 2023 at 13:41, Matthew Pickering wrote: > You need to run `git submodule update` I think. > > On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones > wrote: > > > > Aargh! I can't build HEAD! > > > > I get this: > > ./hadrian/build > > Up to date > > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no > rule available: > > utils/hpc/hpc-bin.cabal > > Build failed. > > > > > > This is after > > hadrian/build clean > > ./boot > > ./configure > > > > I'm very stalled. All my trees are borked. Can anyone help? > > > > Simon > _______________________________________________ > 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 Wed Mar 15 12:54:01 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 15 Mar 2023 12:54:01 +0000 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: I forgot to say -- I always do `git submodule update`. On this occasion it's a no op S On Wed, 15 Mar 2023 at 12:41, Matthew Pickering wrote: > You need to run `git submodule update` I think. > > On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones > wrote: > > > > Aargh! I can't build HEAD! > > > > I get this: > > ./hadrian/build > > Up to date > > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no > rule available: > > utils/hpc/hpc-bin.cabal > > Build failed. > > > > > > This is after > > hadrian/build clean > > ./boot > > ./configure > > > > I'm very stalled. All my trees are borked. Can anyone help? > > > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Mar 15 12:54:44 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 15 Mar 2023 12:54:44 +0000 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: Oh I didn't know you had to say "--init". Anyway that fails git submodule update --init Submodule 'utils/hpc' (https://gitlab.haskell.org/hpc/hpc-bin.git) registered for path 'utils/hpc' fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already exists and is not an empty directory. fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed Failed to clone 'utils/hpc'. Retry scheduled fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already exists and is not an empty directory. fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed Failed to clone 'utils/hpc' a second time, aborting simonpj at LHR-WD-22561:~/code/HEAD-15$ Simon On Wed, 15 Mar 2023 at 12:46, Sam Derbyshire wrote: > Perhaps even `git submodule update --init`. > > On Wed, 15 Mar 2023 at 13:41, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > >> You need to run `git submodule update` I think. >> >> On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones >> wrote: >> > >> > Aargh! I can't build HEAD! >> > >> > I get this: >> > ./hadrian/build >> > Up to date >> > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no >> rule available: >> > utils/hpc/hpc-bin.cabal >> > Build failed. >> > >> > >> > This is after >> > hadrian/build clean >> > ./boot >> > ./configure >> > >> > I'm very stalled. All my trees are borked. Can anyone help? >> > >> > Simon >> _______________________________________________ >> 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 Wed Mar 15 12:57:03 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 15 Mar 2023 12:57:03 +0000 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: Ah. rm utils/hpc git submodule update does the job. Who would have guessed that? Maybe this thread will help others. Could hadrian have avoided this, perhaps? Anyway, I'm rolling again, thanks Simon On Wed, 15 Mar 2023 at 12:54, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Oh I didn't know you had to say "--init". Anyway that fails > > git submodule update --init > Submodule 'utils/hpc' (https://gitlab.haskell.org/hpc/hpc-bin.git) > registered for path 'utils/hpc' > fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already > exists and is not an empty directory. > fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into > submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed > Failed to clone 'utils/hpc'. Retry scheduled > fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already > exists and is not an empty directory. > fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into > submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed > Failed to clone 'utils/hpc' a second time, aborting > simonpj at LHR-WD-22561:~/code/HEAD-15$ > > Simon > > On Wed, 15 Mar 2023 at 12:46, Sam Derbyshire > wrote: > >> Perhaps even `git submodule update --init`. >> >> On Wed, 15 Mar 2023 at 13:41, Matthew Pickering < >> matthewtpickering at gmail.com> wrote: >> >>> You need to run `git submodule update` I think. >>> >>> On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones >>> wrote: >>> > >>> > Aargh! I can't build HEAD! >>> > >>> > I get this: >>> > ./hadrian/build >>> > Up to date >>> > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no >>> rule available: >>> > utils/hpc/hpc-bin.cabal >>> > Build failed. >>> > >>> > >>> > This is after >>> > hadrian/build clean >>> > ./boot >>> > ./configure >>> > >>> > I'm very stalled. All my trees are borked. Can anyone help? >>> > >>> > Simon >>> _______________________________________________ >>> 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 sgraf1337 at gmail.com Wed Mar 15 13:44:46 2023 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Wed, 15 Mar 2023 13:44:46 +0000 Subject: Help! Can't build HEAD In-Reply-To: References: Message-ID: Hi Simon, I had that very issue a few days ago, but saw this thread too late. For me it was enough to cd into utils/hpc and do a `git checkout .`. Sebastian ------ Originalnachricht ------ Von: "Simon Peyton Jones" An: "Sam Derbyshire" Cc: "Sam Derbyshire" ; "GHC developers" Gesendet: 15.03.2023 13:57:03 Betreff: Re: Help! Can't build HEAD >Ah. > >rm utils/hpc >git submodule update > >does the job. Who would have guessed that? Maybe this thread will >help others. > >Could hadrian have avoided this, perhaps? > >Anyway, I'm rolling again, thanks > >Simon > >On Wed, 15 Mar 2023 at 12:54, Simon Peyton Jones > wrote: >>Oh I didn't know you had to say "--init". Anyway that fails >> >>git submodule update --init >>Submodule 'utils/hpc' (https://gitlab.haskell.org/hpc/hpc-bin.git) >>registered for path 'utils/hpc' >>fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already >>exists and is not an empty directory. >>fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into >>submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed >>Failed to clone 'utils/hpc'. Retry scheduled >>fatal: destination path '/home/simonpj/code/HEAD-15/utils/hpc' already >>exists and is not an empty directory. >>fatal: clone of 'https://gitlab.haskell.org/hpc/hpc-bin.git' into >>submodule path '/home/simonpj/code/HEAD-15/utils/hpc' failed >>Failed to clone 'utils/hpc' a second time, aborting >>simonpj at LHR-WD-22561:~/code/HEAD-15$ >> >>Simon >> >>On Wed, 15 Mar 2023 at 12:46, Sam Derbyshire >> wrote: >>>Perhaps even `git submodule update --init`. >>> >>>On Wed, 15 Mar 2023 at 13:41, Matthew Pickering >>> wrote: >>>>You need to run `git submodule update` I think. >>>> >>>>On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones >>>> wrote: >>>> > >>>> > Aargh! I can't build HEAD! >>>> > >>>> > I get this: >>>> > ./hadrian/build >>>> > Up to date >>>> > ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and >>>>no rule available: >>>> > utils/hpc/hpc-bin.cabal >>>> > Build failed. >>>> > >>>> > >>>> > This is after >>>> > hadrian/build clean >>>> > ./boot >>>> > ./configure >>>> > >>>> > I'm very stalled. All my trees are borked. Can anyone help? >>>> > >>>> > Simon >>>>_______________________________________________ >>>>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 hecate at glitchbra.in Wed Mar 15 15:28:56 2023 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Wed, 15 Mar 2023 16:28:56 +0100 Subject: Coordination on FreeBSD CI, default WinIO and Info Tables profiling work Message-ID: <5941b280-8bab-176c-57a9-7ba235bb160f@glitchbra.in> Hi everyone, I have created topical aggregators of tickets that go beyond the rhythm of releases (aka. "epics") for  the following topics: * Info Tables Profiling: https://gitlab.haskell.org/groups/ghc/-/epics/3 * Setting WinIO "on" by default: https://gitlab.haskell.org/groups/ghc/-/epics/4 * FreeBSD CI revival: https://gitlab.haskell.org/groups/ghc/-/epics/5 These epics have no deadline and their purpose is to track the evolution of our workload for certain "big" tasks that go beyond a single ticket. They are also useful as they are a (albeit imprecise) tool to help determine after the fact the magnitude of a project and the efforts it took. This will certainly be helpful for future estimations. And finally their prime purpose is to enable more awareness about our co-contributors work, so that we get all a better sense of what it takes to do certain things. :) Please do feel free to create your own for projects that are not fit for a single milestone (or are not related to release milestones at all). Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From george.colpitts at gmail.com Wed Mar 15 16:03:36 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 13:03:36 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Hi Bill I'm cc'ing GHC dev and GHC users as someone else may have a better answer, catch a mistake I made etc. Please don't delete them. I believe you have encountered https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 I believe the way to fix this is to do the following: rm -fr /usr/local/bin/ghc* rm -fr /usr/local/lib/ghc* ./configure sudo xattr -rc . sudo make install However I am unsure why you are encountering this as the issue is supposed to have been fixed. Cheers George On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < bill.mcenaney.jr at gmail.com> wrote: > Hi, George, > > I got this message when I ran make install with the sudo command. What > should I do? > > *libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple > cannot check it for malicious software.* > > > What should I do now? > > > Thanks. > > > Bill > > > > > On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < > bill.mcenaney.jr at gmail.com> wrote: > >> Hi George, >> >> Thank you for your reply. I forget what I did to install it. But the >> compiler and other ghc-related programs live in /usr/local/bin. Since I >> installed the wrong binaries, I changed the directory to /usr/local/bin and >> tried to empty that directory with *rm -rf ghc*.**, but that didn't >> delete anything. So I wonder whether I'll need to remove those programs >> before reinstalling ghc. >> >> Thanks for your help, too. >> >> Best, >> Bill >> >> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>> Hi Bill >>> >>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple >>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, >>> the x86_64-apple-darwin platform. >>> >>> I'm not sure how you installed the compiler. I believe the standard way >>> is described on https://www.haskell.org/ghcup/. Can you tell us how you >>> installed it? >>> >>> Thanks >>> George >>> >>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>>> Redirecting this query to ghc-devs. Can anyone help William? Thanks! >>>> >>>> Will GHC run on my new MacBook Air? After installing the compiler, my >>>>> laptop said its processor was wrong for the binary distribution I chose. If >>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>>> >>>> >>>> Simon >>>> >>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >>>>> Dear Dr. Jones, >>>>> >>>>> Will GHC run on my new MacBook Air? After installing the compiler, my >>>>> laptop said its processor was wrong for the binary distribution I chose. If >>>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>>> >>>>> Thanks for your help. >>>>> >>>>> Best, >>>>> Bill >>>>> >>>> _______________________________________________ >>>> 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 allbery.b at gmail.com Wed Mar 15 16:10:13 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 15 Mar 2023 12:10:13 -0400 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: That seems unlikely; it would report a permission error in that case, not that it had the wrong architecture. On Wed, Mar 15, 2023 at 12:04 PM George Colpitts wrote: > > Hi Bill > > I'm cc'ing GHC dev and GHC users as someone else may have a better answer, catch a mistake I made etc. Please don't delete them. > > I believe you have encountered https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 > > I believe the way to fix this is to do the following: > > rm -fr /usr/local/bin/ghc* > rm -fr /usr/local/lib/ghc* > ./configure > sudo xattr -rc . > sudo make install > > > However I am unsure why you are encountering this as the issue is supposed to have been fixed. > > Cheers > George > > > > > > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney wrote: >> >> Hi, George, >> >> I got this message when I ran make install with the sudo command. What should I do? >> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple cannot check it for malicious software. >> >> >> What should I do now? >> >> >> Thanks. >> >> >> Bill >> >> >> >> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney wrote: >>> >>> Hi George, >>> >>> Thank you for your reply. I forget what I did to install it. But the compiler and other ghc-related programs live in /usr/local/bin. Since I installed the wrong binaries, I changed the directory to /usr/local/bin and tried to empty that directory with rm -rf ghc*.*, but that didn't delete anything. So I wonder whether I'll need to remove those programs before reinstalling ghc. >>> >>> Thanks for your help, too. >>> >>> Best, >>> Bill >>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts wrote: >>>> >>>> Hi Bill >>>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, the x86_64-apple-darwin platform. >>>> >>>> I'm not sure how you installed the compiler. I believe the standard way is described on https://www.haskell.org/ghcup/. Can you tell us how you installed it? >>>> >>>> Thanks >>>> George >>>> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones wrote: >>>>> >>>>> Redirecting this query to ghc-devs. Can anyone help William? Thanks! >>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, my laptop said its processor was wrong for the binary distribution I chose. If there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>>> >>>>> >>>>> Simon >>>>> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney wrote: >>>>>> >>>>>> Dear Dr. Jones, >>>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, my laptop said its processor was wrong for the binary distribution I chose. If there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>>>> >>>>>> Thanks for your help. >>>>>> >>>>>> Best, >>>>>> Bill >>>>> >>>>> _______________________________________________ >>>>> 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 -- brandon s allbery kf8nh allbery.b at gmail.com From george.colpitts at gmail.com Wed Mar 15 16:22:59 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 13:22:59 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: cc'ing others On Wed, Mar 15, 2023 at 1:20 PM George Colpitts wrote: > Thanks Brandon. There were some earlier emails that somehow got dropped > from this. > > I believe we have already solved the wrong architecture issue; this is the > next issue. > > Here is the earlier email: > > I just noticed that you said you installed a binary distribution. If for > example you chose the 9.4.4 distribution at > https://www.haskell.org/ghc/download_ghc_9_4_4.html#macosx_x86_64 you > should choose one of: > > > - ghc-9.4.4-aarch64-apple-darwin.tar.xz > (187.0 > MB, sig > > ) > - ghc-9.4.4-aarch64-apple-darwin.tar.bz2 > (300.0 > MB, sig > > ) > > rather than > > > - ghc-9.4.4-x86_64-apple-darwin.tar.xz > (177.9 > MB, sig > > ) > - ghc-9.4.4-x86_64-apple-darwin.tar.bz2 > (281.9 > MB, sig > > ) > > > On Wed, Mar 15, 2023 at 1:10 PM Brandon Allbery > wrote: > >> That seems unlikely; it would report a permission error in that case, >> not that it had the wrong architecture. >> >> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts >> wrote: >> > >> > Hi Bill >> > >> > I'm cc'ing GHC dev and GHC users as someone else may have a better >> answer, catch a mistake I made etc. Please don't delete them. >> > >> > I believe you have encountered >> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 >> > >> > I believe the way to fix this is to do the following: >> > >> > rm -fr /usr/local/bin/ghc* >> > rm -fr /usr/local/lib/ghc* >> > ./configure >> > sudo xattr -rc . >> > sudo make install >> > >> > >> > However I am unsure why you are encountering this as the issue is >> supposed to have been fixed. >> > >> > Cheers >> > George >> > >> > >> > >> > >> > >> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >> >> >> Hi, George, >> >> >> >> I got this message when I ran make install with the sudo command. What >> should I do? >> >> >> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >> cannot check it for malicious software. >> >> >> >> >> >> What should I do now? >> >> >> >> >> >> Thanks. >> >> >> >> >> >> Bill >> >> >> >> >> >> >> >> >> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>> >> >>> Hi George, >> >>> >> >>> Thank you for your reply. I forget what I did to install it. But the >> compiler and other ghc-related programs live in /usr/local/bin. Since I >> installed the wrong binaries, I changed the directory to /usr/local/bin and >> tried to empty that directory with rm -rf ghc*.*, but that didn't delete >> anything. So I wonder whether I'll need to remove those programs before >> reinstalling ghc. >> >>> >> >>> Thanks for your help, too. >> >>> >> >>> Best, >> >>> Bill >> >>> >> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>>> >> >>>> Hi Bill >> >>>> >> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple >> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, >> the x86_64-apple-darwin platform. >> >>>> >> >>>> I'm not sure how you installed the compiler. I believe the standard >> way is described on https://www.haskell.org/ghcup/. Can you tell us how >> you installed it? >> >>>> >> >>>> Thanks >> >>>> George >> >>>> >> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>>>> >> >>>>> Redirecting this query to ghc-devs. Can anyone help William? >> Thanks! >> >>>>> >> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, >> my laptop said its processor was wrong for the binary distribution I chose. >> If there is a dmg file for MacOS 12.5.1, please please link your reply to >> it. >> >>>>> >> >>>>> >> >>>>> Simon >> >>>>> >> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>>>>> >> >>>>>> Dear Dr. Jones, >> >>>>>> >> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, >> my laptop said its processor was wrong for the binary distribution I chose. >> If there is a dmg file for MacOS 12.5.1, please please link your reply to >> it. >> >>>>>> >> >>>>>> Thanks for your help. >> >>>>>> >> >>>>>> Best, >> >>>>>> Bill >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >> >> >> -- >> brandon s allbery kf8nh >> allbery.b at gmail.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Mar 15 16:25:35 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 15 Mar 2023 12:25:35 -0400 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: <874jqmoud9.fsf@smart-cactus.org> George Colpitts writes: > Hi Bill > > I'm cc'ing GHC dev and GHC users as someone else may have a better answer, > catch a mistake I made etc. Please don't delete them. > > I believe you have encountered > https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 > > I believe the way to fix this is to do the following: > > rm -fr /usr/local/bin/ghc* > rm -fr /usr/local/lib/ghc* > ./configure > sudo xattr -rc . > sudo make install > > > However I am unsure why you are encountering this as the issue is supposed > to have been fixed. > It may be that the reason is either a GHC bug (https://gitlab.haskell.org/ghc/ghc/-/issues/23009) or further changes by Apple (https://gitlab.haskell.org/ghc/ghc/-/issues/23115) Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From george.colpitts at gmail.com Wed Mar 15 16:26:16 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 13:26:16 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Bill For your latest problem libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple cannot check it for malicious software. Did you try what I wrote in my last email: rm -fr /usr/local/bin/ghc* rm -fr /usr/local/lib/ghc* ./configure sudo xattr -rc . sudo make install George On Wed, Mar 15, 2023 at 1:20 PM William McEnaney wrote: > Hi, everyone, > > Thank you for the help. Someone will tell me how to solve the problem, I > hope because it stumped me. > > Bill > > On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery > wrote: > >> That seems unlikely; it would report a permission error in that case, >> not that it had the wrong architecture. >> >> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts >> wrote: >> > >> > Hi Bill >> > >> > I'm cc'ing GHC dev and GHC users as someone else may have a better >> answer, catch a mistake I made etc. Please don't delete them. >> > >> > I believe you have encountered >> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 >> > >> > I believe the way to fix this is to do the following: >> > >> > rm -fr /usr/local/bin/ghc* >> > rm -fr /usr/local/lib/ghc* >> > ./configure >> > sudo xattr -rc . >> > sudo make install >> > >> > >> > However I am unsure why you are encountering this as the issue is >> supposed to have been fixed. >> > >> > Cheers >> > George >> > >> > >> > >> > >> > >> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >> >> >> Hi, George, >> >> >> >> I got this message when I ran make install with the sudo command. What >> should I do? >> >> >> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >> cannot check it for malicious software. >> >> >> >> >> >> What should I do now? >> >> >> >> >> >> Thanks. >> >> >> >> >> >> Bill >> >> >> >> >> >> >> >> >> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>> >> >>> Hi George, >> >>> >> >>> Thank you for your reply. I forget what I did to install it. But the >> compiler and other ghc-related programs live in /usr/local/bin. Since I >> installed the wrong binaries, I changed the directory to /usr/local/bin and >> tried to empty that directory with rm -rf ghc*.*, but that didn't delete >> anything. So I wonder whether I'll need to remove those programs before >> reinstalling ghc. >> >>> >> >>> Thanks for your help, too. >> >>> >> >>> Best, >> >>> Bill >> >>> >> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >> george.colpitts at gmail.com> wrote: >> >>>> >> >>>> Hi Bill >> >>>> >> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple >> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, >> the x86_64-apple-darwin platform. >> >>>> >> >>>> I'm not sure how you installed the compiler. I believe the standard >> way is described on https://www.haskell.org/ghcup/. Can you tell us how >> you installed it? >> >>>> >> >>>> Thanks >> >>>> George >> >>>> >> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>>>> >> >>>>> Redirecting this query to ghc-devs. Can anyone help William? >> Thanks! >> >>>>> >> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, >> my laptop said its processor was wrong for the binary distribution I chose. >> If there is a dmg file for MacOS 12.5.1, please please link your reply to >> it. >> >>>>> >> >>>>> >> >>>>> Simon >> >>>>> >> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>>>>> >> >>>>>> Dear Dr. Jones, >> >>>>>> >> >>>>>> Will GHC run on my new MacBook Air? After installing the compiler, >> my laptop said its processor was wrong for the binary distribution I chose. >> If there is a dmg file for MacOS 12.5.1, please please link your reply to >> it. >> >>>>>> >> >>>>>> Thanks for your help. >> >>>>>> >> >>>>>> Best, >> >>>>>> Bill >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >> >> >> -- >> brandon s allbery kf8nh >> allbery.b at gmail.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Mar 15 16:40:48 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 13:40:48 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Hi William I think it's best if you submit a bug as described here Whether in email or in the bug report it is critical that you describe how the reader can reproduce the bug, i.e. starting from the beginning, describe what you did and what error message(s) you got. Regards, George On Wed, Mar 15, 2023 at 1:34 PM William McEnaney wrote: > Hi, George, > > Yes, I did. But I must have made a mistake. After I pasted them into a > Terminal window, the machine warned me that some program wanted to access > my photos when I don't have any. > > > On Wed, Mar 15, 2023 at 12:26 PM George Colpitts < > george.colpitts at gmail.com> wrote: > >> Bill >> >> For your latest problem >> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >> cannot check it for malicious software. >> >> Did you try what I wrote in my last email: >> >> rm -fr /usr/local/bin/ghc* >> rm -fr /usr/local/lib/ghc* >> ./configure >> sudo xattr -rc . >> sudo make install >> >> George >> >> >> >> >> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>> Hi, everyone, >>> >>> Thank you for the help. Someone will tell me how to solve the problem, I >>> hope because it stumped me. >>> >>> Bill >>> >>> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery >>> wrote: >>> >>>> That seems unlikely; it would report a permission error in that case, >>>> not that it had the wrong architecture. >>>> >>>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts >>>> wrote: >>>> > >>>> > Hi Bill >>>> > >>>> > I'm cc'ing GHC dev and GHC users as someone else may have a better >>>> answer, catch a mistake I made etc. Please don't delete them. >>>> > >>>> > I believe you have encountered >>>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 >>>> > >>>> > I believe the way to fix this is to do the following: >>>> > >>>> > rm -fr /usr/local/bin/ghc* >>>> > rm -fr /usr/local/lib/ghc* >>>> > ./configure >>>> > sudo xattr -rc . >>>> > sudo make install >>>> > >>>> > >>>> > However I am unsure why you are encountering this as the issue is >>>> supposed to have been fixed. >>>> > >>>> > Cheers >>>> > George >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >> >>>> >> Hi, George, >>>> >> >>>> >> I got this message when I ran make install with the sudo command. >>>> What should I do? >>>> >> >>>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >>>> cannot check it for malicious software. >>>> >> >>>> >> >>>> >> What should I do now? >>>> >> >>>> >> >>>> >> Thanks. >>>> >> >>>> >> >>>> >> Bill >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >>> >>>> >>> Hi George, >>>> >>> >>>> >>> Thank you for your reply. I forget what I did to install it. But >>>> the compiler and other ghc-related programs live in /usr/local/bin. Since I >>>> installed the wrong binaries, I changed the directory to /usr/local/bin and >>>> tried to empty that directory with rm -rf ghc*.*, but that didn't delete >>>> anything. So I wonder whether I'll need to remove those programs before >>>> reinstalling ghc. >>>> >>> >>>> >>> Thanks for your help, too. >>>> >>> >>>> >>> Best, >>>> >>> Bill >>>> >>> >>>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >>>> george.colpitts at gmail.com> wrote: >>>> >>>> >>>> >>>> Hi Bill >>>> >>>> >>>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple >>>> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, >>>> the x86_64-apple-darwin platform. >>>> >>>> >>>> >>>> I'm not sure how you installed the compiler. I believe the >>>> standard way is described on https://www.haskell.org/ghcup/. Can you >>>> tell us how you installed it? >>>> >>>> >>>> >>>> Thanks >>>> >>>> George >>>> >>>> >>>> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >>>> simon.peytonjones at gmail.com> wrote: >>>> >>>>> >>>> >>>>> Redirecting this query to ghc-devs. Can anyone help William? >>>> Thanks! >>>> >>>>> >>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>> compiler, my laptop said its processor was wrong for the binary >>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>> please link your reply to it. >>>> >>>>> >>>> >>>>> >>>> >>>>> Simon >>>> >>>>> >>>> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >>>>>> >>>> >>>>>> Dear Dr. Jones, >>>> >>>>>> >>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>> compiler, my laptop said its processor was wrong for the binary >>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>> please link your reply to it. >>>> >>>>>> >>>> >>>>>> Thanks for your help. >>>> >>>>>> >>>> >>>>>> Best, >>>> >>>>>> Bill >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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 >>>> >>>> >>>> >>>> -- >>>> brandon s allbery kf8nh >>>> allbery.b at gmail.com >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Mar 15 17:17:18 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 14:17:18 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Hi Bill, It's easy to forget to do replay all in gmail but it's important to do so in these emails. In your original email you wrote: After installing the compiler, my laptop said its processor was wrong for the binary distribution I chose. If there is a dmg file for *MacOS 12.5.1,* please please link your reply to it. Can you confirm that you no longer have the problem "of processor was wrong for the binary distribution I chose." ? My understanding is that after that you got the error: libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple cannot check it for malicious software. I then suggested you had encountered https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 and I suggested you do: rm -fr /usr/local/bin/ghc* rm -fr /usr/local/lib/ghc* ./configure sudo xattr -rc . sudo make install You said you did and got a warning "that some program wanted to access my photos when I don't have any." Can you repeat those steps and cut and paste your terminal session into an email? Unfortunately I am too busy to continue replying but with the above I think somebody will be able to help you. Cheers, George On Wed, Mar 15, 2023 at 1:59 PM William McEnaney wrote: > Hi, George, > > I'd be happy to do that for you. But I'm sure I can recall the information > a GHC maintainer would need. > > Best, > Bill > > On Wed, Mar 15, 2023 at 12:41 PM George Colpitts < > george.colpitts at gmail.com> wrote: > >> Hi William >> >> I think it's best if you submit a bug as described here >> >> >> Whether in email or in the bug report it is critical that you >> describe how the reader can reproduce the bug, i.e. starting from the >> beginning, describe what you did and what error message(s) you got. >> >> Regards, >> George >> >> >> On Wed, Mar 15, 2023 at 1:34 PM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>> Hi, George, >>> >>> Yes, I did. But I must have made a mistake. After I pasted them into a >>> Terminal window, the machine warned me that some program wanted to access >>> my photos when I don't have any. >>> >>> >>> On Wed, Mar 15, 2023 at 12:26 PM George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> Bill >>>> >>>> For your latest problem >>>> >>>> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >>>> cannot check it for malicious software. >>>> >>>> Did you try what I wrote in my last email: >>>> >>>> rm -fr /usr/local/bin/ghc* >>>> rm -fr /usr/local/lib/ghc* >>>> ./configure >>>> sudo xattr -rc . >>>> sudo make install >>>> >>>> George >>>> >>>> >>>> >>>> >>>> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >>>>> Hi, everyone, >>>>> >>>>> Thank you for the help. Someone will tell me how to solve the problem, >>>>> I hope because it stumped me. >>>>> >>>>> Bill >>>>> >>>>> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery >>>>> wrote: >>>>> >>>>>> That seems unlikely; it would report a permission error in that case, >>>>>> not that it had the wrong architecture. >>>>>> >>>>>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts >>>>>> wrote: >>>>>> > >>>>>> > Hi Bill >>>>>> > >>>>>> > I'm cc'ing GHC dev and GHC users as someone else may have a better >>>>>> answer, catch a mistake I made etc. Please don't delete them. >>>>>> > >>>>>> > I believe you have encountered >>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 >>>>>> > >>>>>> > I believe the way to fix this is to do the following: >>>>>> > >>>>>> > rm -fr /usr/local/bin/ghc* >>>>>> > rm -fr /usr/local/lib/ghc* >>>>>> > ./configure >>>>>> > sudo xattr -rc . >>>>>> > sudo make install >>>>>> > >>>>>> > >>>>>> > However I am unsure why you are encountering this as the issue is >>>>>> supposed to have been fixed. >>>>>> > >>>>>> > Cheers >>>>>> > George >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < >>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>> >> >>>>>> >> Hi, George, >>>>>> >> >>>>>> >> I got this message when I ran make install with the sudo command. >>>>>> What should I do? >>>>>> >> >>>>>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because >>>>>> Apple cannot check it for malicious software. >>>>>> >> >>>>>> >> >>>>>> >> What should I do now? >>>>>> >> >>>>>> >> >>>>>> >> Thanks. >>>>>> >> >>>>>> >> >>>>>> >> Bill >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < >>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>> >>> >>>>>> >>> Hi George, >>>>>> >>> >>>>>> >>> Thank you for your reply. I forget what I did to install it. But >>>>>> the compiler and other ghc-related programs live in /usr/local/bin. Since I >>>>>> installed the wrong binaries, I changed the directory to /usr/local/bin and >>>>>> tried to empty that directory with rm -rf ghc*.*, but that didn't delete >>>>>> anything. So I wonder whether I'll need to remove those programs before >>>>>> reinstalling ghc. >>>>>> >>> >>>>>> >>> Thanks for your help, too. >>>>>> >>> >>>>>> >>> Best, >>>>>> >>> Bill >>>>>> >>> >>>>>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >>>>>> george.colpitts at gmail.com> wrote: >>>>>> >>>> >>>>>> >>>> Hi Bill >>>>>> >>>> >>>>>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is >>>>>> Apple Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel >>>>>> chips, the x86_64-apple-darwin platform. >>>>>> >>>> >>>>>> >>>> I'm not sure how you installed the compiler. I believe the >>>>>> standard way is described on https://www.haskell.org/ghcup/. Can you >>>>>> tell us how you installed it? >>>>>> >>>> >>>>>> >>>> Thanks >>>>>> >>>> George >>>>>> >>>> >>>>>> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >>>>>> simon.peytonjones at gmail.com> wrote: >>>>>> >>>>> >>>>>> >>>>> Redirecting this query to ghc-devs. Can anyone help William? >>>>>> Thanks! >>>>>> >>>>> >>>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>>>> compiler, my laptop said its processor was wrong for the binary >>>>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>>>> please link your reply to it. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Simon >>>>>> >>>>> >>>>>> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear Dr. Jones, >>>>>> >>>>>> >>>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>>>> compiler, my laptop said its processor was wrong for the binary >>>>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>>>> please link your reply to it. >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your help. >>>>>> >>>>>> >>>>>> >>>>>> Best, >>>>>> >>>>>> Bill >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> brandon s allbery kf8nh >>>>>> allbery.b at gmail.com >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Mar 15 18:14:07 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 15 Mar 2023 15:14:07 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Somehow I missed that it is now working for you. Great! Definitely no need to report a bug. Haskell is a great language. Enjoy! Cheers George On Wed, Mar 15, 2023 at 3:07 PM William McEnaney wrote: > Hi, George, > > Now that the compiler runs, maybe I don't need to report a bug. > ... > Thanks for everything. > > Bill > > On Wed, Mar 15, 2023 at 1:17 PM George Colpitts > wrote: > >> Hi Bill, >> >> It's easy to forget to do replay all in gmail but it's important to do so >> in these emails. >> >> In your original email you wrote: >> >> After installing the compiler, my laptop said its processor was wrong for >> the binary distribution I chose. If there is a dmg file for *MacOS >> 12.5.1,* please please link your reply to it. >> >> >> Can you confirm that you no longer have the problem "of processor was >> wrong for the binary distribution I chose." ? >> >> My understanding is that after that you got the error: >> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >> cannot check it for malicious software. >> >> I then suggested you had encountered >> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 and I >> suggested you do: >> >> rm -fr /usr/local/bin/ghc* >> rm -fr /usr/local/lib/ghc* >> ./configure >> sudo xattr -rc . >> sudo make install >> >> >> You said you did and got a warning "that some program wanted to access my >> photos when I don't have any." >> >> Can you repeat those steps and cut and paste your terminal session into >> an email? >> >> Unfortunately I am too busy to continue replying but with the above I >> think somebody will be able to help you. >> >> Cheers, >> George >> >> >> On Wed, Mar 15, 2023 at 1:59 PM William McEnaney < >> bill.mcenaney.jr at gmail.com> wrote: >> >>> Hi, George, >>> >>> I'd be happy to do that for you. But I'm sure I can recall the >>> information a GHC maintainer would need. >>> >>> Best, >>> Bill >>> >>> On Wed, Mar 15, 2023 at 12:41 PM George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> Hi William >>>> >>>> I think it's best if you submit a bug as described here >>>> >>>> >>>> Whether in email or in the bug report it is critical that you >>>> describe how the reader can reproduce the bug, i.e. starting from the >>>> beginning, describe what you did and what error message(s) you got. >>>> >>>> Regards, >>>> George >>>> >>>> >>>> On Wed, Mar 15, 2023 at 1:34 PM William McEnaney < >>>> bill.mcenaney.jr at gmail.com> wrote: >>>> >>>>> Hi, George, >>>>> >>>>> Yes, I did. But I must have made a mistake. After I pasted them into a >>>>> Terminal window, the machine warned me that some program wanted to access >>>>> my photos when I don't have any. >>>>> >>>>> >>>>> On Wed, Mar 15, 2023 at 12:26 PM George Colpitts < >>>>> george.colpitts at gmail.com> wrote: >>>>> >>>>>> Bill >>>>>> >>>>>> For your latest problem >>>>>> >>>>>> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because Apple >>>>>> cannot check it for malicious software. >>>>>> >>>>>> Did you try what I wrote in my last email: >>>>>> >>>>>> rm -fr /usr/local/bin/ghc* >>>>>> rm -fr /usr/local/lib/ghc* >>>>>> ./configure >>>>>> sudo xattr -rc . >>>>>> sudo make install >>>>>> >>>>>> George >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 15, 2023 at 1:20 PM William McEnaney < >>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>> >>>>>>> Hi, everyone, >>>>>>> >>>>>>> Thank you for the help. Someone will tell me how to solve >>>>>>> the problem, I hope because it stumped me. >>>>>>> >>>>>>> Bill >>>>>>> >>>>>>> On Wed, Mar 15, 2023 at 12:10 PM Brandon Allbery < >>>>>>> allbery.b at gmail.com> wrote: >>>>>>> >>>>>>>> That seems unlikely; it would report a permission error in that >>>>>>>> case, >>>>>>>> not that it had the wrong architecture. >>>>>>>> >>>>>>>> On Wed, Mar 15, 2023 at 12:04 PM George Colpitts >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > Hi Bill >>>>>>>> > >>>>>>>> > I'm cc'ing GHC dev and GHC users as someone else may have a >>>>>>>> better answer, catch a mistake I made etc. Please don't delete them. >>>>>>>> > >>>>>>>> > I believe you have encountered >>>>>>>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506#note_447206 >>>>>>>> > >>>>>>>> > I believe the way to fix this is to do the following: >>>>>>>> > >>>>>>>> > rm -fr /usr/local/bin/ghc* >>>>>>>> > rm -fr /usr/local/lib/ghc* >>>>>>>> > ./configure >>>>>>>> > sudo xattr -rc . >>>>>>>> > sudo make install >>>>>>>> > >>>>>>>> > >>>>>>>> > However I am unsure why you are encountering this as the issue is >>>>>>>> supposed to have been fixed. >>>>>>>> > >>>>>>>> > Cheers >>>>>>>> > George >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > On Wed, Mar 15, 2023 at 11:21 AM William McEnaney < >>>>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>>>> >> >>>>>>>> >> Hi, George, >>>>>>>> >> >>>>>>>> >> I got this message when I ran make install with the sudo >>>>>>>> command. What should I do? >>>>>>>> >> >>>>>>>> >> libHSterminfo-0.4.1.5-ghc9.4.4.dylib” can’t be opened because >>>>>>>> Apple cannot check it for malicious software. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> What should I do now? >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Thanks. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> Bill >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Wed, Mar 15, 2023 at 9:29 AM William McEnaney < >>>>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>>>> >>> >>>>>>>> >>> Hi George, >>>>>>>> >>> >>>>>>>> >>> Thank you for your reply. I forget what I did to install it. >>>>>>>> But the compiler and other ghc-related programs live in /usr/local/bin. >>>>>>>> Since I installed the wrong binaries, I changed the directory to >>>>>>>> /usr/local/bin and tried to empty that directory with rm -rf ghc*.*, but >>>>>>>> that didn't delete anything. So I wonder whether I'll need to remove those >>>>>>>> programs before reinstalling ghc. >>>>>>>> >>> >>>>>>>> >>> Thanks for your help, too. >>>>>>>> >>> >>>>>>>> >>> Best, >>>>>>>> >>> Bill >>>>>>>> >>> >>>>>>>> >>> On Wed, Mar 15, 2023 at 7:59 AM George Colpitts < >>>>>>>> george.colpitts at gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hi Bill >>>>>>>> >>>> >>>>>>>> >>>> Yes,GHC will run on your new MacBook Air. The cpu in that is >>>>>>>> Apple Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel >>>>>>>> chips, the x86_64-apple-darwin platform. >>>>>>>> >>>> >>>>>>>> >>>> I'm not sure how you installed the compiler. I believe the >>>>>>>> standard way is described on https://www.haskell.org/ghcup/. Can >>>>>>>> you tell us how you installed it? >>>>>>>> >>>> >>>>>>>> >>>> Thanks >>>>>>>> >>>> George >>>>>>>> >>>> >>>>>>>> >>>> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >>>>>>>> simon.peytonjones at gmail.com> wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> Redirecting this query to ghc-devs. Can anyone help >>>>>>>> William? Thanks! >>>>>>>> >>>>> >>>>>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>>>>>> compiler, my laptop said its processor was wrong for the binary >>>>>>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>>>>>> please link your reply to it. >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> Simon >>>>>>>> >>>>> >>>>>>>> >>>>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >>>>>>>> bill.mcenaney.jr at gmail.com> wrote: >>>>>>>> >>>>>> >>>>>>>> >>>>>> Dear Dr. Jones, >>>>>>>> >>>>>> >>>>>>>> >>>>>> Will GHC run on my new MacBook Air? After installing the >>>>>>>> compiler, my laptop said its processor was wrong for the binary >>>>>>>> distribution I chose. If there is a dmg file for MacOS 12.5.1, please >>>>>>>> please link your reply to it. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Thanks for your help. >>>>>>>> >>>>>> >>>>>>>> >>>>>> Best, >>>>>>>> >>>>>> Bill >>>>>>>> >>>>> >>>>>>>> >>>>> _______________________________________________ >>>>>>>> >>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> brandon s allbery kf8nh >>>>>>>> allbery.b at gmail.com >>>>>>>> >>>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Mar 16 09:59:46 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 16 Mar 2023 09:59:46 +0000 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: Message-ID: Thanks Laurent, In fact this fits with our thinking in https://github.com/haskell/core-libraries-committee/issues/105. We'll discuss and Ben/Matthew will get back to you. Simon On Sun, 12 Mar 2023 at 13:39, Laurent P. René de Cotret < laurent.decotret at outlook.com> wrote: > Dear GHC developers, > > In recent weeks, John Ericson has fine-tuned a Haskell Foundation > Technical Proposal to split `base` into two libraries: `ghc-base` and > `base`, the latter simply re-exporting everything for `ghc-base` (for now). > You can read about the rationale and specifics more in details in the > proposal itself: > https://github.com/haskellfoundation/tech-proposals/pull/47 > > Note that this proposal has recently been streamlined into a form which is > more focused than its initial state, and might be worth a re-read. > > The Haskell Foundation Technical Working Group has reached a consensus > that this work will benefit the Haskell community. Moreover, the Haskell > Foundation has agreed to spend some of its resources to implement this > proposal, which would start by ensuring the completion of MR7898 ( > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898). > > This work will affect GHC developers. Therefore, the Technical Working > Group would like to get buy-in from the GHC developers before formally > accepting this proposal. > > Best regards, > Laurent P. René de Cotret > on behalf of the Haskell Foundation Technical Working Group > _______________________________________________ > 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 david at haskell.foundation Thu Mar 16 13:20:40 2023 From: david at haskell.foundation (David Christiansen) Date: Thu, 16 Mar 2023 14:20:40 +0100 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: Message-ID: Hi Simon, As a bit of context here, CLC issue 105 was definitely part of the discussions leading to the refinement of this proposal (and we also brought some of that over from the discussions that you participated in in the Stability Working Group). Please feel free to get in touch with any questions or concerns - as the ones closest to GHC, you're of course best placed to see things that we may have overlooked. Thanks! David On Thu, Mar 16, 2023 at 10:58 AM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Thanks Laurent, > > In fact this fits with our thinking in > https://github.com/haskell/core-libraries-committee/issues/105. We'll > discuss and Ben/Matthew will get back to you. > > Simon > > On Sun, 12 Mar 2023 at 13:39, Laurent P. René de Cotret < > laurent.decotret at outlook.com> wrote: > >> Dear GHC developers, >> >> In recent weeks, John Ericson has fine-tuned a Haskell Foundation >> Technical Proposal to split `base` into two libraries: `ghc-base` and >> `base`, the latter simply re-exporting everything for `ghc-base` (for now). >> You can read about the rationale and specifics more in details in the >> proposal itself: >> https://github.com/haskellfoundation/tech-proposals/pull/47 >> >> Note that this proposal has recently been streamlined into a form which >> is more focused than its initial state, and might be worth a re-read. >> >> The Haskell Foundation Technical Working Group has reached a consensus >> that this work will benefit the Haskell community. Moreover, the Haskell >> Foundation has agreed to spend some of its resources to implement this >> proposal, which would start by ensuring the completion of MR7898 ( >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898). >> >> This work will affect GHC developers. Therefore, the Technical Working >> Group would like to get buy-in from the GHC developers before formally >> accepting this proposal. >> >> Best regards, >> Laurent P. René de Cotret >> on behalf of the Haskell Foundation Technical Working Group >> _______________________________________________ >> 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 george.colpitts at gmail.com Fri Mar 17 12:12:46 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 17 Mar 2023 09:12:46 -0300 Subject: Installing GHC on my MacBook Air In-Reply-To: References: Message-ID: Type the following at the command line: xcode-select --install and then try ghci again. I'm not sure what you mean by "the software" in the phrase "Should I delete and reinstall the software you told me to install?" but in any case don't delete anything. Please try to be as specific as possible. When you first encounter a problem you should Google for a solution. If that doesn't work you can send mail to me but also cc ghc-devs at haskell.org and glasgow-haskell-users at haskell.org Cheers George On Thu, Mar 16, 2023 at 11:09 PM William McEnaney < bill.mcenaney.jr at gmail.com> wrote: > Hi, George, > > Sorry to bother you. Though ghc seems to run properly, here's what ghci > prints on my screen. What mistake did I make? Should I delete and reinstall > the software you told me to install? > > "GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help > > xcrun: error: invalid active developer path > (/Library/Developer/CommandLineTools), missing xcrun at: > /Library/Developer/CommandLineTools/usr/bin/xcrun > > `gcc' failed in phase `gcc'. (Exit code: 1) > > williammcenaney at Williams-Air bin" > > > Thanks. > > > Bill > > > Bill > > On Wed, Mar 15, 2023 at 7:59 AM George Colpitts > wrote: > >> Hi Bill >> >> Yes,GHC will run on your new MacBook Air. The cpu in that is Apple >> Silicon , the aarch64-apple-darwin platform. Older Macs run on Intel chips, >> the x86_64-apple-darwin platform. >> >> I'm not sure how you installed the compiler. I believe the standard way >> is described on https://www.haskell.org/ghcup/. Can you tell us how you >> installed it? >> >> Thanks >> George >> >> On Wed, Mar 15, 2023 at 8:22 AM Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> Redirecting this query to ghc-devs. Can anyone help William? Thanks! >>> >>> Will GHC run on my new MacBook Air? After installing the compiler, my >>>> laptop said its processor was wrong for the binary distribution I chose. If >>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>> >>> >>> Simon >>> >>> On Tue, 14 Mar 2023 at 23:33, William McEnaney < >>> bill.mcenaney.jr at gmail.com> wrote: >>> >>>> Dear Dr. Jones, >>>> >>>> Will GHC run on my new MacBook Air? After installing the compiler, my >>>> laptop said its processor was wrong for the binary distribution I chose. If >>>> there is a dmg file for MacOS 12.5.1, please please link your reply to it. >>>> >>>> Thanks for your help. >>>> >>>> Best, >>>> Bill >>>> >>> _______________________________________________ >>> 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 Sat Mar 18 13:00:51 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sat, 18 Mar 2023 13:00:51 +0000 Subject: CI Message-ID: All GHC CI pipelines seem stalled, sadly e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines Can someone unglue it? Thanks! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.derbyshire at gmail.com Sat Mar 18 13:05:44 2023 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Sat, 18 Mar 2023 14:05:44 +0100 Subject: CI In-Reply-To: References: Message-ID: I think there's a problem with jobs restarting, on my renamer MR there were 5 full pipelines running at once. I had to cancel some of them, but also it seems some got cancelled by some new CI pipelines restarting. On Sat, 18 Mar 2023 at 13:59, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > All GHC CI pipelines seem stalled, sadly > > e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines > > Can someone unglue it? > > Thanks! > > Simon > _______________________________________________ > 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 bryan at haskell.foundation Sat Mar 18 15:55:07 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sat, 18 Mar 2023 17:55:07 +0200 Subject: CI In-Reply-To: References: Message-ID: I'm away from my computer for the day, but yes there were some jobs that got stuck in a restart loop. See https://gitlab.haskell.org/ghc/ghc/-/issues/23094#note_487426 . Unfortunately I don't know if there are others, but I did fix the root cause of that particular loop. On Sat, 18 Mar 2023, 15.06 Sam Derbyshire, wrote: > I think there's a problem with jobs restarting, on my renamer MR > there were 5 > full pipelines running at once. I had to cancel some of them, but also it > seems some got cancelled by some new CI pipelines restarting. > > On Sat, 18 Mar 2023 at 13:59, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> All GHC CI pipelines seem stalled, sadly >> >> e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines >> >> Can someone unglue it? >> >> Thanks! >> >> Simon >> _______________________________________________ >> 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 bryan at haskell.foundation Sun Mar 19 11:27:26 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sun, 19 Mar 2023 13:27:26 +0200 Subject: CI Message-ID: Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: I'm back at my computer and am investigating. I don't see the problem I feared, but I do see some anomalies. I'll update once it's back to normal. On Sat, 18 Mar 2023 at 17:55, Bryan Richter wrote: [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: Bryan Richter Subject: Re: CI Date: Sun, 19 Mar 2023 13:27:26 +0200 Size: 7667 URL: From bryan at haskell.foundation Sun Mar 19 12:42:50 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sun, 19 Mar 2023 14:42:50 +0200 Subject: CI In-Reply-To: References: Message-ID: I did find that some jobs were being retried repeatedly. I have deployed a workaround to prevent this from continuing. The problem was related to T18623 behaving strangely, and I've opened https://gitlab.haskell.org/ghc/ghc/-/issues/23139 so GHC devs can have a look at it. On Sun, 19 Mar 2023 at 13:27, Bryan Richter wrote: > I'm back at my computer and am investigating. I don't see the problem I > feared, but I do see some anomalies. I'll update once it's back to normal. > > On Sat, 18 Mar 2023 at 17:55, Bryan Richter > wrote: > >> I'm away from my computer for the day, but yes there were some jobs that >> got stuck in a restart loop. See >> https://gitlab.haskell.org/ghc/ghc/-/issues/23094#note_487426 . >> Unfortunately I don't know if there are others, but I did fix the root >> cause of that particular loop. >> >> On Sat, 18 Mar 2023, 15.06 Sam Derbyshire, >> wrote: >> >>> I think there's a problem with jobs restarting, on my renamer MR >>> there were 5 >>> full pipelines running at once. I had to cancel some of them, but also it >>> seems some got cancelled by some new CI pipelines restarting. >>> >>> On Sat, 18 Mar 2023 at 13:59, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>>> All GHC CI pipelines seem stalled, sadly >>>> >>>> e.g. >>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines >>>> >>>> Can someone unglue it? >>>> >>>> Thanks! >>>> >>>> Simon >>>> _______________________________________________ >>>> 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 bryan at haskell.foundation Sun Mar 19 17:04:39 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sun, 19 Mar 2023 19:04:39 +0200 Subject: CI In-Reply-To: References: Message-ID: Hoo boy... now I've fixed an even *bigger* problem that is pretty embarrassing. https://gitlab.haskell.org/ghc/ghc-perf-import/-/commit/67238099e9c3478ba591080c6e582985c62b83c0 It's time to give this service a proper testsuite. On Sun, 19 Mar 2023 at 14:42, Bryan Richter wrote: > I did find that some jobs were being retried repeatedly. I have deployed a > workaround to prevent this from continuing. The problem was related to > T18623 behaving strangely, and I've opened > https://gitlab.haskell.org/ghc/ghc/-/issues/23139 so GHC devs can have a > look at it. > > On Sun, 19 Mar 2023 at 13:27, Bryan Richter > wrote: > >> I'm back at my computer and am investigating. I don't see the problem I >> feared, but I do see some anomalies. I'll update once it's back to normal. >> >> On Sat, 18 Mar 2023 at 17:55, Bryan Richter >> wrote: >> >>> I'm away from my computer for the day, but yes there were some jobs that >>> got stuck in a restart loop. See >>> https://gitlab.haskell.org/ghc/ghc/-/issues/23094#note_487426 . >>> Unfortunately I don't know if there are others, but I did fix the root >>> cause of that particular loop. >>> >>> On Sat, 18 Mar 2023, 15.06 Sam Derbyshire, >>> wrote: >>> >>>> I think there's a problem with jobs restarting, on my renamer MR >>>> there were >>>> 5 full pipelines running at once. I had to cancel some of them, but also it >>>> seems some got cancelled by some new CI pipelines restarting. >>>> >>>> On Sat, 18 Mar 2023 at 13:59, Simon Peyton Jones < >>>> simon.peytonjones at gmail.com> wrote: >>>> >>>>> All GHC CI pipelines seem stalled, sadly >>>>> >>>>> e.g. >>>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines >>>>> >>>>> Can someone unglue it? >>>>> >>>>> Thanks! >>>>> >>>>> Simon >>>>> _______________________________________________ >>>>> 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 baulig at protonmail.com Mon Mar 20 02:05:16 2023 From: baulig at protonmail.com (Martin Baulig) Date: Mon, 20 Mar 2023 02:05:16 +0000 Subject: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue Message-ID: Hello, I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor the GHC 9.2.7 binary packages from GHCUP work anymore. There are two issues - and I wrote a detailed article about my investigation on Medium: https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" into > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" Otherwise, this will break when both ccArgs and ldFlags are non-empty: > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" Unfortunately, this is not quite it just yet. The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always invoking hsc2hs with an explicit --cc= argument. Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last name in lowercase, baulig. Looking forward to hear back from you, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Mar 20 12:41:08 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 20 Mar 2023 14:41:08 +0200 Subject: GitLab partial outage - attempting to mitigate Message-ID: I am seeing a few different problems with the GitLab server right now. I am gonna try to mitigate the issues, so the server might be unavailable for a few short periods. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Mar 20 13:11:51 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 20 Mar 2023 15:11:51 +0200 Subject: GitLab partial outage - attempting to mitigate In-Reply-To: References: Message-ID: I eventually resorted to a server reboot, which cleared up all the problems I was seeing. I think we're back in business. Symptoms were: * No new data coming into https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&from=now-7d&to=now&refresh=30m * High-frequency repetition of the system log message "systemd-journald[1622008]: Failed to open runtime journal: Device or resource busy" * ~50% failure rate connecting to the server with ssh None of those are happening anymore. -Bryan On Mon, 20 Mar 2023 at 14:41, Bryan Richter wrote: > I am seeing a few different problems with the GitLab server right now. I > am gonna try to mitigate the issues, so the server might be unavailable for > a few short periods. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Mar 20 13:25:04 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 20 Mar 2023 09:25:04 -0400 Subject: GitLab partial outage - attempting to mitigate In-Reply-To: References: Message-ID: <87lejro8rt.fsf@smart-cactus.org> Bryan Richter via ghc-devs writes: > I eventually resorted to a server reboot, which cleared up all the problems > I was seeing. I think we're back in business. > The root partition was close to running out of disk space yesterday. The problem appears to be that /nix is located on the small system drive. We should really address this although moving /nix is sadly not easy and will certainly require downtime. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From allbery.b at gmail.com Mon Mar 20 13:40:58 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 20 Mar 2023 09:40:58 -0400 Subject: GitLab partial outage - attempting to mitigate In-Reply-To: <87lejro8rt.fsf@smart-cactus.org> References: <87lejro8rt.fsf@smart-cactus.org> Message-ID: Isn't it just "move /nix out of the way, bind mount a new one from a larger drive, use rsync to move the data"? On Mon, Mar 20, 2023 at 9:25 AM Ben Gamari wrote: > > Bryan Richter via ghc-devs writes: > > > I eventually resorted to a server reboot, which cleared up all the problems > > I was seeing. I think we're back in business. > > > The root partition was close to running out of disk space yesterday. The > problem appears to be that /nix is located on the small system drive. We > should really address this although moving /nix is sadly not easy and > will certainly require downtime. > > Cheers, > > - Ben > > _______________________________________________ > 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 ben at well-typed.com Mon Mar 20 13:44:41 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 20 Mar 2023 09:44:41 -0400 Subject: GitLab partial outage - attempting to mitigate In-Reply-To: <87lejro8rt.fsf@smart-cactus.org> References: <87lejro8rt.fsf@smart-cactus.org> Message-ID: <87ilevo7v7.fsf@smart-cactus.org> Ben Gamari writes: > Bryan Richter via ghc-devs writes: > >> I eventually resorted to a server reboot, which cleared up all the problems >> I was seeing. I think we're back in business. >> > The root partition was close to running out of disk space yesterday. The > problem appears to be that /nix is located on the small system drive. We > should really address this although moving /nix is sadly not easy and > will certainly require downtime. > In the meantime, I have significantly reduced the number of snapshots retained in the root dataset. This brought disk usage down from 70% to 12%, which should keep us afloat for a long while. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From ben at well-typed.com Mon Mar 20 15:32:06 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 20 Mar 2023 11:32:06 -0400 Subject: GitLab partial outage - attempting to mitigate In-Reply-To: References: <87lejro8rt.fsf@smart-cactus.org> Message-ID: <87fs9zo2wb.fsf@smart-cactus.org> Brandon Allbery writes: > Isn't it just "move /nix out of the way, bind mount a new one from a > larger drive, use rsync to move the data"? > Something like that, yes [1]. Cheers, - Ben [1] https://nixos.wiki/wiki/Storage_optimization#Moving_the_store -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From matthewtpickering at gmail.com Tue Mar 21 13:28:14 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 21 Mar 2023 13:28:14 +0000 Subject: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue In-Reply-To: References: Message-ID: Hi Martin, Thanks for your reports. I have approved your account on gitlab now. * The FreeBSD bindists are not officially created during the release process. The ones you are using from ghcup are created (and maintained) by the ghcup maintainers. * Most linux bindists are created using the old make build system on the 9.2.* series but it seems these bindists were not. * We will gladly fix the bugs you report with the hsc2hs wrapper. * Please open an issue for the problem with --target flag Cheers, Matt On Mon, Mar 20, 2023 at 2:05 AM Martin Baulig via ghc-devs wrote: > > Hello, > > I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. > > When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor > the GHC 9.2.7 binary packages from GHCUP work anymore. > > There are two issues - and I wrote a detailed article about my investigation on Medium: > https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 > > The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" > > > into > > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" > > > Otherwise, this will break when both ccArgs and ldFlags are non-empty: > > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" > > > Unfortunately, this is not quite it just yet. > > The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always > invoking hsc2hs with an explicit --cc= argument. > > Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no > "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. > > I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, > so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin > approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should > post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last > name in lowercase, baulig. > > Looking forward to hear back from you, > > Martin > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Tue Mar 21 17:16:10 2023 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Mar 2023 13:16:10 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: Message-ID: <877cvanhyy.fsf@smart-cactus.org> Laurent P. René de Cotret writes: > Dear GHC developers, > > In recent weeks, John Ericson has fine-tuned a Haskell Foundation > Technical Proposal to split `base` into two libraries: `ghc-base` and > `base`, the latter simply re-exporting everything for `ghc-base` (for > now). You can read about the rationale and specifics more in details > in the proposal itself: > https://github.com/haskellfoundation/tech-proposals/pull/47 > > Note that this proposal has recently been streamlined into a form > which is more focused than its initial state, and might be worth a > re-read. > > The Haskell Foundation Technical Working Group has reached a consensus > that this work will benefit the Haskell community. Moreover, the > Haskell Foundation has agreed to spend some of its resources to > implement this proposal, which would start by ensuring the completion > of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898). > > This work will affect GHC developers. Therefore, the Technical Working > Group would like to get buy-in from the GHC developers before formally > accepting this proposal. > Hi Laurent, In general I am quite supportive of this proposal. I have discussed the idea with John on several occassions and agree that separating the implementation of `base` from its user-facing interfaces with a package boundary would simplify life for both users and GHC's maintainers (c.f. [1]). I also threw together my own implementation of the idea in a few hours some weeks back (having forgotten about John's effort); this can be found in the wip/ghc-base branch [2]. From that experience I have no doubts that this idea is feasible. The only issues that I am slightly unsure of are: * whether/how to prevent `ghc-base` references from seeping into error messages. * which interfaces should be re-exposed from `base`. In [2] we propose that a fair number of interfaces be marked as GHC-internal. Those which are marked [3] as "hidden" should likely be exposed only via `ghc-base`. However, for compatibility reasons we may decide to continue exporting some subset of "internal" modules (with frozen export lists) from `base`. Regardless, I am very happy to see this split move forward and am grateful to John for his work in this direction. Cheers, - Ben [1] https://github.com/haskell/core-libraries-committee/issues/146 [2] https://gitlab.haskell.org/ghc/ghc/-/tree/wip/ghc-base [3] https://docs.google.com/spreadsheets/d/1WmyYLbJIMk9Q-vK4No5qvKIIdIZwhhFFlw6iVWd1xNQ/edit#gid=1315971213 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From carter.schonwald at gmail.com Tue Mar 21 21:55:45 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 21 Mar 2023 17:55:45 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <877cvanhyy.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> Message-ID: Would this include making those modules not hidden in ghc base? There’s been a few times where that status made it quite hard to build documentation for those modules! On Tue, Mar 21, 2023 at 1:16 PM Ben Gamari wrote: > Laurent P. René de Cotret writes: > > > Dear GHC developers, > > > > In recent weeks, John Ericson has fine-tuned a Haskell Foundation > > Technical Proposal to split `base` into two libraries: `ghc-base` and > > `base`, the latter simply re-exporting everything for `ghc-base` (for > > now). You can read about the rationale and specifics more in details > > in the proposal itself: > > https://github.com/haskellfoundation/tech-proposals/pull/47 > > > > Note that this proposal has recently been streamlined into a form > > which is more focused than its initial state, and might be worth a > > re-read. > > > > The Haskell Foundation Technical Working Group has reached a consensus > > that this work will benefit the Haskell community. Moreover, the > > Haskell Foundation has agreed to spend some of its resources to > > implement this proposal, which would start by ensuring the completion > > of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898). > > > > This work will affect GHC developers. Therefore, the Technical Working > > Group would like to get buy-in from the GHC developers before formally > > accepting this proposal. > > > Hi Laurent, > > In general I am quite supportive of this proposal. I have discussed the > idea with John on several occassions and agree that separating the > implementation of `base` from its user-facing interfaces with a package > boundary would simplify life for both users and GHC's maintainers (c.f. > [1]). > > I also threw together my own implementation of the idea in a few hours > some weeks back (having forgotten about John's effort); this can be > found in the wip/ghc-base branch [2]. From that experience I have no > doubts that this idea is feasible. The only issues that I am slightly > unsure of are: > > * whether/how to prevent `ghc-base` references from seeping into error > messages. > > * which interfaces should be re-exposed from `base`. In [2] we propose > that a fair number of interfaces be marked as GHC-internal. > Those which are marked [3] as "hidden" should likely be > exposed only via `ghc-base`. However, for compatibility reasons we > may decide to continue exporting some subset of "internal" modules > (with frozen export lists) from `base`. > > Regardless, I am very happy to see this split move forward and am > grateful to John for his work in this direction. > > Cheers, > > - Ben > > > > [1] https://github.com/haskell/core-libraries-committee/issues/146 > [2] https://gitlab.haskell.org/ghc/ghc/-/tree/wip/ghc-base > [3] > https://docs.google.com/spreadsheets/d/1WmyYLbJIMk9Q-vK4No5qvKIIdIZwhhFFlw6iVWd1xNQ/edit#gid=1315971213 > _______________________________________________ > 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 Wed Mar 22 00:21:19 2023 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Mar 2023 20:21:19 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> Message-ID: <874jqdocuv.fsf@smart-cactus.org> Carter Schonwald writes: > Would this include making those modules not hidden in ghc base? There’s > been a few times where that status made it quite hard to build > documentation for those modules! > What do you mean concretely? In most cases modules would remain exposed (that is, importable). However, I doubt there will be any change in their Haddock status (e.g. not-home or hidden). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From carter.schonwald at gmail.com Wed Mar 22 03:18:37 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 21 Mar 2023 23:18:37 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <874jqdocuv.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> Message-ID: i mean exactly the hidden status which means you cant directly go to the highlighted source. My recollection is that the only justification for that was as a mechanism for "foot cannons here," which itself predates the more modern *.Internal module norms we hew to today. On Tue, Mar 21, 2023 at 8:21 PM Ben Gamari wrote: > Carter Schonwald writes: > > > Would this include making those modules not hidden in ghc base? There’s > > been a few times where that status made it quite hard to build > > documentation for those modules! > > > What do you mean concretely? In most cases modules would remain exposed > (that is, importable). However, I doubt there will be any change in > their Haddock status (e.g. not-home or hidden). > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Mar 22 03:36:33 2023 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Mar 2023 23:36:33 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> Message-ID: <87wn39mp9k.fsf@smart-cactus.org> Carter Schonwald writes: > i mean exactly the hidden status which means you cant directly go to the > highlighted source. > > My recollection is that the only justification for that was as a mechanism > for "foot cannons here," which itself predates the more modern *.Internal > module norms we hew to today. > This is certainly something that we could consider once the split has been started but I do think we should wait until that point. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From david at haskell.foundation Wed Mar 22 08:37:31 2023 From: david at haskell.foundation (David Christiansen) Date: Wed, 22 Mar 2023 09:37:31 +0100 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> Message-ID: > > i mean exactly the hidden status which means you cant directly go to the > highlighted source. > Isn't this more of a limitation in the tool that generates the highlighted source? It seems to me to be more reasonable to make that tool show hidden modules' source, rather than to change the API of packages to accommodate the tool. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at haskell.foundation Wed Mar 22 08:38:18 2023 From: david at haskell.foundation (David Christiansen) Date: Wed, 22 Mar 2023 09:38:18 +0100 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <87wn39mp9k.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87wn39mp9k.fsf@smart-cactus.org> Message-ID: Hi all, In case it's useful, I made my best attempt to summarize the state of stakeholder discussion here: https://github.com/haskellfoundation/tech-proposals/pull/47#issuecomment-1479101114 All the best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at sandbergericsson.se Wed Mar 22 10:03:25 2023 From: adam at sandbergericsson.se (Adam Sandberg Eriksson) Date: Wed, 22 Mar 2023 10:03:25 +0000 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> Message-ID: I switched all the HADDOCK hide to not-home in base a couple of years ago, but I see a couple of new ones have snuck in in the meantime. I would suggest adding a lint against hiding in GHC CI. Adam On Wed, 22 Mar 2023, at 08:37, David Christiansen via ghc-devs wrote: >> i mean exactly the hidden status which means you cant directly go to the highlighted source. > > Isn't this more of a limitation in the tool that generates the highlighted source? It seems to me to be more reasonable to make that tool show hidden modules' source, rather than to change the API of packages to accommodate the tool. > > David > > _______________________________________________ > 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 Fri Mar 24 03:46:56 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 23 Mar 2023 23:46:56 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> Message-ID: <87lejmn750.fsf@smart-cactus.org> "Adam Sandberg Eriksson" writes: > I switched all the HADDOCK hide to not-home in base a couple of years > ago, but I see a couple of new ones have snuck in in the meantime. I > would suggest adding a lint against hiding in GHC CI. > Sounds reasonable to me. Perhaps someone could open a ticket to track this? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From lonetiger at gmail.com Fri Mar 24 07:48:27 2023 From: lonetiger at gmail.com (Phyx) Date: Fri, 24 Mar 2023 08:48:27 +0100 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <87lejmn750.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> Message-ID: Hi, Though I'm no longer a very active GHC developer I do have some questions. Overall I'm in support of this but I think I'd rather see an outright split from the start rather than first having a forwarder library. The reason for this is that I'm afraid of the performance impact of having this intermediate layer. For statically linked programs this means at least an additional load and branch on every call to a standard library. This would for instance affect Windows quite heavily. I'm not sure the impact is mitigated by branch prediction and prefetching. At the least it'll polute your L2 cache much more than before. For dynamically linked we could potentially use symbol preemption to remove the forwarding or on Windows redirect using import libraries. Now maybe I'm overestimating the impact this would have, but I'd very much like to see some numbers on a small-ish experiment to see what impact (if any) there are and what mitigation we can do. Typically it's quite hard to optimize after the fact. Maybe I've missed it in there. Proposal, but can the compiler remove the forwarding? i.e. Can the calls be specialized directly to the definition one? If so it'll break having alternative standard libs at runtime? Kind regards, Tamar On Fri, Mar 24, 2023, 04:47 Ben Gamari wrote: > "Adam Sandberg Eriksson" writes: > > > I switched all the HADDOCK hide to not-home in base a couple of years > > ago, but I see a couple of new ones have snuck in in the meantime. I > > would suggest adding a lint against hiding in GHC CI. > > > Sounds reasonable to me. > Perhaps someone could open a ticket to track this? > > _______________________________________________ > 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 carter.schonwald at gmail.com Fri Mar 24 19:03:41 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 24 Mar 2023 15:03:41 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> Message-ID: this is actually a good point! In my head, i was thinking some of the backpack module renaming and exporting machinery that cabal has would be applicable to side stepping the problem you're alluding to On Fri, Mar 24, 2023 at 3:48 AM Phyx wrote: > > Hi, > > Though I'm no longer a very active GHC developer I do have some questions. > > Overall I'm in support of this but I think I'd rather see an outright > split from the start rather than first having a forwarder library. > > The reason for this is that I'm afraid of the performance impact of having > this intermediate layer. > > For statically linked programs this means at least an additional load and > branch on every call to a standard library. This would for instance affect > Windows quite heavily. I'm not sure the impact is mitigated by branch > prediction and prefetching. At the least it'll polute your L2 cache much > more than before. > > For dynamically linked we could potentially use symbol preemption to > remove the forwarding or on Windows redirect using import libraries. > > Now maybe I'm overestimating the impact this would have, but I'd very much > like to see some numbers on a small-ish experiment to see what impact (if > any) there are and what mitigation we can do. > > Typically it's quite hard to optimize after the fact. Maybe I've missed it > in there. Proposal, but can the compiler remove the forwarding? i.e. Can > the calls be specialized directly to the definition one? If so it'll break > having alternative standard libs at runtime? > > Kind regards, > Tamar > > On Fri, Mar 24, 2023, 04:47 Ben Gamari wrote: > >> "Adam Sandberg Eriksson" writes: >> >> > I switched all the HADDOCK hide to not-home in base a couple of years >> > ago, but I see a couple of new ones have snuck in in the meantime. I >> > would suggest adding a lint against hiding in GHC CI. >> > >> Sounds reasonable to me. >> Perhaps someone could open a ticket to track this? >> >> _______________________________________________ >> 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 Fri Mar 24 21:17:58 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 24 Mar 2023 17:17:58 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> Message-ID: <87ilepn920.fsf@smart-cactus.org> Phyx writes: > Hi, > > Though I'm no longer a very active GHC developer I do have some questions. > > Overall I'm in support of this but I think I'd rather see an outright split > from the start rather than first having a forwarder library. > > The reason for this is that I'm afraid of the performance impact of having > this intermediate layer. > > For statically linked programs this means at least an additional load and > branch on every call to a standard library. This would for instance affect > Windows quite heavily. I'm not sure the impact is mitigated by branch > prediction and prefetching. At the least it'll polute your L2 cache much > more than before. > > For dynamically linked we could potentially use symbol preemption to remove > the forwarding or on Windows redirect using import libraries. > > Now maybe I'm overestimating the impact this would have, but I'd very much > like to see some numbers on a small-ish experiment to see what impact (if > any) there are and what mitigation we can do. > > Typically it's quite hard to optimize after the fact. Maybe I've missed it > in there. Proposal, but can the compiler remove the forwarding? i.e. Can > the calls be specialized directly to the definition one? If so it'll break > having alternative standard libs at runtime? > I highly doubt that this split will have any measurable overhead. Reexporting a definition defined in one module from another module via an export list does not produce any code at all; importing such a declaration is equivalent to importing the definition from the defining module. If for some reason we can't in some cases directly reexport then we would likely rather have a some very trivial bindings that GHC would be quite eager to inline. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From lonetiger at gmail.com Sat Mar 25 02:08:19 2023 From: lonetiger at gmail.com (Phyx) Date: Sat, 25 Mar 2023 02:08:19 +0000 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <87ilepn920.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> <87ilepn920.fsf@smart-cactus.org> Message-ID: > I highly doubt that this split will have any measurable overhead. > Reexporting a definition defined in one module from another module via > an export list does not produce any code at all; importing such a > declaration is equivalent to importing the definition from the defining > module. Ah right, I can see how that's true at the Haskell level but.. > If for some reason we can't in some cases directly reexport then we > would likely rather have a some very trivial bindings that GHC would be > quite eager to inline. Sure, I can see how you'd inline based on the haskell contract, I can't see how you avoid the compile time overhead when compiling the library. If you have a haskell library module Test (Control.Monad.when, Control.Applicative.many) where import Control.Monad(when) import Control.Applicative(many) compiling it: ghc test.hs [1 of 1] Compiling Test ( test.hs, test.o ) which still contains the closure for the library. On Windows where GHC forces the use of --*export*-*all*-symbols with dynamic-too this will not result in no code. in fact, it will result in exactly the *same* copy of code as in base inside the shared library: --export-all-symbols Treat all global and weak defined symbols found in the input object files as symbols to be exported. There is a small list of symbols which are not exported by default; see the --no-default-excludes option. You may add to the list of symbols to not export by using the --exclude-symbols option. At runtime you're right that you can avoid the extra calls (forgot about re-exportation through module definition) because the library becomes unused, but you don't avoid it at compile and link time in all cases. Yes, --*export*-*all*-symbols is horrible but that's how it works today because GHC does not support symbol visibility correctly. So unless there's a very good reason, I still think that it's better for *all* platforms to just move the code as opposed to re-export them, less we make it even harder still to support dynamic-too on Windows (though maybe that's ok and GHC should be fixed). Thanks, Tamar On Fri, Mar 24, 2023, 21:18 Ben Gamari wrote: > Phyx writes: > > > Hi, > > > > Though I'm no longer a very active GHC developer I do have some > questions. > > > > Overall I'm in support of this but I think I'd rather see an outright > split > > from the start rather than first having a forwarder library. > > > > The reason for this is that I'm afraid of the performance impact of > having > > this intermediate layer. > > > > For statically linked programs this means at least an additional load and > > branch on every call to a standard library. This would for instance > affect > > Windows quite heavily. I'm not sure the impact is mitigated by branch > > prediction and prefetching. At the least it'll polute your L2 cache much > > more than before. > > > > For dynamically linked we could potentially use symbol preemption to > remove > > the forwarding or on Windows redirect using import libraries. > > > > Now maybe I'm overestimating the impact this would have, but I'd very > much > > like to see some numbers on a small-ish experiment to see what impact (if > > any) there are and what mitigation we can do. > > > > Typically it's quite hard to optimize after the fact. Maybe I've missed > it > > in there. Proposal, but can the compiler remove the forwarding? i.e. Can > > the calls be specialized directly to the definition one? If so it'll > break > > having alternative standard libs at runtime? > > > I highly doubt that this split will have any measurable overhead. > Reexporting a definition defined in one module from another module via > an export list does not produce any code at all; importing such a > declaration is equivalent to importing the definition from the defining > module. > > If for some reason we can't in some cases directly reexport then we > would likely rather have a some very trivial bindings that GHC would be > quite eager to inline. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sat Mar 25 16:54:55 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 25 Mar 2023 12:54:55 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> <87ilepn920.fsf@smart-cactus.org> Message-ID: <87cz4wn54m.fsf@smart-cactus.org> Phyx writes: >> I highly doubt that this split will have any measurable overhead. >> Reexporting a definition defined in one module from another module via >> an export list does not produce any code at all; importing such a >> declaration is equivalent to importing the definition from the defining >> module. > > Ah right, I can see how that's true at the Haskell level but.. > >> If for some reason we can't in some cases directly reexport then we >> would likely rather have a some very trivial bindings that GHC would be >> quite eager to inline. > > Sure, I can see how you'd inline based on the haskell contract, I can't see > how you avoid the compile time overhead when compiling the library. If you > have a haskell library > > module Test (Control.Monad.when, Control.Applicative.many) where > > import Control.Monad(when) > import Control.Applicative(many) > > compiling it: > > ghc test.hs > [1 of 1] Compiling Test ( test.hs, test.o ) > > which still contains the closure for the library. I'm a bit lost. When I compile this module I get an object which contains no references to `when` or `many`. The only references to these two symbols should be in the interface file. What am I missing? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From ben at smart-cactus.org Sat Mar 25 16:58:32 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 25 Mar 2023 12:58:32 -0400 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> <87ilepn920.fsf@smart-cactus.org> Message-ID: <87a600n4yj.fsf@smart-cactus.org> Phyx writes: >> I highly doubt that this split will have any measurable overhead. >> Reexporting a definition defined in one module from another module via >> an export list does not produce any code at all; importing such a >> declaration is equivalent to importing the definition from the defining >> module. > > Ah right, I can see how that's true at the Haskell level but.. > >> If for some reason we can't in some cases directly reexport then we >> would likely rather have a some very trivial bindings that GHC would be >> quite eager to inline. > > Sure, I can see how you'd inline based on the haskell contract, I can't see > how you avoid the compile time overhead when compiling the library. If you > have a haskell library > > module Test (Control.Monad.when, Control.Applicative.many) where > > import Control.Monad(when) > import Control.Applicative(many) > > compiling it: > > ghc test.hs > [1 of 1] Compiling Test ( test.hs, test.o ) > To clarify, what is happening in this program is not inlining. Rather when you re-export `Control.Monad.when` from `Test` GHC merely records this fact in the interface file it produces for `Test`. No code is generated for `when` in `Test`. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 905 bytes Desc: not available URL: From lonetiger at gmail.com Sat Mar 25 17:29:59 2023 From: lonetiger at gmail.com (Phyx) Date: Sat, 25 Mar 2023 17:29:59 +0000 Subject: Buy-in for technical proposal 47 which affect GHC devs In-Reply-To: <87cz4wn54m.fsf@smart-cactus.org> References: <877cvanhyy.fsf@smart-cactus.org> <874jqdocuv.fsf@smart-cactus.org> <87lejmn750.fsf@smart-cactus.org> <87ilepn920.fsf@smart-cactus.org> <87cz4wn54m.fsf@smart-cactus.org> Message-ID: > What am I missing? Hi Ben, I'm talking about dynamic-too support, which I am still working on getting back in Windows. In the grand scheme of things it doesn't matter much, as it doesn't work today. But a forwarder library in that scenario still will have a compile time cost in the current scheme for how dynamic-too works on Windows. So I wanted to see if the implementation cost isn't high if we could do the library split now. But if it is then no problem, I'll find a work around. Thanks, Tamar On Sat, Mar 25, 2023, 16:54 Ben Gamari wrote: > Phyx writes: > > >> I highly doubt that this split will have any measurable overhead. > >> Reexporting a definition defined in one module from another module via > >> an export list does not produce any code at all; importing such a > >> declaration is equivalent to importing the definition from the defining > >> module. > > > > Ah right, I can see how that's true at the Haskell level but.. > > > >> If for some reason we can't in some cases directly reexport then we > >> would likely rather have a some very trivial bindings that GHC would be > >> quite eager to inline. > > > > Sure, I can see how you'd inline based on the haskell contract, I can't > see > > how you avoid the compile time overhead when compiling the library. If > you > > have a haskell library > > > > > module Test (Control.Monad.when, Control.Applicative.many) where > > > > import Control.Monad(when) > > import Control.Applicative(many) > > > > compiling it: > > > > ghc test.hs > > [1 of 1] Compiling Test ( test.hs, test.o ) > > > > which still contains the closure for the library. > > I'm a bit lost. When I compile this module I get an object which > contains no references to `when` or `many`. The only references to these > two symbols should be in the interface file. What am I missing? > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sat Mar 25 22:49:09 2023 From: djsamperi at gmail.com (Dominick Samperi) Date: Sat, 25 Mar 2023 18:49:09 -0400 Subject: Windows/R issue with FFI Message-ID: Hello, FFI code that used to work now fails under Windows (still seems to work under Ubuntu), and I wonder if anybody has seen anything like this and can provide some pointers... The code uses FFI to fetch information from the R side like R_NilValue, using something like this; -- Fetch R's R_NilValue... foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP r_NilValue :: IO R_EXP r_NilValue = peek r_NilValue_ptr rNilValue1 :: IO REXP rNilValue1 = do x <- r_NilValue traceShow("addr=",x) extREXP x Under Windows the address displayed is obviously bad, and this causes the app to crash. This does not happen under Linux (Ubuntu). Now, replace the line containing peek with r_NilValue = trace "PEEK" peek r_NilValue_ptr The address is now valid! It seems that adding the trace "PEEK" adds some delay and somehow resolves the problem. This problem is intermittent, so it is hard to come up with a simple example that fails every time. A little background: R_NilValue is a pointer to a SEXP that is not initialized until an embedded instance of R is initialized, and the code above is not triggered until this happens. Perhaps there is a race condition between the time R initializes itself and Haskell performs the peek? I don't think R_NilValue is garbage collected once initialized. Any tips would be appreciated. Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Sun Mar 26 03:18:13 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 25 Mar 2023 23:18:13 -0400 Subject: Windows/R issue with FFI In-Reply-To: References: Message-ID: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> This sounds like a bug. Could you open a ticket, ideally with a fairly standalone reproducer? Cheer, - Ben On March 25, 2023 6:49:09 PM EDT, Dominick Samperi wrote: >Hello, >FFI code that used to work now fails under Windows (still seems to work >under Ubuntu), and I wonder if anybody has seen anything like this and >can provide some pointers... > >The code uses FFI to fetch information from the R side like R_NilValue, >using something like this; > >-- Fetch R's R_NilValue... >foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >r_NilValue :: IO R_EXP >r_NilValue = peek r_NilValue_ptr >rNilValue1 :: IO REXP >rNilValue1 = do > x <- r_NilValue > traceShow("addr=",x) extREXP x > >Under Windows the address displayed is obviously bad, and this causes >the app to crash. This does not happen under Linux (Ubuntu). > >Now, replace the line containing peek with > >r_NilValue = trace "PEEK" peek r_NilValue_ptr > >The address is now valid! It seems that adding the trace "PEEK" adds >some delay and somehow resolves the problem. > >This problem is intermittent, so it is hard to come up with a >simple example that fails every time. > >A little background: R_NilValue is a pointer to a SEXP that is not >initialized until an embedded instance of R is initialized, and the >code above is not triggered until this happens. Perhaps there is >a race condition between the time R initializes itself and Haskell >performs the peek? I don't think R_NilValue is garbage collected >once initialized. > >Any tips would be appreciated. >Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: From djsamperi at gmail.com Sun Mar 26 13:16:11 2023 From: djsamperi at gmail.com (Dominick Samperi) Date: Sun, 26 Mar 2023 09:16:11 -0400 Subject: Windows/R issue with FFI In-Reply-To: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> References: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> Message-ID: Thanks Ben, I'll see what I can do to reliably reproduce and open a ticket. One theory I'm investigating is that this might have something to do with my anti-virus software (AVG), since it sometimes interacts with Windows in strange ways (for example, an extra instance of a terminal app pops up, then disappears after a few seconds). But disabling this software does not seem to solve the problem. On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari wrote: > This sounds like a bug. Could you open a ticket, ideally with a fairly > standalone reproducer? > > Cheer, > > - Ben > > On March 25, 2023 6:49:09 PM EDT, Dominick Samperi > wrote: >> >> Hello, >> FFI code that used to work now fails under Windows (still seems to work >> under Ubuntu), and I wonder if anybody has seen anything like this and >> can provide some pointers... >> >> The code uses FFI to fetch information from the R side like R_NilValue, >> using something like this; >> >> -- Fetch R's R_NilValue... >> foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >> r_NilValue :: IO R_EXP >> r_NilValue = peek r_NilValue_ptr >> rNilValue1 :: IO REXP >> rNilValue1 = do >> x <- r_NilValue >> traceShow("addr=",x) extREXP x >> >> Under Windows the address displayed is obviously bad, and this causes >> the app to crash. This does not happen under Linux (Ubuntu). >> >> Now, replace the line containing peek with >> >> r_NilValue = trace "PEEK" peek r_NilValue_ptr >> >> The address is now valid! It seems that adding the trace "PEEK" adds >> some delay and somehow resolves the problem. >> >> This problem is intermittent, so it is hard to come up with a >> simple example that fails every time. >> >> A little background: R_NilValue is a pointer to a SEXP that is not >> initialized until an embedded instance of R is initialized, and the >> code above is not triggered until this happens. Perhaps there is >> a race condition between the time R initializes itself and Haskell >> performs the peek? I don't think R_NilValue is garbage collected >> once initialized. >> >> Any tips would be appreciated. >> Dominick >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Mar 27 13:48:34 2023 From: lonetiger at gmail.com (Phyx) Date: Mon, 27 Mar 2023 14:48:34 +0100 Subject: Windows/R issue with FFI In-Reply-To: References: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> Message-ID: Hi, I'm missing some details here here as I'm having trouble following the flow. What provides the symbol for that import? As in where does R_NilValue come from? As in, how is it defined. Are you linking against a library or C sources? When you say you replace the trace statement, do you keep the x <- r_NilValue? The address to R_NilValue should never change during initialization so I'm more suspicious of how it's declared. Unless you're linking to a symbol in a shared library, in which case that could be possible due to ASLR. Kind regards, Tamar Sent from my Mobile On Sun, Mar 26, 2023, 14:15 Dominick Samperi wrote: > Thanks Ben, I'll see what I can do to reliably reproduce and open a ticket. > > One theory I'm investigating is that this might have something to do > with my anti-virus software (AVG), since it sometimes interacts with > Windows in strange ways (for example, an extra instance of a terminal app > pops up, then disappears after a few seconds). But disabling this software > does not seem to solve the problem. > > On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari wrote: > >> This sounds like a bug. Could you open a ticket, ideally with a fairly >> standalone reproducer? >> >> Cheer, >> >> - Ben >> >> On March 25, 2023 6:49:09 PM EDT, Dominick Samperi >> wrote: >>> >>> Hello, >>> FFI code that used to work now fails under Windows (still seems to work >>> under Ubuntu), and I wonder if anybody has seen anything like this and >>> can provide some pointers... >>> >>> The code uses FFI to fetch information from the R side like R_NilValue, >>> using something like this; >>> >>> -- Fetch R's R_NilValue... >>> foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >>> r_NilValue :: IO R_EXP >>> r_NilValue = peek r_NilValue_ptr >>> rNilValue1 :: IO REXP >>> rNilValue1 = do >>> x <- r_NilValue >>> traceShow("addr=",x) extREXP x >>> >>> Under Windows the address displayed is obviously bad, and this causes >>> the app to crash. This does not happen under Linux (Ubuntu). >>> >>> Now, replace the line containing peek with >>> >>> r_NilValue = trace "PEEK" peek r_NilValue_ptr >>> >>> The address is now valid! It seems that adding the trace "PEEK" adds >>> some delay and somehow resolves the problem. >>> >>> This problem is intermittent, so it is hard to come up with a >>> simple example that fails every time. >>> >>> A little background: R_NilValue is a pointer to a SEXP that is not >>> initialized until an embedded instance of R is initialized, and the >>> code above is not triggered until this happens. Perhaps there is >>> a race condition between the time R initializes itself and Haskell >>> performs the peek? I don't think R_NilValue is garbage collected >>> once initialized. >>> >>> Any tips would be appreciated. >>> Dominick >>> >>> >>> >>> >>> >>> _______________________________________________ > 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 djsamperi at gmail.com Mon Mar 27 14:17:51 2023 From: djsamperi at gmail.com (Dominick Samperi) Date: Mon, 27 Mar 2023 10:17:51 -0400 Subject: Windows/R issue with FFI In-Reply-To: References: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> Message-ID: Yes, everything else stays the same, including x <- r_NilValue. I opened a ticket here where more details are provided https://gitlab.haskell.org/ghc/ghc/-/issues/23183 After initializing an R instance, if you fetch R_NilValue and peek at its value (using FFI peek) you get a bad address. But if you add a trace statement before the peek the address is valid. A "race condition" should not be possible in a single-threaded application, so I am not sure what is going on. I tried to come up with a simple reproducible example where a library module does nothing but fetch R_NilValue, and the client also uses FFI to fetch R_NilValue, but in this example both addresses are valid and equal. Virus-free.www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 27, 2023 at 9:48 AM Phyx wrote: > Hi, > > I'm missing some details here here as I'm having trouble following the > flow. > > What provides the symbol for that import? As in where does R_NilValue come > from? As in, how is it defined. Are you linking against a library or C > sources? > > When you say you replace the trace statement, do you keep the x <- > r_NilValue? > > The address to R_NilValue should never change during initialization so I'm > more suspicious of how it's declared. Unless you're linking to a symbol in > a shared library, in which case that could be possible due to ASLR. > > Kind regards, > Tamar > > Sent from my Mobile > > On Sun, Mar 26, 2023, 14:15 Dominick Samperi wrote: > >> Thanks Ben, I'll see what I can do to reliably reproduce and open a >> ticket. >> >> One theory I'm investigating is that this might have something to do >> with my anti-virus software (AVG), since it sometimes interacts with >> Windows in strange ways (for example, an extra instance of a terminal app >> pops up, then disappears after a few seconds). But disabling this software >> does not seem to solve the problem. >> >> On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari wrote: >> >>> This sounds like a bug. Could you open a ticket, ideally with a fairly >>> standalone reproducer? >>> >>> Cheer, >>> >>> - Ben >>> >>> On March 25, 2023 6:49:09 PM EDT, Dominick Samperi >>> wrote: >>>> >>>> Hello, >>>> FFI code that used to work now fails under Windows (still seems to work >>>> under Ubuntu), and I wonder if anybody has seen anything like this and >>>> can provide some pointers... >>>> >>>> The code uses FFI to fetch information from the R side like R_NilValue, >>>> using something like this; >>>> >>>> -- Fetch R's R_NilValue... >>>> foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >>>> r_NilValue :: IO R_EXP >>>> r_NilValue = peek r_NilValue_ptr >>>> rNilValue1 :: IO REXP >>>> rNilValue1 = do >>>> x <- r_NilValue >>>> traceShow("addr=",x) extREXP x >>>> >>>> Under Windows the address displayed is obviously bad, and this causes >>>> the app to crash. This does not happen under Linux (Ubuntu). >>>> >>>> Now, replace the line containing peek with >>>> >>>> r_NilValue = trace "PEEK" peek r_NilValue_ptr >>>> >>>> The address is now valid! It seems that adding the trace "PEEK" adds >>>> some delay and somehow resolves the problem. >>>> >>>> This problem is intermittent, so it is hard to come up with a >>>> simple example that fails every time. >>>> >>>> A little background: R_NilValue is a pointer to a SEXP that is not >>>> initialized until an embedded instance of R is initialized, and the >>>> code above is not triggered until this happens. Perhaps there is >>>> a race condition between the time R initializes itself and Haskell >>>> performs the peek? I don't think R_NilValue is garbage collected >>>> once initialized. >>>> >>>> Any tips would be appreciated. >>>> Dominick >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >> 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 lonetiger at gmail.com Mon Mar 27 14:55:39 2023 From: lonetiger at gmail.com (Phyx) Date: Mon, 27 Mar 2023 15:55:39 +0100 Subject: Windows/R issue with FFI In-Reply-To: References: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> Message-ID: Thanks, that does indeed look dynamically linked. Could you also paste on the ticket the contents of hR.buildinfo? Cheers, Tamar Sent from my Mobile On Mon, Mar 27, 2023, 15:18 Dominick Samperi wrote: > Yes, everything else stays the same, including x <- r_NilValue. > > I opened a ticket here where more details are provided > https://gitlab.haskell.org/ghc/ghc/-/issues/23183 > > After initializing an R instance, if you fetch R_NilValue and > peek at its value (using FFI peek) you get a bad address. But if > you add a trace statement before the peek the address is valid. > > A "race condition" should not be possible in a single-threaded > application, so I am not sure what is going on. I tried to come > up with a simple reproducible example where a library module does > nothing but fetch R_NilValue, and the client also uses FFI to fetch > R_NilValue, but in this example both addresses are valid and equal. > > > > > > Virus-free.www.avg.com > > <#m_7940054291392109769_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Mon, Mar 27, 2023 at 9:48 AM Phyx wrote: > >> Hi, >> >> I'm missing some details here here as I'm having trouble following the >> flow. >> >> What provides the symbol for that import? As in where does R_NilValue >> come from? As in, how is it defined. Are you linking against a library or C >> sources? >> >> When you say you replace the trace statement, do you keep the x <- >> r_NilValue? >> >> The address to R_NilValue should never change during initialization so >> I'm more suspicious of how it's declared. Unless you're linking to a symbol >> in a shared library, in which case that could be possible due to ASLR. >> >> Kind regards, >> Tamar >> >> Sent from my Mobile >> >> On Sun, Mar 26, 2023, 14:15 Dominick Samperi wrote: >> >>> Thanks Ben, I'll see what I can do to reliably reproduce and open a >>> ticket. >>> >>> One theory I'm investigating is that this might have something to do >>> with my anti-virus software (AVG), since it sometimes interacts with >>> Windows in strange ways (for example, an extra instance of a terminal >>> app pops up, then disappears after a few seconds). But disabling this >>> software does not seem to solve the problem. >>> >>> On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari >>> wrote: >>> >>>> This sounds like a bug. Could you open a ticket, ideally with a fairly >>>> standalone reproducer? >>>> >>>> Cheer, >>>> >>>> - Ben >>>> >>>> On March 25, 2023 6:49:09 PM EDT, Dominick Samperi >>>> wrote: >>>>> >>>>> Hello, >>>>> FFI code that used to work now fails under Windows (still seems to work >>>>> under Ubuntu), and I wonder if anybody has seen anything like this and >>>>> can provide some pointers... >>>>> >>>>> The code uses FFI to fetch information from the R side like R_NilValue, >>>>> using something like this; >>>>> >>>>> -- Fetch R's R_NilValue... >>>>> foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >>>>> r_NilValue :: IO R_EXP >>>>> r_NilValue = peek r_NilValue_ptr >>>>> rNilValue1 :: IO REXP >>>>> rNilValue1 = do >>>>> x <- r_NilValue >>>>> traceShow("addr=",x) extREXP x >>>>> >>>>> Under Windows the address displayed is obviously bad, and this causes >>>>> the app to crash. This does not happen under Linux (Ubuntu). >>>>> >>>>> Now, replace the line containing peek with >>>>> >>>>> r_NilValue = trace "PEEK" peek r_NilValue_ptr >>>>> >>>>> The address is now valid! It seems that adding the trace "PEEK" adds >>>>> some delay and somehow resolves the problem. >>>>> >>>>> This problem is intermittent, so it is hard to come up with a >>>>> simple example that fails every time. >>>>> >>>>> A little background: R_NilValue is a pointer to a SEXP that is not >>>>> initialized until an embedded instance of R is initialized, and the >>>>> code above is not triggered until this happens. Perhaps there is >>>>> a race condition between the time R initializes itself and Haskell >>>>> performs the peek? I don't think R_NilValue is garbage collected >>>>> once initialized. >>>>> >>>>> Any tips would be appreciated. >>>>> Dominick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>> 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 adam at well-typed.com Mon Mar 27 19:18:53 2023 From: adam at well-typed.com (Adam Gundry) Date: Mon, 27 Mar 2023 20:18:53 +0100 Subject: Understanding how warnings on unused functions work In-Reply-To: References: Message-ID: <23008550-9e2a-c734-78c1-e9b0bf53cddb@well-typed.com> Hi, I think the function you are looking for is reportUnusedNames in GHC.Rename.Names [1], which calls findUses [2]. You may find the Note [Tracking unused binding and imports] in GHC.Tc.Types [3] helpful. Roughly, GHC's renamer traverses the syntax tree to resolve names and along the way collects sets of defined/used names in tcg_dus. There are also a set of names used by the typechecker in tcg_keep. After typechecking, findUses takes the transitive closure of the set of uses and reportUnusedNames then issues unused-top-binds warnings for all names defined in the current module that are not in the set. Hope this helps, Adam [1] https://gitlab.haskell.org/ghc/ghc/-/blob/e1fb56b24e2fe45a6f628f651bfc12b2b9743378/compiler/GHC/Rename/Names.hs#L1579 [2] https://gitlab.haskell.org/ghc/ghc/-/blob/e1fb56b24e2fe45a6f628f651bfc12b2b9743378/compiler/GHC/Types/Name/Set.hs#L203 [3] https://gitlab.haskell.org/ghc/ghc/-/blob/e1fb56b24e2fe45a6f628f651bfc12b2b9743378/compiler/GHC/Tc/Types.hs#L710 On 14/03/2023 17:13, Razetime wrote: > This message is related to a feature in the futhark compiler > , which is a language > with a similar module system. > > I am trying to create a tool to detect unused top-level functions in > Futhark, and I have been looking in the ghc codebase to find out how it > does so. So far I have found these areas: > > 1. warning flag > > 2. WarnUnusedTopBinds > > > The project is a bit too big for my machine to take, so HLS is not > helping me with finding where the computation of unused bindings > (specifically functions) is done. > I would like some help with finding where ghc does this computation, and > maybe some help with the naming conventions of the code. > > Thanks in advance. -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From matthewtpickering at gmail.com Thu Mar 30 08:26:13 2023 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 30 Mar 2023 09:26:13 +0100 Subject: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue In-Reply-To: References: Message-ID: The HSC2HS_EXTRA option was fixed in ``` commit 99623358754d812b8b4bdfcdc57190d38617b9cc Author: Matthew Pickering Date: Thu Mar 10 20:48:44 2022 +0000 hadrian: Correct generation of hsc2hs wrapper If you inspect the inside of a wrapper script for hsc2hs you will see that the cflag and lflag values are concatenated incorrectly. ``` HSC2HS_EXTRA="--cflag=-U__i686--lflag=-fuse-ld=gold" ``` It should instead be ``` HSC2HS_EXTRA="--cflag=-U__i686 --lflag=-fuse-ld=gold" ``` Fixes #21221 ``` On Tue, Mar 21, 2023 at 1:28 PM Matthew Pickering wrote: > > Hi Martin, > > Thanks for your reports. > > I have approved your account on gitlab now. > > * The FreeBSD bindists are not officially created during the release > process. The ones you are using from ghcup are created (and > maintained) by the ghcup maintainers. > * Most linux bindists are created using the old make build system on > the 9.2.* series but it seems these bindists were not. > * We will gladly fix the bugs you report with the hsc2hs wrapper. > * Please open an issue for the problem with --target flag > > Cheers, > > Matt > > On Mon, Mar 20, 2023 at 2:05 AM Martin Baulig via ghc-devs > wrote: > > > > Hello, > > > > I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. > > > > When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor > > the GHC 9.2.7 binary packages from GHCUP work anymore. > > > > There are two issues - and I wrote a detailed article about my investigation on Medium: > > https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 > > > > The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > > > > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" > > > > > > into > > > > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" > > > > > > Otherwise, this will break when both ccArgs and ldFlags are non-empty: > > > > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" > > > > > > Unfortunately, this is not quite it just yet. > > > > The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always > > invoking hsc2hs with an explicit --cc= argument. > > > > Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no > > "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. > > > > I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, > > so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin > > approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should > > post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last > > name in lowercase, baulig. > > > > Looking forward to hear back from you, > > > > Martin > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From djsamperi at gmail.com Thu Mar 30 12:14:56 2023 From: djsamperi at gmail.com (Dominick Samperi) Date: Thu, 30 Mar 2023 08:14:56 -0400 Subject: Windows/R issue with FFI In-Reply-To: References: <313B213F-AE84-41F6-8855-C36332D1116F@smart-cactus.org> Message-ID: I closed the previous ticket and opened another with a simple reproducer attached. It consists of just two source files, and shows that when a trivial library is installed by stack and compiled using ghc, there are problems, but if everything is compiled using ghci there are no problems. https://gitlab.haskell.org/ghc/ghc/-/issues/23194 Virus-free.www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Mon, Mar 27, 2023 at 10:55 AM Phyx wrote: > Thanks, that does indeed look dynamically linked. > > Could you also paste on the ticket the contents of hR.buildinfo? > > Cheers, > Tamar > > Sent from my Mobile > > On Mon, Mar 27, 2023, 15:18 Dominick Samperi wrote: > >> Yes, everything else stays the same, including x <- r_NilValue. >> >> I opened a ticket here where more details are provided >> https://gitlab.haskell.org/ghc/ghc/-/issues/23183 >> >> After initializing an R instance, if you fetch R_NilValue and >> peek at its value (using FFI peek) you get a bad address. But if >> you add a trace statement before the peek the address is valid. >> >> A "race condition" should not be possible in a single-threaded >> application, so I am not sure what is going on. I tried to come >> up with a simple reproducible example where a library module does >> nothing but fetch R_NilValue, and the client also uses FFI to fetch >> R_NilValue, but in this example both addresses are valid and equal. >> >> >> >> >> >> Virus-free.www.avg.com >> >> <#m_375268917039218120_m_7940054291392109769_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> On Mon, Mar 27, 2023 at 9:48 AM Phyx wrote: >> >>> Hi, >>> >>> I'm missing some details here here as I'm having trouble following the >>> flow. >>> >>> What provides the symbol for that import? As in where does R_NilValue >>> come from? As in, how is it defined. Are you linking against a library or C >>> sources? >>> >>> When you say you replace the trace statement, do you keep the x <- >>> r_NilValue? >>> >>> The address to R_NilValue should never change during initialization so >>> I'm more suspicious of how it's declared. Unless you're linking to a symbol >>> in a shared library, in which case that could be possible due to ASLR. >>> >>> Kind regards, >>> Tamar >>> >>> Sent from my Mobile >>> >>> On Sun, Mar 26, 2023, 14:15 Dominick Samperi >>> wrote: >>> >>>> Thanks Ben, I'll see what I can do to reliably reproduce and open a >>>> ticket. >>>> >>>> One theory I'm investigating is that this might have something to do >>>> with my anti-virus software (AVG), since it sometimes interacts with >>>> Windows in strange ways (for example, an extra instance of a terminal >>>> app pops up, then disappears after a few seconds). But disabling this >>>> software does not seem to solve the problem. >>>> >>>> On Sat, Mar 25, 2023 at 11:18 PM Ben Gamari >>>> wrote: >>>> >>>>> This sounds like a bug. Could you open a ticket, ideally with a fairly >>>>> standalone reproducer? >>>>> >>>>> Cheer, >>>>> >>>>> - Ben >>>>> >>>>> On March 25, 2023 6:49:09 PM EDT, Dominick Samperi < >>>>> djsamperi at gmail.com> wrote: >>>>>> >>>>>> Hello, >>>>>> FFI code that used to work now fails under Windows (still seems to >>>>>> work >>>>>> under Ubuntu), and I wonder if anybody has seen anything like this and >>>>>> can provide some pointers... >>>>>> >>>>>> The code uses FFI to fetch information from the R side like >>>>>> R_NilValue, >>>>>> using something like this; >>>>>> >>>>>> -- Fetch R's R_NilValue... >>>>>> foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP >>>>>> r_NilValue :: IO R_EXP >>>>>> r_NilValue = peek r_NilValue_ptr >>>>>> rNilValue1 :: IO REXP >>>>>> rNilValue1 = do >>>>>> x <- r_NilValue >>>>>> traceShow("addr=",x) extREXP x >>>>>> >>>>>> Under Windows the address displayed is obviously bad, and this causes >>>>>> the app to crash. This does not happen under Linux (Ubuntu). >>>>>> >>>>>> Now, replace the line containing peek with >>>>>> >>>>>> r_NilValue = trace "PEEK" peek r_NilValue_ptr >>>>>> >>>>>> The address is now valid! It seems that adding the trace "PEEK" adds >>>>>> some delay and somehow resolves the problem. >>>>>> >>>>>> This problem is intermittent, so it is hard to come up with a >>>>>> simple example that fails every time. >>>>>> >>>>>> A little background: R_NilValue is a pointer to a SEXP that is not >>>>>> initialized until an embedded instance of R is initialized, and the >>>>>> code above is not triggered until this happens. Perhaps there is >>>>>> a race condition between the time R initializes itself and Haskell >>>>>> performs the peek? I don't think R_NilValue is garbage collected >>>>>> once initialized. >>>>>> >>>>>> Any tips would be appreciated. >>>>>> Dominick >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>> 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 baulig at protonmail.com Thu Mar 30 23:22:03 2023 From: baulig at protonmail.com (Martin Baulig) Date: Thu, 30 Mar 2023 23:22:03 +0000 Subject: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue In-Reply-To: References: Message-ID: Hey Matthew, Thank you so very much for fixing this and my apologies for not following up on the issue. I was planning to file an issue with a PR, but got distracted with other things. My new AMD Radeon RX 6700 XT had arrived in the mail and while it's working fine with OpenBSD, I had to upgade the FreeBSD to 14-CURRENT to get it working there as well. Since I didn't feel good about filing any issue while using an unsupported developer preview version of the operating system, I had planned to install FreeBSD 13.1 in some AWS instance for testing, but then got too busy with OpenBSD. GHC 9.2.7 works great on OpenBSD - I just had two minor issues to get it to compile, I'll file an issue and a PR for that shortly. Best wishes, Martin ------- Original Message ------- On Thursday, March 30th, 2023 at 8:26 AM, Matthew Pickering wrote: > > > The HSC2HS_EXTRA option was fixed in > > ``` > commit 99623358754d812b8b4bdfcdc57190d38617b9cc > Author: Matthew Pickering matthewtpickering at gmail.com > > Date: Thu Mar 10 20:48:44 2022 +0000 > > hadrian: Correct generation of hsc2hs wrapper > > If you inspect the inside of a wrapper script for hsc2hs you will see > that the cflag and lflag values are concatenated incorrectly. > > `HSC2HS_EXTRA="--cflag=-U__i686--lflag=-fuse-ld=gold"` > > It should instead be > > `HSC2HS_EXTRA="--cflag=-U__i686 --lflag=-fuse-ld=gold"` > > Fixes #21221 > ``` > > On Tue, Mar 21, 2023 at 1:28 PM Matthew Pickering > matthewtpickering at gmail.com wrote: > > > Hi Martin, > > > > Thanks for your reports. > > > > I have approved your account on gitlab now. > > > > * The FreeBSD bindists are not officially created during the release > > process. The ones you are using from ghcup are created (and > > maintained) by the ghcup maintainers. > > * Most linux bindists are created using the old make build system on > > the 9.2.* series but it seems these bindists were not. > > * We will gladly fix the bugs you report with the hsc2hs wrapper. > > * Please open an issue for the problem with --target flag > > > > Cheers, > > > > Matt > > > > On Mon, Mar 20, 2023 at 2:05 AM Martin Baulig via ghc-devs > > ghc-devs at haskell.org wrote: > > > > > Hello, > > > > > > I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. > > > > > > When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor > > > the GHC 9.2.7 binary packages from GHCUP work anymore. > > > > > > There are two issues - and I wrote a detailed article about my investigation on Medium: > > > https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 > > > > > > The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > > > > > > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" > > > > > > into > > > > > > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" > > > > > > Otherwise, this will break when both ccArgs and ldFlags are non-empty: > > > > > > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" > > > > > > Unfortunately, this is not quite it just yet. > > > > > > The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always > > > invoking hsc2hs with an explicit --cc= argument. > > > > > > Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no > > > "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. > > > > > > I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, > > > so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin > > > approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should > > > post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last > > > name in lowercase, baulig. > > > > > > Looking forward to hear back from you, > > > > > > Martin > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs