- Glasgow-haskell-users

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

Re: [ANNOUNCE] GHC 8.8.3 is now available
by Ben Gamari 29 Feb '20

29 Feb '20

Ben Gamari <ben(a)well-typed.com> writes: > --text follows this line-- > <#part sign=pgpmime> > > Hello everyone, > > The GHC team is proud to announce the release of GHC 8.8.3. The source > distribution, binary distributions, and documentation are available at > > https://downloads.haskell.org/~ghc/8.8.3 > > Release notes are also available [1]. > Unfortunately there has been a slight mix-up in the binary distributions associated with this release and I will need to do a re-spin. I have pulled down the binary distributions for the time being. They should be back in a few hours. Many apologies for the confusion! Cheers, - Ben

2 2

[ANNOUNCE] GHC 8.8.2 is now available
by Ben Gamari 25 Feb '20

25 Feb '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.2. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.2 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.1: - A bug (#17088) in the compacting garbage collector resulting in segmentations faults under specific circumstances. Note that this may affect user programs even if they did not explicitly request the compacting GC (using the -c RTS flag) since GHC may fallback to compacting collection during times of high memory pressure. - A code generation bug (#17334) resulting in GHC panics has been fixed. - A bug in the `process` library causing builds using `hsc2hs` to fail non-deterministically on Windows has been fixed (Trac #17480) - A typechecker bug (#12088) resulting in programs being unexpectedly rejected has been fixed. - A bug in the implementation of compact normal forms resulting in segmentation faults in some uses (#17044) has been fixed. - A bug causing GHC to incorrectly complain about incompatible LLVM versions when using LLVM 7.0.1 has been fixed (#16990). As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.2/docs/html/users_guide/8.8.2-notes.h…

2 3

[ANNOUNCE] Glasgow Haskell Compiler 8.10.1-rc1 released
by Ben Gamari 26 Jan '20

26 Jan '20

Hello all, The GHC team is happy to announce the availability of the first release candidate of GHC 8.10.1. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.1-rc1/ GHC 8.10.1 will bring 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 This is the first and likely final release candidate. For a variety of reasons, it comes a few weeks later than the original schedule of release late December. However, besides a few core libraries book-keeping issues this candidate is believed to be in good condition for the final release. As such, the final 8.10.1 release will likely come in two weeks. 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`. In addition, we are still looking for any Alpine Linux to help diagnose the correctness issues in the Alpine binary distribution [1]. If you use Alpine any you can offer here would be greatly appreciated. Please do test this release and let us know if you encounter any other issues. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 [2] https://gitlab.haskell.org/ghc/ghc/issues/17418

4 3

GHC Full Bootstrap from Source on macOS
by Steven Smith 19 Jan '20

19 Jan '20

Is there a guide or script to build ghc from source (not the prebuilt binary)? At MacPorts we’re running into issues on macOS Catalina 10.15 with the bootstrapped-from-prebuilt ghc. See https://trac.macports.org/ticket/59467 . It would preferable and probably more robust to be able to bootstrap everything from source, and highly preferable to be able to do this with a clang compiler of choice.

1 0