- Glasgow-haskell-users

The dreaded windows path length issue
by Erik de Castro Lopo 30 May '18

30 May '18

Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1

Natural number comparisons with evidence
by Conal Elliott 24 May '18

24 May '18

When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > data CompareEv u v > = (u < v) => CompareLT > | (u ~ v) => CompareEQ > | (u > v) => CompareGT Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v With `compareEv`, we can bring evidence into scope in `case` expressions. I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > LT -> CompareLT > EQ -> CompareEQ > GT -> CompareGT Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? Thanks, -- Conal

5 10

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 21 May '18

21 May '18

On Wed, 9 May 2018 03:01 UTC, cheater00 wrote: > I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out Yes absolutely. To be clear: nobody's talking about removing it. The question is, could we get the same functionality without being so confusing and contrary to how Haskell usually works with type variables? (I'm not saying yea or nay, I'm trying to invite discussion.) > ... > Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc? The current design for ScopedTypeVariables potentially changes the types for programs that are valid H98/H2010. (Or for programs that were valid as at when ScopedTypeVariables was introduced ~10 years ago, perhaps using ExplicitForAll.) Probably the effect would be that they don't compile, but it might be more subtle. So the explanation I've seen for the current design is it was deliberately idiosyncratic, to minimise any disruption to existing code. Then I'm asking whether any of that code is still around? If not/if it's been re-factored to use ScopedTypeVariables, then any tweak to the design could have a freer hand. But seems there's no enthusiasm for such discussion, so I'm going to let it die. I hear there might be moves afoot elsewhere ... AntC

3 5

PSA for Cabal 2.2 new-* users regarding .ghc.environment files
by Gershom B 13 May '18

13 May '18

There is an important change in the cabal new- commands for 2.2 that the release docs should have highlighted more significantly. Cabal new-* commands now produce a .ghc.environment file by default. These files [1] are picked up by ghc and ghci automatically (since 8.0.1), and allow them to operate directly with the same package environment used by the new-* commands. This lets you, for example, run `ghci` in a project where you are using `new-build` and get the proper dependencies in scope. Herbert has written an experimental tool to make it easier to create and manipulate these environments [2]. However: there is a drawback (on which some discussion at [3] and [4]. In particular, there is not good information provided by ghc about when these files are picked up and used. So if you are admixing new-* commands and other commands for the time being, jumping between the two, or admixing ghc and ghcjs, etc., then you may run into unexpected behavior! [5] The simplest solution for now is to delete the local .ghc.environment file in those cases (i.e. where you're mixing commands and get unexpected behavior). A particular gotcha is that these files are picked up not just in the current directory but also in any parent directory. Cheers, Gershom [1] documented at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.ht… [2] https://github.com/hvr/cabal-env [3] https://github.com/haskell/cabal/issues/4542 [4] https://ghc.haskell.org/trac/ghc/ticket/13753 [5] Error messages may be like ".cabal/store/ghc-8.0.2/package.db/package.cache: openBinaryFile: does not exist (No such file or directory)" or complaints about missing inplace dependencies.

3 2

Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 09 May '18

09 May '18

This thread is a discussion about discussions, not the discussion itself ;-) I'm cc'ing to the cafe; but I'd prefer replies to come to glasgow-haskell-users. >> I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) > ... don’t care what forums or list or whatever. As long as it’s collated and such > It could even be on the prime issue tracker for prime proposals. Just that it’s written down :) Thanks Carter, but I understand Haskell Prime to be to assess mature/stable proposals (preferably already delivered as extensions). This discussion is at first going to be more exploratory: * likes and dislikes about ScopedTypeVariables as currently. * confusions experienced by users (especially newbies) -- although absolute newbies wouldn't be using it(?), so intermediates? * feedback from those teaching Haskell. * wild ideas for possible alternative designs. * possible improvements to the current design. * I think we're all agreed that ScopedTypeVariables should have been in Haskell from the beginning; but it wasn't, so now we have to worry about backwards compatibility for programs that worked around the omission. Or do we? What code would break? How much pain would that cause? * anything else? > We have lots of forums, but your point is that certain sorts of discussions never get going with the right audience – you especially point to “confused beginners”. > ... It’s quite a challenge because beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. On this particular topic, there's plenty of confused people asking questions on StackOverflow. (Heads up: they're especially asking why they need explicit `forall` whereas in reguar Haskell that 'intermediates' see, the forall is implicit.) Can other people point me to questions/likes/dislikes on other forums? Reddit for example. If you've read this far, you now understand what we're trying to cover. It's going to be random/varied thoughts at first, then perhaps coalescing to an approach or two. At that point a formal proposal on github proper; and the random stuff might be interesting background but will essentially get archived/thrown away. I do agree with David's suggestion that github Issue tracker looks like a suitable solution. We can write formatted code and text. We can add links and references. What do others think? Joachim has opened up Issues tracker, as a try-out. If using it doesn't work out, that's fine and in keeping with my "thrown away" above. Also where else should I post links to this message to 'advertise' the thread? I don't reddit much, so if that's suitable, please someone post there. Thank you AntC

2 1

Re: Open up the issues tracker on ghc-proposals
by Anthony Clayden 05 May '18

05 May '18

> On May 1, 2018, at 2:24 PM, David Feuer <david.feuer at gmail.com> wrote: > > Sometimes, a language extension idea could benefit from some community discussion before it's ready for a formal proposal. Can I point out it's not only ghc developers who make proposals. I'd rather you post this idea more widely. As a datapoint, I found ghc-users and the café just fine for those discussions. Ghc-users seems to have very low traffic/is rather wasted currently. And I believe a lot of people pre-discuss on reddit. For ideas that have been on the back burner for a long time, there's often wiki pages. (For example re Quantified Constraints.) > I'd like to propose that we open up the GitHub issues tracker for ghc-proposals to serve as a place to discuss pre-proposal ideas. Once those discussions converge on one or a few specific plans, someone can write a proper proposal. I'm not against that. There gets to be a lot of cruft on some discussions about proposals, so I'd expect we could archive it all once a proposal is more formalised. AntC

5 8

[ANNOUNCE] GHC 8.4.2 released
by Ben Gamari 01 May '18

01 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.2. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.2 This release is a bug-fix release, fixing numerous regressions and bugs present in GHC 8.4.1. These include: * A regression resulting in some uses of `Control.Exception.evaluate` to be inappropriately optimised away (see #13930) * A regression resulting in segmentation faults of programs compiled with profiling (#14705) * A bug causing runtime system panics while running programs with retainer profiling (#14947) * The configure scripts now accepts a `--disable-dtrace` option, again allowing GHC to be bootstrapped on FreeBSD (#15040) * The version number of the `base` package has been bumped to 4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type. This interface was added in 8.4.1 but the version bump was missed due to an oversight. * Support for DWARF debug information has been significantly improved (#14894, #14779) A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Accessing 'Annotations' of modules in external packages
by Ranjit Jhala 20 Apr '18

20 Apr '18

Hi all, I'm looking for some help using the GHC API to access the 'Annotations' (created using the 'ANN' mechanism) within modules of *external* packages i.e. non-home modules.Currently I'm using hscEPS :: HscEnv -> IO ExternalPackageState and then using the field eps_PIT :: !PackageIfaceTable and from there, accessing the mi_anns :: [IfaceAnnotation] field of the data ModIface stored in the PackageIfaceTable but this ends in an unfortunate: ``` panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): No mi_anns in PIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ``` Perhaps this is because, as the documentation for `mi_anns` says: Annotations NOT STRICT! we read this field lazily from the interface file but I am not sure how to proceed at this point? Do I need a _different_ HscEnv? Or perhaps I need to set up/initialize the HscEnv separately? Any pointers would be most welcome! Thanks! Ranjit.

2 1

.ghci runs after flag parsing?
by Evan Laforge 05 Apr '18

05 Apr '18

I just noticed that it appears flag parsing happens before executing .ghci. And sure enough, looking at the source, GHCi.UI.runGHCi executes the dot files, which is definitely after all the dynflags parsing stuff in Main. This means that if your .ghci has a -Wall, you can't turn off warnings from the command line. You have to prepend ":set " to the flags and make a local ./.ghci, or pass -ghci-script. I assume this has how it's already been, and I'm surprised it's taken me this long to notice this! Is there a good reason to do it this way, or is it just the way it's always been and no one complained? It's surprising to me because I think most programs do it the other way. E.g. when you start your shell, settings on the command line will override your .zshrc or whatever. zsh for one doesn't seem to clearly document this, but experimenting seems to indicate that is so. I can put all my flags in a -ghci-script without too much trouble, it's just a surprising default.

1 0

8.4.1 ghci findings
by Evan Laforge 23 Mar '18

23 Mar '18

I just filed this bug: #14963: ghci -fdefer-type-errors can't run IO action from another module https://ghc.haskell.org/trac/ghc/ticket/14963 It seems like -fdefer-type-errors and ghci just don't get along at all now. But on the good news side, ghci reloading a changed module in 8.4.1 is much much faster than 8.0.2. I don't know who did that, but good work! Reload being instant instead of having to wait a second or so makes a big difference.

1 0