From bryan at haskell.foundation Thu Nov 2 14:20:05 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 2 Nov 2023 16:20:05 +0200 Subject: Docs for RTS option -I Message-ID: The original docs are here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 They raised more questions than answers for me, so I took a stab at rewriting them, and sprinkled in some questions where I need better understanding. Anyone care to fill in my blanks? ----------------- Set the amount of idle time which must pass before an idle GC is performed. Setting -I0 disables the idle GC. The idle GC only affects the threaded and SMP versions of the RTS (see -threaded, Options affecting linking). When the idle GC is enabled, a major GC is automatically performed if the runtime has been idle (i.e., no Haskell computation has been running) for the specified period of time. For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. [Why is this a good thing? What happens when the idle GC is disabled?] Also, it will mean that a GC is less likely to happen when the application is busy, so application responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant penalty to responsiveness. [Why? Is it because the idle GC was delayed by waiting for some idle time, and thus has more work to do?]. Conversely, too small of an interval could adversely affect interactive responsiveness [How? And how is this worse than having idle GC disabled? What is the actual behavior when it's disabled, anyway?] The idle period timer only resets after some activity by a Haskell thread. Therefore, once an idle GC is triggered, another one won't be scheduled until more work is performed. This is an experimental feature. Please let us know if it causes problems and/or could benefit from further tuning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From teofilcamarasu at gmail.com Thu Nov 2 15:17:23 2023 From: teofilcamarasu at gmail.com (Teofil Camarasu) Date: Thu, 2 Nov 2023 15:17:23 +0000 Subject: Docs for RTS option -I In-Reply-To: References: Message-ID: Hi Bryan, Thanks for improving this documentation! I've often found these flags to be quite confusing. > For an interactive application, it is probably a good idea to use the idle GC, because this will allow finalizers to run and deadlocked threads to be detected in the idle time when no Haskell computation is happening. [Why is this a good thing? What happens when the idle GC is disabled?] So there's basically 3 ways to trigger a major GC as far as I know: 1. Heap overflow: when we last performed a major GC we checked how much live data there is and set a variable so that we do another major GC when the heap grows to be live * F. 2. Idle GC 3. Manually triggering a GC using the interface in System.Mem When idle gc is disabled, then GC will happen less often. One of the other two may still trigger a GC. A key difference is both of those are only activated by the mutator running code: either through allocation or by calling a GC directly. On the other hand, idle GC can be triggered when the mutator isn't running. So, if you want to ensure that finalizers get called promptly then idle GC can help, especially if your application is idle for long periods of time. The other key benefit of the idle GC is that it can reduce the prevalence of heap overflow GCs. These can only happen when your application is allocating and hence running code. So it's quite likely that it's going to tank the response time for the request your application is serving at the time. And since idle GCs free some memory, it makes it less likely that you reach the limit that would trigger a heap overflow GC. With idle GCs, if you are lucky, major GCs will only run while your application isn't meant to be responding to requests at all, which makes it basically free. > Also, it will mean that a GC is less likely to happen when the application is busy, so application responsiveness may be improved. However, if the amount of live data in the heap is particularly large, then the idle GC can cause a significant penalty to responsiveness. [Why? Is it because the idle GC was delayed by waiting for some idle time, and thus has more work to do?]. The reason this can happen is because the time a major GC takes is proportional to the live data in the heap. So, if the pause required by the GC starts to overlap with time when you'd like the application to be working on a response, then you will regress response times. For instance if it takes 100ms to run an idle GC and a request comes in just after you've started the GC then processing it will have to wait until the GC is over. >Conversely, too small of an interval could adversely affect interactive responsiveness [How? And how is this worse than having idle GC disabled? What is the actual behavior when it's disabled, anyway?] The smaller the interval, the more time you are spending running an idle GC, the more likely it becomes that it will overlap with time you want to be doing something else. This is similar to the long GC case above due to large heaps. Another reason you might not want to run it too often is that you are unlikely to free much memory. I think this documentation was written before the non-moving GC was added. It would also be important to add that the savings in terms of responsiveness don't really apply if that is enabled as the non-moving GC runs concurrently with the mutator anyway. So, the main advantage would just be more prompt finalization, deadlock detection, etc. I hope that helps; let me know if you'd like anything clarified. Cheers, Teo From bryan at haskell.foundation Fri Nov 3 11:24:29 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 3 Nov 2023 13:24:29 +0200 Subject: Report on my little ticket triage exercise Message-ID: Hello, Over the past few months, I have looked at tickets labeled "Priority: highest" to get a feel for things. I looked at the three stalest once a fortnight using this link.  https://gitlab.haskell.org/ghc/ghc/-/issues/?sort=updated_asc&state=opened&label_name%5B%5D=P%3A%3Ahighest&first_page_size=3 I managed to find some that could be closed, some that could be deprioritized, and some that had fallen through the cracks. Overall it felt really nice. Now I've started seeing the same issues, meaning I've worked my way through the entire list. So I think all of the remainders are current and valid. Having done that, I decided I'd try looking at "Priority: high" tickets. Unfortunately the same triage strategy won't work. While "highest" says to me, "Hey, we need to fix this!", it's not clear what "high" means. I think a mature project like GHC may very well have many tickets that are important, but not important enough to halt other work. That means these tickets may just be stale and that's that. But then how might I review them? My strategy of simply looking at the 3 stalest once a fortnight won't work anymore, because it'll just be the same three each time. :) At least with "Priority: Highest" tickets, I felt justified commenting, "Hi, is this still valid?" if I had nothing else meaningful to add. That would push the ticket to the bottom of the queue. Would people mind if I do the same thing with "Priority: High" tickets? I do worry it might cause useless churn. Nonetheless, I think a slow review like this is valuable, since undoubtedly there are tickets that can be closed or reprioritized. I could also do something dull like toggle some metadata, e.g. assign and then unassign myself, which would also "refresh" the ticket and push it to the bottom of the list. Does anybody have any better ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Nov 6 11:13:13 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 6 Nov 2023 13:13:13 +0200 Subject: Docs for RTS option -I In-Reply-To: References: Message-ID: Thanks! Let's see if I can find the time to make a patch for this. On Thu, 2 Nov 2023 at 17:17, Teofil Camarasu wrote: > Hi Bryan, > > Thanks for improving this documentation! I've often found these flags > to be quite confusing. > > > For an interactive application, it is probably a good idea to use the > idle GC, because this will allow finalizers to run and deadlocked threads > to be detected in the idle time when no Haskell computation is happening. > [Why is this a good thing? What happens when the idle GC is disabled?] > > So there's basically 3 ways to trigger a major GC as far as I know: > 1. Heap overflow: when we last performed a major GC we checked how > much live data there is and set a variable so that we do another major > GC when the heap grows to be live * F. > 2. Idle GC > 3. Manually triggering a GC using the interface in System.Mem > > When idle gc is disabled, then GC will happen less often. One of the > other two may still trigger a GC. > > A key difference is both of those are only activated by the mutator > running code: either through allocation or by calling a GC directly. > On the other hand, idle GC can be triggered when the mutator isn't > running. So, if you want to ensure that finalizers get called promptly > then idle GC can help, especially if your application is idle for long > periods of time. > > The other key benefit of the idle GC is that it can reduce the > prevalence of heap overflow GCs. These can only happen when your > application is allocating and hence running code. So it's quite likely > that it's going to tank the response time for the request your > application is serving at the time. And since idle GCs free some > memory, it makes it less likely that you reach the limit that would > trigger a heap overflow GC. > > With idle GCs, if you are lucky, major GCs will only run while your > application isn't meant to be responding to requests at all, which > makes it basically free. > > > Also, it will mean that a GC is less likely to happen when the > application is busy, so application responsiveness may be improved. > However, if the amount of live data in the heap is particularly large, then > the idle GC can cause a significant penalty to responsiveness. [Why? Is it > because the idle GC was delayed by waiting for some idle time, and thus has > more work to do?]. > > The reason this can happen is because the time a major GC takes is > proportional to the live data in the heap. So, if the pause required > by the GC starts to overlap with time when you'd like the application > to be working on a response, then you will regress response times. For > instance if it takes 100ms to run an idle GC and a request comes in > just after you've started the GC then processing it will have to wait > until the GC is over. > > >Conversely, too small of an interval could adversely affect interactive > responsiveness [How? And how is this worse than having idle GC disabled? > What is the actual behavior when it's disabled, anyway?] > > The smaller the interval, the more time you are spending running an > idle GC, the more likely it becomes that it will overlap with time you > want to be doing something else. This is similar to the long GC case > above due to large heaps. > > Another reason you might not want to run it too often is that you are > unlikely to free much memory. > > I think this documentation was written before the non-moving GC was > added. It would also be important to add that the savings in terms of > responsiveness don't really apply if that is enabled as the non-moving > GC runs concurrently with the mutator anyway. So, the main advantage > would just be more prompt finalization, deadlock detection, etc. > > I hope that helps; let me know if you'd like anything clarified. > > Cheers, > Teo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Nov 10 12:34:25 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 10 Nov 2023 12:34:25 +0000 Subject: Nofib Message-ID: Dear devs Building 'nofib' with HEAD fails with real/scs/Parse.hs:40:19: error: [GHC-87543] Ambiguous occurrence ‘List’. It could refer to either ‘Data.List.List’, imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16 (and originally defined in ‘GHC.Types’), or ‘Types.List’, imported from ‘Types’ at real/scs/Parse.hs:8:1-12. | 40 | list :: Parser List | ^^^^ This is because of a change in the export list of Data.List. The fix is easy (hide the import of List). But I don't know how to update nofib and the subdmodule magic to make HEAD pick the new version. Could anyone possible execute on this? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecate at glitchbra.in Fri Nov 10 13:02:06 2023 From: hecate at glitchbra.in (=?UTF-8?Q?H=C3=A9cate?=) Date: Fri, 10 Nov 2023 14:02:06 +0100 Subject: Nofib In-Reply-To: References: Message-ID: <5c8b47ab-f548-4287-b065-ab2d366476aa@glitchbra.in> Hi Simon, To modify nofib, simply submit a merge request to https://gitlab.haskell.org/ghc/nofib with the appropriate change. Once it's integrated, run `git submodule update --remote` in the GHC repo to update the submodule and push the update as part of your work. Cheers, Hécate Le 10/11/2023 à 13:34, Simon Peyton Jones a écrit : > Dear devs > > Building 'nofib' with HEAD fails with > > real/scs/Parse.hs:40:19: error: [GHC-87543] >     Ambiguous occurrence ‘List’. >     It could refer to >        either ‘Data.List.List’, >               imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16 >               (and originally defined in ‘GHC.Types’), >            or ‘Types.List’, >               imported from ‘Types’ at real/scs/Parse.hs:8:1-12. >    | > 40 | list    :: Parser List >    |                   ^^^^ > > This is because of a change in the export list of Data.List.  The fix > is easy (hide the import of List). > > But I don't know how to update nofib and the subdmodule magic to make > HEAD pick the new version. > > Could anyone possible execute on this?  Thanks > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW:https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Fri Nov 10 15:53:11 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 10 Nov 2023 21:23:11 +0530 Subject: [ANNOUNCE] GHC 9.4.8 is now available Message-ID: <6hiqewjmevgygianxd3bc3x6cz2dkwx5xrnntmwpxhwwzj6akd@cgncs2to3xkq> The GHC developers are happy to announce the availability of GHC 9.4.8. Binary distributions, source distributions, and documentation are available on the [release page](/download_ghc_9_4_8.html). This release is primarily a bugfix release addressing a few issues found in the 9.4 series. These include: * A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724). * A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746). * Support for `-split-sections` on Windows. * Enabling `-split-sections` for various Linux and Windows binary distributions, enabling GHC to produce smaller binaries on these platforms. * And a few other fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.8/docs/users_guide/9.4.8-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From simon.peytonjones at gmail.com Fri Nov 10 20:55:13 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 10 Nov 2023 20:55:13 +0000 Subject: Nofib In-Reply-To: <5c8b47ab-f548-4287-b065-ab2d366476aa@glitchbra.in> References: <5c8b47ab-f548-4287-b065-ab2d366476aa@glitchbra.in> Message-ID: Thank you. I could try that but I'm totally submerged at the moment. Is it possible that someone might feel up to actioning this? It's unrelated to my work -- it's just a bug in HEAD. Simon On Fri, 10 Nov 2023 at 13:02, Hécate via ghc-devs wrote: > Hi Simon, > > To modify nofib, simply submit a merge request to > https://gitlab.haskell.org/ghc/nofib with the appropriate change. > Once it's integrated, run `git submodule update --remote` in the GHC repo > to update the submodule and push the update as part of your work. > > Cheers, > Hécate > Le 10/11/2023 à 13:34, Simon Peyton Jones a écrit : > > Dear devs > > Building 'nofib' with HEAD fails with > > real/scs/Parse.hs:40:19: error: [GHC-87543] > Ambiguous occurrence ‘List’. > It could refer to > either ‘Data.List.List’, > imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16 > (and originally defined in ‘GHC.Types’), > or ‘Types.List’, > imported from ‘Types’ at real/scs/Parse.hs:8:1-12. > | > 40 | list :: Parser List > | ^^^^ > > This is because of a change in the export list of Data.List. The fix is > easy (hide the import of List). > > But I don't know how to update nofib and the subdmodule magic to make HEAD > pick the new version. > > Could anyone possible execute on this? Thanks > > Simon > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Nov 10 21:22:54 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Nov 2023 16:22:54 -0500 Subject: [ANNOUNCE] GHC 9.4.8 is now available In-Reply-To: <6hiqewjmevgygianxd3bc3x6cz2dkwx5xrnntmwpxhwwzj6akd@cgncs2to3xkq> References: <6hiqewjmevgygianxd3bc3x6cz2dkwx5xrnntmwpxhwwzj6akd@cgncs2to3xkq> Message-ID: On Fri, Nov 10, 2023 at 09:23:11PM +0530, Zubin Duggal wrote: > The GHC developers are happy to announce the availability of GHC 9.4.8. Binary > distributions, source distributions, and documentation are available on the > [release page](/download_ghc_9_4_8.html). > Many thanks. I am, however, having a problem building 9.4.8 from source on Fedora 36, with GHC 9.4.6 as the compiler, and cabal-install 3.10.1.0. The diagnostic output (some paths made relative to reduce clutter) is: ... | Configure package 'haskeline' | Run Ghc LinkHs Stage1: _build/stage1/libraries/process/build/c/cbits/posix/runProcess.dyn_o (and 8 more) => _build/stage1/libraries/process/build/libHSprocess-1.6.18.0-ghc9.4.8.so | ContextData oracle: resolving data for 'hpc-bin' (Stage1, dyn)... # _build/stage1/utils/hpc/setup-config | Configure package 'hpc-bin' | Package 'hpc-bin' configuration flags: configure --distdir _build/stage1/utils/hpc --cabal-file utils/hpc/hpc-bin.cabal --ipid $pkg-$version --prefix ${pkgroot}/.. --htmldir ${pkgroot}/../../doc/html/libraries/hpc-bin-0.69 --with-ghc=_build/stage0/bin/ghc --ghc-option=-no-global-package-db --ghc-option=-package-db=_build/stage1/lib/package.conf.d --with-ghc-pkg=_build/stage0/bin/ghc-pkg --ghc-pkg-option=--global-package-db=_build/stage1/lib/package.conf.d --enable-library-vanilla --enable-library-profiling --disable-library-for-ghci --enable-shared --with-gcc=/usr/bin/cc --with-ld=ld.gold --with-ar=/bin/ar --with-alex=/bin/alex --with-happy=/bin/happy --configure-option=CFLAGS=-iquote utils/hpc --configure-option=LDFLAGS=-fuse-ld=gold --gcc-options=-iquote utils/hpc -fuse-ld=gold --configure-option=--with-gmp-includes=/usr/include --configure-option=--with-gmp-libraries=/usr/lib64 --configure-option=--host=x86_64-unknown-linux --configure-option=--with-cc=/usr/bin/cc --ghc-option=-ghcversion-file=rts/include/ghcversion.h --ghc-option=-ghcversion-file=rts/include/ghcversion.h --flags=-build-tool-depends -v0 # cabal-configure (for _build/stage1/utils/hpc/setup-config) Error: hadrian: Encountered missing or private dependencies: hpc >=0.6.2 && <0.8 Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/bin/hpc at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.19.7-0a34884117d1c1ae051fb71ab291372738b4fe99639c85970f08dbdf7c0632db:Development.Shake.Internal.Rules.Oracle * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "hpc-bin", pkgPath = "utils/hpc"}, way = dyn})) at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in main:Hadrian.Oracles.Cabal.Rules * Depends on: _build/stage1/utils/hpc/setup-config * Raised the exception: ExitFailure 1 -- Viktor. From ietf-dane at dukhovni.org Fri Nov 10 21:42:01 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 10 Nov 2023 16:42:01 -0500 Subject: [ANNOUNCE] GHC 9.4.8 is now available In-Reply-To: References: <6hiqewjmevgygianxd3bc3x6cz2dkwx5xrnntmwpxhwwzj6akd@cgncs2to3xkq> Message-ID: On Fri, Nov 10, 2023 at 04:22:54PM -0500, Viktor Dukhovni wrote: > On Fri, Nov 10, 2023 at 09:23:11PM +0530, Zubin Duggal wrote: > > > The GHC developers are happy to announce the availability of GHC 9.4.8. Binary > > distributions, source distributions, and documentation are available on the > > [release page](/download_ghc_9_4_8.html). > > > > Many thanks. I am, however, having a problem building 9.4.8 from source > on Fedora 36, with GHC 9.4.6 as the compiler, and cabal-install > 3.10.1.0. The diagnostic output (some paths made relative to reduce > clutter) is: > > ... > Error: hadrian: Encountered missing or private dependencies: > hpc >=0.6.2 && <0.8 Never mind, looks like the source tree wasn't quite up-to-date with all the submodules. Sorry about the noise... -- Viktor. From teofilcamarasu at gmail.com Sat Nov 11 11:35:39 2023 From: teofilcamarasu at gmail.com (Teofil Camarasu) Date: Sat, 11 Nov 2023 11:35:39 +0000 Subject: Nofib In-Reply-To: References: <5c8b47ab-f548-4287-b065-ab2d366476aa@glitchbra.in> Message-ID: Hi folks, I had a spare minute, so I've made some MRs to fix this: - https://gitlab.haskell.org/ghc/nofib/-/merge_requests/71 - https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11592 Cheers, Teo On Fri, Nov 10, 2023 at 8:55 PM Simon Peyton Jones wrote: > > Thank you. I could try that but I'm totally submerged at the moment. > > Is it possible that someone might feel up to actioning this? It's unrelated to my work -- it's just a bug in HEAD. > > Simon > > On Fri, 10 Nov 2023 at 13:02, Hécate via ghc-devs wrote: >> >> Hi Simon, >> >> To modify nofib, simply submit a merge request to https://gitlab.haskell.org/ghc/nofib with the appropriate change. >> Once it's integrated, run `git submodule update --remote` in the GHC repo to update the submodule and push the update as part of your work. >> >> Cheers, >> Hécate >> >> Le 10/11/2023 à 13:34, Simon Peyton Jones a écrit : >> >> Dear devs >> >> Building 'nofib' with HEAD fails with >> >> real/scs/Parse.hs:40:19: error: [GHC-87543] >> Ambiguous occurrence ‘List’. >> It could refer to >> either ‘Data.List.List’, >> imported from ‘Data.List’ at real/scs/Parse.hs:4:1-16 >> (and originally defined in ‘GHC.Types’), >> or ‘Types.List’, >> imported from ‘Types’ at real/scs/Parse.hs:8:1-12. >> | >> 40 | list :: Parser List >> | ^^^^ >> >> This is because of a change in the export list of Data.List. The fix is easy (hide the import of List). >> >> But I don't know how to update nofib and the subdmodule magic to make HEAD pick the new version. >> >> Could anyone possible execute on this? Thanks >> >> Simon >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -- >> Hécate ✨ >> 🐦: @TechnoEmpress >> IRC: Hecate >> WWW: https://glitchbra.in >> RUN: BSD >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs 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 From ietf-dane at dukhovni.org Sat Nov 11 21:20:52 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 11 Nov 2023 16:20:52 -0500 Subject: Support conversion from (UArray i Word8) to ShortByteString? Message-ID: The 'ShortByteString' type in the "bytestring" package has seen some singnificant improvement recently, and yet its API is still noticeably limited in comparison to its pinned, I/O friendly 'ByteString' elder sibling. One of the limitations is that that there are fewer ways to construct a 'ShortByteString' object. One often has to restort to constructing a pinned ByteString, and then copy. (There no "ST" Builders that write to resizable MutableByteArrays instead of raw memory pointers). Meanwhile, under-the covers, both the "UArray i Word8" type and 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API provides a flexible "UArray" construction interface. Would it be reasonable to "bridge" the two APIs: Data.Array.Unboxed: (re-export from Data.Array.Base) import Data.Array.Byte arrayToByteArray :: UArray i Word8 -> ByteArray arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# {-# INLINE arrayToByArrray #-} Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) byteArrayToShort :: ByteArray -> ShortByteString byteArrayToShort = coerce {-# INLINE byteArrayToShort #-} It would then be possible to write: short = byteArrayToShort $ arrayToByteArray $ runSTUArray m where m = do a <- newArray (0, last) 0 -- zero fill sequence_ [ writeArray a ix e | (ix, e) <- generator ] and generate the bytes of a 'ShortByteString' from an arbitrary computation, possibly merging multiple inputs into some bytes by using the recently introduced "modifyArray" (or explicit read/modify/write). Any thoughts about the wisdom or lack thereof of this proposal? An alternative is to add a tailored version of the UArray and STUArray APIs to 'MutableByteArray' by extending the rather limited API of 'Data.Array.Byte': runMutableByteArray :: (forall s. ST s (MutableByteArray s)) -> ByteArray runMutableByteArray m = runST $ m >>= freezeMutableByteArray freezeMutableByteArray (MutableByteArray mba#) = ST $ \s -> case unsafeFreezeByteArray# mba# s of (# s', ba# #) -> (# s', ByteArray ba# #) Since "Data.Array.Byte" is an "array" (rather than string) interface, it could have a richer set of indexed read/write/modify primitives along the lines of those found in "Data.Array.STUArray", but specialised to 'Word8' elements and implicit zero-based integer indexing. The flexible construction I seek would then be via "Data.Array.Bytes", rather than the somewhat too general index and value types from UArray. short = byteArrayToShort $ runMutableByteArray m where m = do a <- newByteArray size 0 -- 0 fill sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] In this scenario, the indexed-mutation of ShortByteStrings under construction, or indexed-mutation of copies for various transformations, could live in Data.Array.Byte, with ShortByteString and various applications leveraging the random-access mutation (and resizing, ...) to implement higher level operations. -- Viktor. From clyring at gmail.com Tue Nov 14 02:35:06 2023 From: clyring at gmail.com (Matthew Craven) Date: Mon, 13 Nov 2023 21:35:06 -0500 Subject: Support conversion from (UArray i Word8) to ShortByteString? In-Reply-To: References: Message-ID: Viktor, Your proposed `arrayToByteArray` seems plausible. Your proposed `byteArrayToShort` is just the newtype-constructor `ShortByteString` which is exposed from Data.ByteString.Short since bytestring-0.12.0.0. > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': How does this compare to the interface provided by primitive:Data.Primitive.ByteArray? Their `runByteArray` is your `runMutableByteArray`. > The 'ShortByteString' type in the "bytestring" package has seen some > singnificant improvement recently, and yet its API is still noticeably > limited in comparison to its pinned, I/O friendly 'ByteString' elder > sibling. > > One of the limitations is that that there are fewer ways to construct a > 'ShortByteString' object. One often has to restort to constructing a > pinned ByteString, and then copy. (There no "ST" Builders that write > to resizable MutableByteArrays instead of raw memory pointers). > > Meanwhile, under-the covers, both the "UArray i Word8" type and > 'ShortByteString' hold an immutable 'ByteArray', and the STUArray API > provides a flexible "UArray" construction interface. > > Would it be reasonable to "bridge" the two APIs: > > Data.Array.Unboxed: (re-export from Data.Array.Base) > import Data.Array.Byte > > arrayToByteArray :: UArray i Word8 -> ByteArray > arrayToByteArray (UArray _ _ _ ba#) = ByteArray ba# > {-# INLINE arrayToByArrray #-} > > Data.ByteString.Short: (re-export from Data.ByteString.Short.Internal) > byteArrayToShort :: ByteArray -> ShortByteString > byteArrayToShort = coerce > {-# INLINE byteArrayToShort #-} > > It would then be possible to write: > > short = byteArrayToShort $ arrayToByteArray $ runSTUArray m > where > m = do > a <- newArray (0, last) 0 -- zero fill > sequence_ [ writeArray a ix e | (ix, e) <- generator ] > > and generate the bytes of a 'ShortByteString' from an arbitrary > computation, possibly merging multiple inputs into some bytes by using > the recently introduced "modifyArray" (or explicit read/modify/write). > > Any thoughts about the wisdom or lack thereof of this proposal? > > An alternative is to add a tailored version of the UArray and STUArray > APIs to 'MutableByteArray' by extending the rather limited API of > 'Data.Array.Byte': > > runMutableByteArray :: (forall s. ST s (MutableByteArray s)) > -> ByteArray > runMutableByteArray m = runST $ m >>= freezeMutableByteArray > > freezeMutableByteArray (MutableByteArray mba#) = > ST $ \s -> case unsafeFreezeByteArray# mba# s of > (# s', ba# #) -> (# s', ByteArray ba# #) > > Since "Data.Array.Byte" is an "array" (rather than string) interface, it > could have a richer set of indexed read/write/modify primitives along > the lines of those found in "Data.Array.STUArray", but specialised to > 'Word8' elements and implicit zero-based integer indexing. > > The flexible construction I seek would then be via "Data.Array.Bytes", > rather than the somewhat too general index and value types from UArray. > > short = byteArrayToShort $ runMutableByteArray m > where > m = do > a <- newByteArray size 0 -- 0 fill > sequence_ [ writeByteArray a ix e | (ix, e) <- generator ] > > In this scenario, the indexed-mutation of ShortByteStrings under > construction, or indexed-mutation of copies for various transformations, > could live in Data.Array.Byte, with ShortByteString and various > applications leveraging the random-access mutation (and resizing, ...) > to implement higher level operations. > > -- > Viktor. From ietf-dane at dukhovni.org Tue Nov 14 06:10:03 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 14 Nov 2023 01:10:03 -0500 Subject: Support conversion from (UArray i Word8) to ShortByteString? In-Reply-To: References: Message-ID: On Mon, Nov 13, 2023 at 09:35:06PM -0500, Matthew Craven wrote: > Your proposed `arrayToByteArray` seems plausible. Thanks, that could be handy, but see below. > Your proposed `byteArrayToShort` is just the newtype-constructor > `ShortByteString` which is exposed from Data.ByteString.Short since > bytestring-0.12.0.0. Thanks. I did not notice these are now exposed without having to import unstable "Internal" interfaces: GHCi, version 9.8.1: ... λ> import Data.Array.Byte λ> import Data.ByteString.Short λ> :t ShortByteString ShortByteString :: Data.Array.Byte.ByteArray -> ShortByteString λ> :t SBS SBS :: GHC.Prim.ByteArray# -> ShortByteString λ> :t ByteArray ByteArray :: GHC.Prim.ByteArray# -> ByteArray So as of GHC 9.8.1 and "bytestring" 12, I have all the missing glue. > > An alternative is to add a tailored version of the UArray and STUArray > > APIs to 'MutableByteArray' by extending the rather limited API of > > 'Data.Array.Byte': > > How does this compare to the interface provided by > primitive:Data.Primitive.ByteArray? Their `runByteArray` is your > `runMutableByteArray`. I was unaware that the "primitive" packages already provides what I was looking for. Unlike the case with "array", there's no duplication of bounds checks for performing separate read/write at the same index (because there are no bounds checks), so the "missing" will not be missed. Looks like I'm all set. Just need to use 'SBS' in place of 'ShortByteString' while working with GHC 9.[246].*. For my use case, I don't need the additional safety (bounds checks) of "array", but it is perhaps reasonable to consider adding the proposed bridge (from UArray i Word8), for users who want a bit more safety than one gets with "primitive". -- Viktor. From FrozenDude101 at outlook.com Mon Nov 20 00:38:58 2023 From: FrozenDude101 at outlook.com (Matthew Hammond) Date: Mon, 20 Nov 2023 00:38:58 +0000 Subject: Account Approval Message-ID: Hello everyone, I’ve been working on my own Haskell interpreter and found a strange case that GHC seems to hang on until it overflows, where I would expect a proper error. I’m fairly new to Haskell, and completely new to the GHC codebase, but I figured I might as well give it a shot! I’ve made an account on the GitLab, and I’m requesting approval please. Thanks, Matthew Hammond. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Nov 20 08:18:14 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 20 Nov 2023 10:18:14 +0200 Subject: Account Approval In-Reply-To: References: Message-ID: Approved! On Mon, 20 Nov 2023, 2.39 Matthew Hammond, wrote: > Hello everyone, > > > > I’ve been working on my own Haskell interpreter and found a strange case > that GHC seems to hang on until it overflows, where I would expect a proper > error. > > I’m fairly new to Haskell, and completely new to the GHC codebase, but I > figured I might as well give it a shot! > > I’ve made an account on the GitLab, and I’m requesting approval please. > > > > Thanks, > > Matthew Hammond. > _______________________________________________ > 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 Wed Nov 22 16:01:52 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 22 Nov 2023 18:01:52 +0200 Subject: Docs for RTS option -I In-Reply-To: References: Message-ID: I've now drafted some new documentation at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11655. Reviews welcome. On Mon, 6 Nov 2023 at 13:13, Bryan Richter wrote: > Thanks! Let's see if I can find the time to make a patch for this. > > On Thu, 2 Nov 2023 at 17:17, Teofil Camarasu > wrote: > >> Hi Bryan, >> >> Thanks for improving this documentation! I've often found these flags >> to be quite confusing. >> >> > For an interactive application, it is probably a good idea to use the >> idle GC, because this will allow finalizers to run and deadlocked threads >> to be detected in the idle time when no Haskell computation is happening. >> [Why is this a good thing? What happens when the idle GC is disabled?] >> >> So there's basically 3 ways to trigger a major GC as far as I know: >> 1. Heap overflow: when we last performed a major GC we checked how >> much live data there is and set a variable so that we do another major >> GC when the heap grows to be live * F. >> 2. Idle GC >> 3. Manually triggering a GC using the interface in System.Mem >> >> When idle gc is disabled, then GC will happen less often. One of the >> other two may still trigger a GC. >> >> A key difference is both of those are only activated by the mutator >> running code: either through allocation or by calling a GC directly. >> On the other hand, idle GC can be triggered when the mutator isn't >> running. So, if you want to ensure that finalizers get called promptly >> then idle GC can help, especially if your application is idle for long >> periods of time. >> >> The other key benefit of the idle GC is that it can reduce the >> prevalence of heap overflow GCs. These can only happen when your >> application is allocating and hence running code. So it's quite likely >> that it's going to tank the response time for the request your >> application is serving at the time. And since idle GCs free some >> memory, it makes it less likely that you reach the limit that would >> trigger a heap overflow GC. >> >> With idle GCs, if you are lucky, major GCs will only run while your >> application isn't meant to be responding to requests at all, which >> makes it basically free. >> >> > Also, it will mean that a GC is less likely to happen when the >> application is busy, so application responsiveness may be improved. >> However, if the amount of live data in the heap is particularly large, then >> the idle GC can cause a significant penalty to responsiveness. [Why? Is it >> because the idle GC was delayed by waiting for some idle time, and thus has >> more work to do?]. >> >> The reason this can happen is because the time a major GC takes is >> proportional to the live data in the heap. So, if the pause required >> by the GC starts to overlap with time when you'd like the application >> to be working on a response, then you will regress response times. For >> instance if it takes 100ms to run an idle GC and a request comes in >> just after you've started the GC then processing it will have to wait >> until the GC is over. >> >> >Conversely, too small of an interval could adversely affect interactive >> responsiveness [How? And how is this worse than having idle GC disabled? >> What is the actual behavior when it's disabled, anyway?] >> >> The smaller the interval, the more time you are spending running an >> idle GC, the more likely it becomes that it will overlap with time you >> want to be doing something else. This is similar to the long GC case >> above due to large heaps. >> >> Another reason you might not want to run it too often is that you are >> unlikely to free much memory. >> >> I think this documentation was written before the non-moving GC was >> added. It would also be important to add that the savings in terms of >> responsiveness don't really apply if that is enabled as the non-moving >> GC runs concurrently with the mutator anyway. So, the main advantage >> would just be more prompt finalization, deadlock detection, etc. >> >> I hope that helps; let me know if you'd like anything clarified. >> >> Cheers, >> Teo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Fri Nov 24 12:17:22 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 24 Nov 2023 17:47:22 +0530 Subject: Upcoming GHC 9.6.4 release Message-ID: Hi all, We are planning a release in the 9.6 series before Christmas, with a preliminary ETA of 15th December. Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 Please use this ticket to request any submodule bumps or for any other discussion related to the release. If you would like any patches to be considered for inclusion in this release please ensure that the corresponding Merge Requests are marked with the ~"backport needed:9.6" label. The current set of all MRs being considered for inclusion can be viewed at https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&label_name[]=backport%20needed%3A9.6 Cheers, Zubin From moritz.angermann at gmail.com Fri Nov 24 12:26:24 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 24 Nov 2023 20:26:24 +0800 Subject: Upcoming GHC 9.6.4 release In-Reply-To: References: Message-ID: Can I suggest the release to be pushed into 2024? Releasing it on the 15th or a few days later will put significant burden onto integrators, and distributors. To react to the ghc release. Especially right before the holiday season for quite some. Cheers, Moritz On Fri, 24 Nov 2023 at 8:17 PM, Zubin Duggal wrote: > Hi all, > > We are planning a release in the 9.6 series before Christmas, with a > preliminary ETA of 15th December. > > Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 > Please use this ticket to request any submodule bumps or for any other > discussion related to the release. > > If you would like any patches to be considered for inclusion in this > release please ensure that the corresponding Merge Requests are marked > with the ~"backport needed:9.6" label. > > The current set of all MRs being considered for inclusion can be viewed at > > https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&label_name[]=backport%20needed%3A9.6 > > Cheers, > Zubin > _______________________________________________ > 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 zubin at well-typed.com Fri Nov 24 13:39:19 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 24 Nov 2023 19:09:19 +0530 Subject: Upcoming GHC 9.6.4 release In-Reply-To: References: Message-ID: <4oy2an2i3fhyq5uepae3pcfewlhsgcwnzteemvwhybxd47nfqv@s4bhtlmsjyck> Thanks for raising this Moritz. We decided to do the release in December before we are busy with other matters in January like the 9.10 fork. However, we do see the burdern this would place on distributors to react just a week before the holidays. We have decided to push the release date to the first week of January 2024. Please note that we still plan to finalise the release branch by mid-December so what I said originally about marking patches for backport ASAP still applies. On 23/11/24 20:26, Moritz Angermann wrote: >Can I suggest the release to be pushed into 2024? > >Releasing it on the 15th or a few days later will put significant burden >onto integrators, and distributors. To react to the ghc release. Especially >right before the holiday season for quite some. > >Cheers, > Moritz > >On Fri, 24 Nov 2023 at 8:17 PM, Zubin Duggal wrote: > >> Hi all, >> >> We are planning a release in the 9.6 series before Christmas, with a >> preliminary ETA of 15th December. >> >> Release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24017 >> Please use this ticket to request any submodule bumps or for any other >> discussion related to the release. >> >> If you would like any patches to be considered for inclusion in this >> release please ensure that the corresponding Merge Requests are marked >> with the ~"backport needed:9.6" label. >> >> The current set of all MRs being considered for inclusion can be viewed at >> >> https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&label_name[]=backport%20needed%3A9.6 >> >> Cheers, >> Zubin >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From moritz.angermann at gmail.com Fri Nov 24 13:56:38 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 24 Nov 2023 21:56:38 +0800 Subject: Upcoming GHC 9.6.4 release In-Reply-To: <4oy2an2i3fhyq5uepae3pcfewlhsgcwnzteemvwhybxd47nfqv@s4bhtlmsjyck> References: <4oy2an2i3fhyq5uepae3pcfewlhsgcwnzteemvwhybxd47nfqv@s4bhtlmsjyck> Message-ID: Thanks! Backport-freeze for mid-December sounds absolutely reasonable! -Moritz On Fri, 24 Nov 2023 at 9:39 PM, Zubin Duggal wrote: > Thanks for raising this Moritz. We decided to do the release in December > before we are busy with other matters in January like the 9.10 fork. > However, we do see the burdern this would place on distributors to react > just a week before the holidays. > > We have decided to push the release date to the first week of January > 2024. > > Please note that we still plan to finalise the release branch by > mid-December so what I said originally about marking patches for > backport ASAP still applies. > > On 23/11/24 20:26, Moritz Angermann wrote: > >Can I suggest the release to be pushed into 2024? > > > >Releasing it on the 15th or a few days later will put significant burden > >onto integrators, and distributors. To react to the ghc release. > Especially > >right before the holiday season for quite some. > > > >Cheers, > > Moritz > > > >On Fri, 24 Nov 2023 at 8:17 PM, Zubin Duggal > wrote: > > > >> Hi all, > >> > >> We are planning a release in the 9.6 series before Christmas, with a > >> preliminary ETA of 15th December. > >> > >> Release tracking ticket: > https://gitlab.haskell.org/ghc/ghc/-/issues/24017 > >> Please use this ticket to request any submodule bumps or for any other > >> discussion related to the release. > >> > >> If you would like any patches to be considered for inclusion in this > >> release please ensure that the corresponding Merge Requests are marked > >> with the ~"backport needed:9.6" label. > >> > >> The current set of all MRs being considered for inclusion can be viewed > at > >> > >> > https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all&state=all&label_name[]=backport%20needed%3A9.6 > >> > >> Cheers, > >> Zubin > >> _______________________________________________ > >> 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 ietf-dane at dukhovni.org Sat Nov 25 06:07:37 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Nov 2023 01:07:37 -0500 Subject: Problems building cabal-install? Message-ID: I am having a rather unexpected difficulty building older versions of cabal-install. The invariably run into conflicts between "Cabal" and "Cabal-syntax". The latter shows up as a dependency of "Cabal" on hackage, but not in the upstream Git repo. Is there is there some sort of problem with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with conflicting definitions. -- Viktor. From ietf-dane at dukhovni.org Sat Nov 25 06:45:50 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Nov 2023 01:45:50 -0500 Subject: Problems building cabal-install? In-Reply-To: References: Message-ID: On Sat, Nov 25, 2023 at 01:07:37AM -0500, Viktor Dukhovni wrote: > I am having a rather unexpected difficulty building older versions of > cabal-install. The invariably run into conflicts between "Cabal" and > "Cabal-syntax". > > The latter shows up as a dependency of "Cabal" on hackage, but not > in the upstream Git repo. Is there is there some sort of problem > with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... > > It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with > conflicting definitions. I was able to build 'cabal-3.4' from git, after running "cabal freeze" and editing the freeze file to clear the "+cabal-syntax" flag that for some reason was getting set for "hackage-security" (seems to the source of problem) and removing the "3.10" pin for "Cabal-syntax". -- Viktor. From ben at smart-cactus.org Sat Nov 25 21:52:04 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 25 Nov 2023 16:52:04 -0500 Subject: Problems building cabal-install? In-Reply-To: References: Message-ID: <87fs0t8prx.fsf@smart-cactus.org> Viktor Dukhovni writes: > I am having a rather unexpected difficulty building older versions of > cabal-install. The invariably run into conflicts between "Cabal" and > "Cabal-syntax". > > The latter shows up as a dependency of "Cabal" on hackage, but not > in the upstream Git repo. Is there is there some sort of problem > with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... > > It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with > conflicting definitions. > I believe it is expected that `Cabal-syntax` should appear in the dependency set of `Cabal`. I had no trouble building `cabal-install` from upstream `master` (4f53a2feeb17bd54b609ee7cfba3c25348aca997) with GHC 9.6.3. Perhaps you could describe more precisely what you are doing? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ietf-dane at dukhovni.org Sat Nov 25 21:56:05 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Nov 2023 16:56:05 -0500 Subject: Problems building cabal-install? In-Reply-To: <87fs0t8prx.fsf@smart-cactus.org> References: <87fs0t8prx.fsf@smart-cactus.org> Message-ID: On Sat, Nov 25, 2023 at 04:52:04PM -0500, Ben Gamari wrote: > > The latter shows up as a dependency of "Cabal" on hackage, but not > > in the upstream Git repo. Is there is there some sort of problem > > with the hackage metadata for Cabal 3.0, 3.2, 3.4, ... > > > > It is odd for these to have "Cabal-syntax 3.10.*" as a dependency, with > > conflicting definitions. > > > I believe it is expected that `Cabal-syntax` should appear in the > dependency set of `Cabal`. I had no trouble building `cabal-install` > from upstream `master` (4f53a2feeb17bd54b609ee7cfba3c25348aca997) with > GHC 9.6.3. > > Perhaps you could describe more precisely what you are doing? Just, for example: $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install This fails due to a conflict between Cabal-3.4 and Cabal-syntax-3.10, (which is not the right choice of dependency for Cabal 3.4). The hackage dependency data looks wrong, the "cabal-syntax" flag in "hackage-security" should not default to "on", and then an older version of "Cabal-syntax" would be chosen. -- Viktor. From ben at smart-cactus.org Sat Nov 25 22:09:59 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Sat, 25 Nov 2023 17:09:59 -0500 Subject: Problems building cabal-install? In-Reply-To: References: <87fs0t8prx.fsf@smart-cactus.org> Message-ID: <87cyvx8oy3.fsf@smart-cactus.org> Viktor Dukhovni writes: > Just, for example: > > $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install > > This fails due to a conflict between Cabal-3.4 and Cabal-syntax-3.10, > (which is not the right choice of dependency for Cabal 3.4). > > The hackage dependency data looks wrong, the "cabal-syntax" flag in > "hackage-security" should not default to "on", and then an older > version of "Cabal-syntax" would be chosen. > Which GHC version are you attempting to build with? My guess is that `cabal-install-3.4` excludes your GHC's `base` via its version constraints. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ietf-dane at dukhovni.org Sat Nov 25 22:23:33 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Nov 2023 17:23:33 -0500 Subject: Problems building cabal-install? In-Reply-To: <87cyvx8oy3.fsf@smart-cactus.org> References: <87fs0t8prx.fsf@smart-cactus.org> <87cyvx8oy3.fsf@smart-cactus.org> Message-ID: On Sat, Nov 25, 2023 at 05:09:59PM -0500, Ben Gamari wrote: > Viktor Dukhovni writes: > > > Just, for example: > > > > $ cabal install --constraint "cabal-install ^>= 3.4" cabal-install > > > > This fails due to a conflict between Cabal-3.4 and Cabal-syntax-3.10, > > (which is not the right choice of dependency for Cabal 3.4). > > > > The hackage dependency data looks wrong, the "cabal-syntax" flag in > > "hackage-security" should not default to "on", and then an older > > version of "Cabal-syntax" would be chosen. > > Which GHC version are you attempting to build with? My guess is that > `cabal-install-3.4` excludes your GHC's `base` via its version > constraints. No, I'm specifically using GHC 8.10, which actually comes with the Cabal 3.4 library. Also tried 8.8 with same results. -- Viktor. From ietf-dane at dukhovni.org Sun Nov 26 01:30:42 2023 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Nov 2023 20:30:42 -0500 Subject: Problems building cabal-install? In-Reply-To: References: <87fs0t8prx.fsf@smart-cactus.org> <87cyvx8oy3.fsf@smart-cactus.org> Message-ID: On Sat, Nov 25, 2023 at 05:23:33PM -0500, Viktor Dukhovni wrote: > > Which GHC version are you attempting to build with? My guess is that > > `cabal-install-3.4` excludes your GHC's `base` via its version > > constraints. > > No, I'm specifically using GHC 8.10, which actually comes with the Cabal > 3.4 library. Also tried 8.8 with same results. Here's the build output: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.8.4 $ cabal --version cabal-install version 3.0.1.0 compiled using version 3.0.1.0 of the Cabal library $ cabal install --constraint 'cabal-install ^>=3.4' cabal-install Resolving dependencies... Build profile: -w ghc-8.8.4 -O1 In order, the following will be built (use -v for more details): - Cabal-3.4.1.0 (lib) (requires build) - Cabal-syntax-3.10.2.0 (lib) (requires build) ... - hackage-security-0.6.2.3 (lib) (requires build) ... - cabal-install-3.4.1.0 (exe:cabal) (requires build) ... Installing Cabal-syntax-3.10.2.0 (lib) Completed Cabal-syntax-3.10.2.0 (lib) Starting hackage-security-0.6.2.3 (lib) Building hackage-security-0.6.2.3 (lib) Installing hackage-security-0.6.2.3 (lib) Completed hackage-security-0.6.2.3 (lib) Installing Cabal-3.4.1.0 (lib) Completed Cabal-3.4.1.0 (lib) Starting cabal-install-3.4.1.0 (exe:cabal) Building cabal-install-3.4.1.0 (exe:cabal) Failed to build exe:cabal from cabal-install-3.4.1.0. Build log ( /home/viktor/.cabal/logs/ghc-8.8.4/cabal-install-3.4.1.0-0f55dc0aa499748357ddf42c4e32b1e210d53da7ef90484735d9a77309f7612d.log ): Configuring executable 'cabal' for cabal-install-3.4.1.0.. Preprocessing executable 'cabal' for cabal-install-3.4.1.0.. Building executable 'cabal' for cabal-install-3.4.1.0.. [ 1 of 180] Compiling Distribution.Client.Compat.Directory ( Distribution/Client/Compat/Directory.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Compat/Directory.o ) [ 2 of 180] Compiling Distribution.Client.Compat.ExecutablePath ( Distribution/Client/Compat/ExecutablePath.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Compat/ExecutablePath.o ) ... [128 of 180] Compiling Distribution.Client.FetchUtils ( Distribution/Client/FetchUtils.hs, dist/build/cabal/cabal-tmp/Distribution/Client/FetchUtils.o ) Distribution/Client/FetchUtils.hs:195:36: error: • Couldn't match type ‘Distribution.Types.PackageId.PackageIdentifier’ with ‘Cabal-syntax-3.10.2.0:Distribution.Types.PackageId.PackageIdentifier’ NB: ‘Cabal-syntax-3.10.2.0:Distribution.Types.PackageId.PackageIdentifier’ is defined in ‘Distribution.Types.PackageId’ in package ‘Cabal-syntax-3.10.2.0’ ‘Distribution.Types.PackageId.PackageIdentifier’ is defined in ‘Distribution.Types.PackageId’ in package ‘Cabal-3.4.1.0’ Expected type: Cabal-syntax-3.10.2.0:Distribution.Types.PackageId.PackageIdentifier Actual type: PackageId • In the second argument of ‘Sec.downloadPackage'’, namely ‘pkgid’ In a stmt of a 'do' block: Sec.downloadPackage' rep pkgid path In the second argument of ‘($)’, namely ‘do info verbosity ("Writing " ++ path) Sec.downloadPackage' rep pkgid path’ | 195 | Sec.downloadPackage' rep pkgid path | ^^^^^ cabal: Failed to build exe:cabal from cabal-install-3.4.1.0. See the build log above for details. -- Viktor.