February 2018 - Glasgow-haskell-users

GHC 8.4.1-rc1 is slower on a ray-tracer project
by Vassil Ognyanov Keremidchiev 28 Feb '18

28 Feb '18

Hello! I have a small ray-tracer project: https://bitbucket.org/varosi/cgraytrace >From time to time I'm testing it with different GHC versions including ARM. Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my Intel Core i7 machine on Windows 10 x64. I got this results: GHC 8.4.1-rc1 Average time: 61.87s GHC 8.2.2 Average time: 60.09s GHC 8.0.2 Average time: 67.07s Application is doing multi-threaded brute-force ray-tracing with GI, so a lot of rays are shot around. It seems that previous GHC 8.2.2 is doing better on a high-performance application. I know that this test is too simple, but it is on a real world problem and application and not one for whole purpose of benchmarking. Any thoughts are welcome!

3 5

Re: [ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 26 Feb '18

26 Feb '18

Vincent Hanquez <tab(a)snarc.org> writes: > On 25/02/18 17:42, Ben Gamari wrote: >> The GHC development team is pleased to announce the first (and likely >> final) release candidate of GHC 8.4.1. The usual release artifacts are >> available from >> >> https://downloads.haskell.org/~ghc/8.4.1-rc1 >> > Hi Ben, > > Looks like both SHA1SUM and SHA256SUM are missing the fedora27 variant > Good catch; it looks like I neglected to regenerate them after fixing the name of the the Fedora vairant. Fixed. Cheers, - Ben

1 0

[ANNOUNCE] GHC 8.4.1-rc1 available
by Ben Gamari 25 Feb '18

25 Feb '18

The GHC development team is pleased to announce the first (and likely final) release candidate of GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-rc1 This release will likely be the last release before the final 8.4.1 release, which, if things go well, will be released one week from today. Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release candidate is still affected by #14705, although this will certainly be resolved before the final release is made. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

1 1

GHC for Plugins
by Matt Walker 13 Feb '18

13 Feb '18

Hello, I am developing a game and would like to write the core in haskell with haskell also for scripting. I like haskell. I have the following file to help me do this. >>> BEGIN FILE {-# LANGUAGE ScopedTypeVariables #-} module Plugin.Load where import Data.Functor import System.Directory import GHC import GHC.Paths import DynFlags import Unsafe.Coerce type ModName = String type ValName = String loadPlugin :: FilePath -> ModName -> ValName -> IO a loadPlugin dir modName value = do withCurrentDirectory dir $ defaultErrorHandler defaultFatalMessager defaultFlushOut $ runGhc (Just libdir) $ do dynFlags <- getSessionDynFlags setSessionDynFlags $ dynamicTooMkDynamicDynFlags $ dynFlags { importPaths = [modName] ++ importPaths dynFlags , hscTarget = HscAsm , ghcLink = LinkInMemory , ghcMode = CompManager } sequence [guessTarget modName Nothing] >>= setTargets load LoadAllTargets setContext [IIDecl $ simpleImportDecl $ mkModuleName modName] fetched <- compileExpr (modName ++ "." ++ value) return (unsafeCoerce fetched :: a) <<< END FILE The problem is that if I run the function loadPlugin on the same input more than once, GHC barfs. The error I get is: /usr/bin/ld.gold: error: cannot find -lghc_5 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** Exception: ExitFailure 1 sometimes it's -lghc_2 or -lghc_13 above. Anyways, it seems like I and/or ghc isn't cleaning up properly after themself and then wants to try to append numbers. Any idea what is causing this and how to fix it? Thanks, Matt PS. is there a better way of doing this using Typeable? I'd rather not unsafeCoerce.

1 0

GHC 8.2.2 for WSL Ubuntu 16.04 64 bit
by Yitzchak Gale 13 Feb '18

13 Feb '18

I have made available a build of GHC 8.2.2 with the config option: --disable-large-address-space You may find this useful if you are using Ubuntu 16.04 on Windows Subsystem for Linux. https://github.com/zoominsoftware/ghc-8.2.2-wsl Although Microsoft has been making gradual progress on the large address mapping issue[1][2], and the situation is much improved, there is still an extra startup latency of about 13 secs. for applications that pre-map a large address space as GHC does by default. This makes the standard GHC binary unusable for compiling projects of any non-trivial size. WSL is now out of beta. It can be enabled on any computer running Windows 10. Almost all 64-bit linux binaries run fine out of the box on WSL. GHC is unfortunately an exception, due to its large address space mapping behavior. WSL is extremely useful as a development platform, except for this annoyance for Haskell developers. Could we consider providing binary installers with --disable-large-address-space as an official part of our releases? It seems that it would take very little extra work to do so: just run the build for latest Debian twice, once as usual and once with --disable-large-address-space. Is there anything I could do to help? Thanks, Yitz [1] https://ghc.haskell.org/trac/ghc/ticket/13304 [2] https://github.com/Microsoft/WSL/issues/1671

1 0

unsafeCoerce shenanigans
by David Feuer 12 Feb '18

12 Feb '18

Suppose I have a function of type unionWith# :: (Hashable k, Eq k) => (a -> a -> (# a #)) -> HashMap k a -> HashMap k a -> HashMap k a I can use this to implement strict and lazy unions with practically no code duplication either in source or in generated code: S.unionWith, L.unionWith :: (Hashable k, Eq k) => (a -> a -> a) -> HashMap k a -> HashMap k a -> HashMap k S.unionWith f = unionWith# (\a b -> let !r = f a b in (# r #)) L.unionWith f = unionWith# (\a b -> (# f a b #)) Semantically, this gets the job done, but there's a potential performance problem. If the function passed to either version of unionWith fails to inline, then we'll build a closure to interface with the underlying function. This is not so great, because it adds indirection in a likely hot spot. I'm not too terribly worried about the lazy version, because it's prone to leaking memory anyway, but I do care about the strict version. It seems to me that for the *strict* version, I can probably use unsafeCoerce to do the job instead: S.unionWith f = unionWith# (unsafeCoerce f) When unionWith# applies f to values, it will get back something that it *thinks* might be a thunk, but actually will never be a thunk. We don't really care, especially because we just stick it into a lazy constructor field. My main concern is that this is obviously not at all an officially supported way to use unsafeCoerce. What are the chances that GHC will do something that breaks it? If I can't do this reliably, I should still be able to use unionWith# to reduce *source* size, relying on lots of inlining to avoid closures, but the generated code would stay large. David

1 0

Quantified Constraints and Injectivity
by Anthony Clayden 12 Feb '18

12 Feb '18

I’m looking at the flurry of activity around Quantified Constraints [1, 2, 3], suggestion of uses for implication logic [4], and comments in the hs2017 paper “raise the expressive power of type classes … to first-order logic. … more expressive modelling …”[Abstract]. Consider modelling the logic for somewhat-injective type functions. Take type-level Boolean `And` [5]. `And` is not fully injective but: * If the result is True, the two arguments must be True. * If the result is False and one argument is True, the other must be False. class ( b3 ~ True => (b1 ~ True, b2 ~ True), (b3 ~ False, b1 ~ True) => b2 ~ False ) -- etc => And (b1 :: Bool) (b2 :: Bool) (b3 :: Bool) | b1 b2 -> b3 where … None of this is relying on `Bool` being a closed type AFAICT. (That’s the usual downfall of trying to capture application logic in constraints.) Come to that, can we capture the logic of the FunDep? (The hs2017 paper hints we might.) class ( {- as before -}, ( forall b3’. And b1 b2 b3’ => b3’ ~ b3 ) ) => And (b1 :: Bool) (b2 :: Bool) (b3 :: Bool) | b1 b2 -> b3 where … This might come closer to the logic of FunDeps as originally specified by Mark P Jones, which ghc doesn’t quite reach to [6]. OTOH we now have a cyclical superclass constraint, which ain’t allowed. [1] https://github.com/ghc-proposals/ghc-proposals/pull/109 [2] https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints [3] https://ghc.haskell.org/trac/ghc/ticket/2893 [4] https://mail.haskell.org/pipermail/libraries/2017-December/028377.html [5] https://mail.haskell.org/pipermail/ghc-devs/2017-November/015073.html, continued at https://mail.haskell.org/pipermail/glasgow-haskell-users/2017-November/0266… [6] https://ghc.haskell.org/trac/ghc/ticket/10675 AntC

1 0

[ANNOUNCE] GHC 8.4.1-alpha3 available
by Ben Gamari 06 Feb '18

06 Feb '18

The GHC development team is pleased to announce the third and likely last alpha release leading up to GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha3 Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release is still affected by #14675, wherein the compiler will segmentation fault when built with some Ubuntu toolchains. We are actively working to identify the cause and hope that this will be resolved before the final release. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

1 0