- ghc-devs - Haskell.org

Possible unpackFS problem
by Alan & Kim Zimmerman 10 Jan '15

10 Jan '15

While doing further round-trip testing, I cam across the following issue Original source module Deprecation {-# Deprecated ["This is a module \"deprecation\"", "multi-line"] #-} ( foo ) where Pretty-printed AST via ppr (L {examples/Deprecation.hs:(3,1)-(4,30)} (DeprecatedTxt (L {examples/Deprecation.hs:3:1-14} "{-# Deprecated") [ (L {examples/Deprecation.hs:3:17-50} {FastString: "This is a module \"deprecation\""}), (L {examples/Deprecation.hs:4:14-25} {FastString: "multi-line"})]))) output where the FastString is converted to a string via unpackFS module Deprecation {-# Deprecated ["This is a module "deprecation"", "multi-line"] #-} ( foo ) where So, the ppr (via Pretty.ftext) is able to reproduce the escape characters in original string, but unpackFS does not. Is this a problem for anyone else? Regards Aan

1 1

How to get notifications when a build fails?
by Eric Seidel 10 Jan '15

10 Jan '15

Hi devs, Is there any way to make Phab email you when a revision you've submitted fails to build? I looked through the settings but couldn't find anything that seems to fit the bill. Thanks! Eric

1 0

Milestones
by David Feuer 09 Jan '15

09 Jan '15

I took the liberty of pushing back the milestones for a few tickets that looked unlikely to be acted on for 7.10.1, based on a combination of severity, recent activity, and perceived intrusiveness. If anyone objects, please move them back. #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page #8440: Get rid of the remaining static flags #8634: Relax functional dependency coherence check ("liberal coverage condition") David

1 0

pef T3294
by Simon Peyton Jones 09 Jan '15

09 Jan '15

perf/compiler T3294 [stat not good enough] (normal) This test is failing on Phab all the time now. but it doesn't fail on my machine, so I can't see what's wrong. Could someone look? Simion

1 0

Shipping core libraries with debug symbols
by Johan Tibell 09 Jan '15

09 Jan '15

Hi! We are now able to generate DWARF debug info, by passing -g to GHC. This will allow for better debugging (e.g. using GDB) and profiling (e.g. using Linux perf events). To make this feature more user accessible we need to ship debug info for the core libraries (and perhaps the RTS). The reason we need to ship debug info is that it's difficult, or impossible in the case of base, for the user to rebuild these libraries.The question is, how do we do this well? I don't think our "way" solution works very well. It causes us to recompile too much and GHC doesn't know which "ways" have been built or not. I believe other compilers, e.g. GCC, ship debug symbols in separate files ( https://packages.debian.org/sid/libc-dbg) that e.g. GDB can then look up. -- Johan

4 12

Deprecating functions
by Jan Stolarek 09 Jan '15

09 Jan '15

I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error: #if __GLASGOW_HASKELL__ > 712 #error Remove functions foo bar from TH #endif Is this a good way of doing this? Or should I do it differently? Janek

7 16

warn-redundant-constraints present as errors
by Alan & Kim Zimmerman 09 Jan '15

09 Jan '15

This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word "warning" in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t => [GHC.LHsBind GHC.Name] -> t -> GHC.Name -> GHC.Name -> RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word "Warning" to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan

4 9

Redundant constraints
by Simon Peyton Jones 09 Jan '15

09 Jan '15

Friends I've pushed a big patch that adds -fwarn-redundant-constraints (on by default). It tells you when a constraint in a signature is unnecessary, e.g. f :: Ord a => a -> a -> Bool f x y = True I think I have done all the necessary library updates etc, so everything should build fine. Four libraries which we don't maintain have such warnings (MANY of them in transformers) so I'm ccing the maintainers: o containers o haskeline o transformers o binary Enjoy! Simon

6 10

linker_unload
by Simon Peyton Jones 08 Jan '15

08 Jan '15

I'm getting this for test linker_unload on Linux. I'm sure it's not my fault! But it makes validate fail Simon Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Error 1 *** unexpected failure for linker_unload(normal)

6 18

Windows build gotchas
by Martin Foster 08 Jan '15

08 Jan '15

Hello all, I've been spending some of my winter break trying my hand at compiling GHC, with a mind to hopefully contributing down the line. I've got it working, but I ran into a few things along the way that I figure might be worth fixing and/or documenting. In the approximate order I encountered them: - The first pacman mirror on the list bundled with MSYS2 is down, with the result that every download pacman makes takes ~10sec longer than it should. It downloads a lot, so that really adds up - but it's easy to fix, just "pacman -Sy pacman-mirrors" before doing anything else with it. Is that worth mentioning on the wiki? I was thinking a line on https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows could be helpful. - That page mentions "If you see errors related to fork(), try closing and reopening the shell" - I've determined that you can reliably avoid that problem by following the instructions at http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/#iii-updating-pack…, ie by running "pacman --needed -S bash pacman msys2-runtime", then closing & re-opening the MSYS shell, before you tell pacman to install the GHC prerequisite packages. - A minor point: I found it helpful to include "man-db" in the list of packages to install - without it, "git help" breaks down with " failed to exec 'man'". - I note "./sync-all --help" says, under "Flags", that "--windows also clones the ghc-tarballs repository (enabled by default on Windows)", and I've confirmed that default behaviour experimentally - but https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources tells you to manually clone ghc-tarballs when on Windows. Is that line on the wiki obsolete, or am I overlooking something? - And finally, the big one: cabal and/or ghc-pkg put some files outside the MSYS root directory, and caused me no end of trouble in doing so... I made a bit of a mess at one point, and tried to fix it by starting over completely from scratch. I expected uninstalling & reinstalling MSYS to achieve this (it deletes its root directory when you uninstall it), but that left me with a huge pile of errors when I tried to run "cabal install -j --prefix=/usr/local alex happy", of the form "Could not find module `...': There are files missing in the `...' package". I noticed that the cabal output made reference to "C:\Users\Martin\AppData\Roaming\cabal\", so tried moving that out of the way, but it only made the problem worse. I did figure it out eventually: in addition to that directory, "%APPDATA%\cabal", there were also files left over in "%APPDATA%\ghc". Once I removed that directory as well, things started working again - but it took me a lot of time & frustration to get there. I'm not entirely sure, but I think the copy of Cabal I already had from installing the Platform may also have been storing files in those directories, in which case this process completely mangled them - which isn't great. It seems to me that, ideally, the "build GHC inside MSYS" procedure would keep itself entirely inside the MSYS directory structure: if it were wholly self-contained, you'd know where everything is, and it couldn't break anything outside. As far as I can tell, the only breach is those two directories courtesy of Cabal, so I didn't think it would be too difficult - but none of the things I've tried (the --package-db cabal flag, a custom cabal --config-file, setting the GHC_PACKAGE_PATH environment variable, maybe some others I've forgotten) had the desired effect. Is it possible? Is it even a good idea? If that's just how it has to be, I feel like there should be an obvious note somewhere for the sake of the next person to trip over it. I'd be happy to amend the wiki for any/all of the first four points, if people think it'd be appropriate; I'm not sure at all what to do about the last one. Any thoughts? - Martin

3 3