- Glasgow-haskell-users

GHC formally discontinuing 32-bit Windows support?
by Ben Gamari 16 Jul '20

16 Jul '20

tl;dr. Unless someone speaks up, GHC will formally discontinue its (currently-broken) support for 32-bit Windows in 8.12. Hi everyone, As some have noticed, recent GHC releases' support for 32-bit Windows support can be generously described as "unreliable". This has been due to a combination of platform limitations, native toolchain bugs, and a general lack of capacity within the GHC community focusing on Windows support. I won't summarise the concrete issues here (see #17961, and #17700 for the current state-of-play) but let it suffice to say that we are currently stuck due to a bug in GNU binutils. However, I was recently informed that Cygwin and msys have recently discontinued their support for 32-bit Windows. While GHC uses a toolchain from the mingw32-w64 project, it seems only a matter of time before 32-bit builds cease there as well (see [1] for a summary of the relationships between these projects). Furthermore, Microsoft itself has said that 32-bit Windows 10 releases will cease later this year. All of this suggests to me that supporting 32-bit Windows in GHC will be, at best, an up-hill battle. Even worse, it is a battle with little to gained: essentially all Intel-based Windows systems today run on 64-bit-capable systems. I know of no compelling reasons why users would opt to use 32-bit Windows in 2020. Consequently, I suggest that we should formally discontinue 32-bit Windows support in GHC 8.12. In my opinion, GHC's limited engineering capacity on Windows is better spent elsewhere. However, if there are compelling reasons why some users still rely on 32-bit Windows support (despite it being largely unusable for the last two years), please do let me know. I have been consistently surprised by the number of users who have noted the absence of 32-bit Windows builds; I would love to know why they seem to be so popular. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/surviving-windows

1 0

[ANNOUNCE] GHC 8.8.4 is now available
by Ben Gamari 15 Jul '20

15 Jul '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.4 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.3: - Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately. - Works around a Linux kernel bug in the implementation of timerfd (#18033) - Fixes a few linking issues affecting ARM - Fixes "missing interface file" error triggered by some uses of Data.Ord.Ordering (#18185) - Fixes an integer overflow in the compact-normal-form import implementation (#16992) - `configure` now accepts a `--enable-numa` flag to enable/disable `numactl` support on Linux. - Fixes potentially lost sharing due to the desugaring of left operator sections (#18151). - Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024) As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.h…

1 0

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1 released
by Ben Gamari 18 May '20

18 May '20

Hello all, The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1/ GHC 8.10.1 brings a number of new features including: * The new UnliftedNewtypes extension allowing newtypes around unlifted types. * The new StandaloneKindSignatures extension allows users to give top-level kind signatures to type, type family, and class declarations. * A new warning, -Wderiving-defaults, to draw attention to ambiguous deriving clauses * A number of improvements in code generation, including changes * A new GHCi command, :instances, for listing the class instances available for a type. * An upgraded Windows toolchain lifting the MAX_PATH limitation * A new, low-latency garbage collector. * Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 8.10.2 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418

2 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 14 May '20

14 May '20

On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 7:32 PM, Henning Thielemann wrote: > >> Can someone please give me examples where current state lacks > > * Currently stack traces are not printed, so users cannot forward them > to the developer, even if both the users and the developers would like > that. We are talking about the HasCallStack stack traces, yes? How is their emission addressed by extending exceptions with stack traces? > * Developers cannot easily produce stack traces do debug unintended > exceptions. What are "unintended exceptions"? What is an example of an "unintended exception"?

4 4

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 12 May '20

12 May '20

On Fri, 8 May 2020, Niklas Hambüchen wrote: > On 5/8/20 5:37 PM, Henning Thielemann wrote: > >> a callstack is not useful for a user. > > Call stacks have been very useful to me as a user of non-Haskell tools > so far, because they are excellent for attaching to bug reports and > usually led to developers fixing my problems faster. This confirms that they are not for you, but you only forward them to the developer. Can someone please give me examples where current state lacks and how they are addressed by the proposal(s)?

2 2

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Henning Thielemann 12 May '20

12 May '20

On Fri, 8 May 2020, Niklas Hambüchen wrote: >> What are "unintended exceptions"? >> What is an example of an "unintended exception"? > > A recent example from my production server: > > hPutBuf: resource vanished (Broken pipe) Ok, I lookup the Haddock comment of hPutBuf and it says: "This operation may fail with: * ResourceVanished if the handle is a pipe or socket, and the reading end is closed." That is, ResourceVanished is part of the public interface and in no way unexpected (or what "unintended" may be). I would prefer to make this explicit in the type of hPutBuf: hPutBuf :: (ResourceVanishedException e) => Handle -> Ptr a -> Int -> ExceptT e IO () Now, what do you intend to do with the call-stack? Isn't it something you can attach to the e value?

1 0

Re: Decorating exceptions with backtrace information
by Ben Gamari 11 May '20

11 May '20

Michael Sloan <mgsloan(a)gmail.com> writes: > Thanks so much for making a proposal for this, Ben!! It's great to see > progress here. > > I'm also glad that there is now a proposal process. I made a fairly > similar proposal almost exactly 5 years ago to the libraries list - > https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but > without the subtlety of particular backtrace representations. Skimming the > ensuing thread may still be informative. > Thanks for the reference, Michael! My feeling is that the proposal in that thread is a bit too dynamic. That being said, I can see the argument for wanting, for instance, a robust way to determine that an exception is asynchronous. > In particular, there is one thing I would like to highlight from that old > proposal. I think it'd be good to have a standard way to represent a chain > of exceptions, and build this into `catch` and `finally`. Python and Java > both have a mechanism for this, and both refer to it as a "cause" > exception. When an exception is thrown during exception handling, the > exception being handled is preserved as its "cause". I find this mechanism > to be incredibly useful in Java, it has made the underlying issue much > clearer in many cases, and in other cases at least provides helpful > context. I have no doubt such a mechanism would have saved me many hours > of debugging exceptions in Haskell systems I've worked on in the past. > > I considered commenting about that directly on the proposal, but I figure > this is a better place to suggest expanding the scope of the change :) . > Totally understandable if you want to keep this proposal focused on > stacktraces, but I think it'd be good to consider this as a potential > future improvement. > Indeed I can see the point. I'll keep this point in the back of my mind. I'm not eager to further expand the scope of the proposal at the moment, but we should be certain that the backtrace design doesn't unintentionally close the door to this use-case. However, one question I would have is whether the exception-chaining use-case *needs* to be handled in SomeException. For instance, you could rather leave this to user code. You might even give this pattern a typeclass. For instance, class HasChainedException e where getChainedException :: e -> Maybe SomeException data MyException = MyException { causedBy :: SomeException } instance HasChainedException MyException where getChainedException = causedBy Cheers, - Ben

1 0

Re: Decorating exceptions with backtrace information
by Carter Schonwald 08 May '20

08 May '20

ben, could you please email the libraries list with this too? This seems like a core libraries / base change rather than a ghc-the-compiler change On Thu, May 7, 2020 at 6:57 PM Michael Sloan <mgsloan(a)gmail.com> wrote: > Thanks so much for making a proposal for this, Ben!! It's great to see > progress here. > > I'm also glad that there is now a proposal process. I made a fairly > similar proposal almost exactly 5 years ago to the libraries list - > https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but > without the subtlety of particular backtrace representations. Skimming the > ensuing thread may still be informative. > > In particular, there is one thing I would like to highlight from that old > proposal. I think it'd be good to have a standard way to represent a chain > of exceptions, and build this into `catch` and `finally`. Python and Java > both have a mechanism for this, and both refer to it as a "cause" > exception. When an exception is thrown during exception handling, the > exception being handled is preserved as its "cause". I find this mechanism > to be incredibly useful in Java, it has made the underlying issue much > clearer in many cases, and in other cases at least provides helpful > context. I have no doubt such a mechanism would have saved me many hours > of debugging exceptions in Haskell systems I've worked on in the past. > > I considered commenting about that directly on the proposal, but I figure > this is a better place to suggest expanding the scope of the change :) . > Totally understandable if you want to keep this proposal focused on > stacktraces, but I think it'd be good to consider this as a potential > future improvement. > > -Michael > > On Thu, May 7, 2020 at 3:55 PM Ben Gamari <ben(a)well-typed.com> wrote: > >> >> Hi everyone, >> >> After a nice discussion on IRC about the unfortunate state of error >> reporting in Haskell, I felt compelled to write down some long-lingering >> thoughts regarding backtraces on exceptions. The result is GHC proposal >> #330 [1]. I think the approach is viable and perhaps even >> straightforward. I have the sketch of an implementation here [2]. >> >> Please have a look at the proposal and leave your comments. If there is >> consensus it is possible that we could have this done for 8.12. >> >> Cheers, >> >> - Ben >> >> >> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 >> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

2 2

Decorating exceptions with backtrace information
by Ben Gamari 07 May '20

07 May '20

Hi everyone, After a nice discussion on IRC about the unfortunate state of error reporting in Haskell, I felt compelled to write down some long-lingering thoughts regarding backtraces on exceptions. The result is GHC proposal #330 [1]. I think the approach is viable and perhaps even straightforward. I have the sketch of an implementation here [2]. Please have a look at the proposal and leave your comments. If there is consensus it is possible that we could have this done for 8.12. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236

1 0

is cabal-install buildable?
by Evan Laforge 29 Mar '20

29 Mar '20

I recently upgraded to ghc 8.8.3, thinking that since it's been around 8 months and 8.10 is already out, maybe things have stabilized enough. But I immediately ran into confusing trouble with cabal-install. It seems like it's just not buildable since 8.8 came out. Can this really be true? The reason is that from 2.4.0.0 onwards, it requires base <=4.13, and 8.8 uses base-4.13. Oddly, 2.2.0.0 claims support up to base 5, but actually not, because it also requires stm <2.5, and 8.8 uses stm 2.5, and it's a bootlib. I thought maybe the new nix-style build was supposed to no longer require version matches for bootlibs, but since `cabal v2-configure` fails I guess it must still have that requirement. In any case, my understanding is that linking to different versions of bootlibs isn't a good idea anyway, because once you have a dependency on the ghci api you're stuck. I looked into how nixpkgs builds cabal-install, and it looks like it disables version constraints, pulls a patch for hackage-security from hvr's personal github. So it is buildable, if you apply custom patches. Of course in the limit that's true of everything! I guess we don't need source builds to work as long as someone somewhere can figure out how to do the build and upload a binary, so I downloaded the pre-built binary of 3.0.0.0 from https://www.haskell.org/cabal/download.html, and it seemed to work at first. However, it couldn't build a particular package, and when I tried to download and `cabal configure` it, I got a version conflict which was not very clear, but the important line seems to be this: [__1] rejecting: hlibgit2:setup.Cabal-3.0.1.0/installed-3.0..., hlibgit2:setup.Cabal-3.0.0.0, hlibgit2:setup.Cabal-2.4.1.0, hlibgit2:setup.Cabal-2.4.0.1, hlibgit2:setup.Cabal-2.4.0.0 (conflict: hlibgit2 => hlibgit2:setup.Cabal>=1.10 && <1.25) My best guess about what this means is that, while hlibgit2 has no explicit dependency on Cabal (the library), it does have a Setup.hs, which imports Distribution.Simple, and perhaps this creates a dependency, and the ghc 8.8.3 has `Cabal-3.0.1.0` while cabal-install was compiled against `Cabal-3.0.0.0`, and I vaguely remember if you use a cabal-install whose Cabal version doesn't match the Cabal version of the ghc you are using, it will appear to work, until it doesn't, and then things will crash with confusing errors, or rebuild constantly, or do something bad. But of course I can't compile cabal-install against Cabal-3.0.1.0 because I can't build it at all. Maybe it actually is important for source builds to work! It looks like I could downgrade to 8.8.1 and maybe things would work. Is this really the situation? If it's not, where did I go wrong? If it is, how can we fix it? Provided people agree it's a problem, but if not, why not? I seem to recall that just about every ghc release has had this kind ghc-Cabal-cabal-install synchronization problem, and it's one of the reasons I wait 6 months or so before upgrading. But of course that's not good for me or for ghc, because then I'm reporting the bugs rather late.

1 0