Re: Buy-in for technical proposal 47 which affect GHC devs
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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Buy-in for technical proposal 47 which affect GHC devs
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 > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Buy-in for technical proposal 47 which affect GHC devs
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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Buy-in for technical proposal 47 which affect GHC devs
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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Buy-in for technical proposal 47 which affect GHC devs
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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue
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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
