From ben at well-typed.com Tue Feb 6 16:43:10 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 06 Feb 2018 11:43:10 -0500 Subject: [ANNOUNCE] GHC 8.4.1-alpha3 available Message-ID: <87d11iyspz.fsf@smart-cactus.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From anthony_clayden at clear.net.nz Mon Feb 12 07:21:32 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 12 Feb 2018 20:21:32 +1300 Subject: Quantified Constraints and Injectivity Message-ID: 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/026650.html [6] https://ghc.haskell.org/trac/ghc/ticket/10675 AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Feb 12 23:45:07 2018 From: david.feuer at gmail.com (David Feuer) Date: Mon, 12 Feb 2018 18:45:07 -0500 Subject: unsafeCoerce shenanigans Message-ID: 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 From gale at sefer.org Tue Feb 13 10:04:55 2018 From: gale at sefer.org (Yitzchak Gale) Date: Tue, 13 Feb 2018 12:04:55 +0200 Subject: GHC 8.2.2 for WSL Ubuntu 16.04 64 bit Message-ID: 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 From matt.g.d.walker at gmail.com Tue Feb 13 21:50:10 2018 From: matt.g.d.walker at gmail.com (Matt Walker) Date: Tue, 13 Feb 2018 16:50:10 -0500 Subject: GHC for Plugins Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Feb 25 17:42:15 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 25 Feb 2018 12:42:15 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available Message-ID: <87po4trmr3.fsf@smart-cactus.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Sun Feb 25 19:57:58 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 25 Feb 2018 14:57:58 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <87po4trmr3.fsf@smart-cactus.org> References: <87po4trmr3.fsf@smart-cactus.org> Message-ID: <87k1v0suyk.fsf@smart-cactus.org> Ben Gamari writes: > 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. > It has come to my attention that the fix for #14675 has broken `configure`'s `--disable-ld-override` flag. I have a fix [1] which will be applied to the final release. In the meantime, if you need to use this flag please define the `LD_NO_GOLD` environment variable to point to a non-gold linker when invoking `configure`. For instance, ./configure --disable-ld-override LD_NO_GOLD=ld.bfd Cheers, - Ben [1] https://phabricator.haskell.org/D4448 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Feb 26 16:01:59 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Feb 2018 11:01:59 -0500 Subject: [ANNOUNCE] GHC 8.4.1-rc1 available In-Reply-To: <881c4581-eaae-009a-626b-024f29d0a010@snarc.org> References: <87po4trmr3.fsf@smart-cactus.org> <881c4581-eaae-009a-626b-024f29d0a010@snarc.org> Message-ID: <87a7vvspsc.fsf@smart-cactus.org> Vincent Hanquez 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From varosi at gmail.com Wed Feb 28 12:17:23 2018 From: varosi at gmail.com (Vassil Ognyanov Keremidchiev) Date: Wed, 28 Feb 2018 14:17:23 +0200 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project Message-ID: 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Feb 28 15:32:27 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Feb 2018 10:32:27 -0500 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project In-Reply-To: References: Message-ID: <87k1uxqge2.fsf@smart-cactus.org> Vassil Ognyanov Keremidchiev writes: > 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. > Thanks for doing these tests! I have opened #14870 to make sure we don't lose track of this. It would be interesting to bisect this to see where we went off the rails. This is a very interesting example which the Cabal file says is in the public domain. In principle it would be a nice case to include in nofib, although I suspect it has few too many dependencies. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Wed Feb 28 15:47:57 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 28 Feb 2018 10:47:57 -0500 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project In-Reply-To: <87k1uxqge2.fsf@smart-cactus.org> References: <87k1uxqge2.fsf@smart-cactus.org> Message-ID: I don't see how 62 seconds rather than 60 is anything close to going off the rails. Did I read something wrong? This sounds more like a minor wibble. On Feb 28, 2018 10:32 AM, "Ben Gamari" wrote: > Vassil Ognyanov Keremidchiev writes: > > > 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. > > > Thanks for doing these tests! I have opened #14870 to make sure we don't > lose track of this. It would be interesting to bisect this to see where > we went off the rails. > > This is a very interesting example which the Cabal file says is in the > public domain. In principle it would be a nice case to include in nofib, > although I suspect it has few too many dependencies. > > Cheers, > > - Ben > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varosi at gmail.com Wed Feb 28 17:22:11 2018 From: varosi at gmail.com (Vassil Ognyanov Keremidchiev) Date: Wed, 28 Feb 2018 19:22:11 +0200 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project In-Reply-To: References: <87k1uxqge2.fsf@smart-cactus.org> Message-ID: Those numbers are averaged from 5-10 runs. So there is some slow down for some reason. It's not great and it's just 3%. But I hoped that 8.4 has more optimizations and will lead to better performance and not worse. 2018-02-28 17:47 GMT+02:00 David Feuer : > I don't see how 62 seconds rather than 60 is anything close to going off > the rails. Did I read something wrong? This sounds more like a minor wibble. > > On Feb 28, 2018 10:32 AM, "Ben Gamari" wrote: > >> Vassil Ognyanov Keremidchiev writes: >> >> > Hello! >> > >> > I have a small ray-tracer project: https://bitbucket.org/varosi/c >> graytrace >> > From time to time I'm testing it with different GHC versions including >> ARM. >> > >> Thanks for doing these tests! I have opened #14870 to make sure we don't >> lose track of this. It would be interesting to bisect this to see where >> we went off the rails. >> >> This is a very interesting example which the Cabal file says is in the >> public domain. In principle it would be a nice case to include in nofib, >> although I suspect it has few too many dependencies. >> >> Cheers, >> >> - Ben >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From varosi at gmail.com Wed Feb 28 17:23:27 2018 From: varosi at gmail.com (Vassil Ognyanov Keremidchiev) Date: Wed, 28 Feb 2018 19:23:27 +0200 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project In-Reply-To: References: <87k1uxqge2.fsf@smart-cactus.org> Message-ID: The project could be stripped off yesod package which bring a lot dependencies with it. In cgraytrace-exe I don't use Yesod at all. 2018-02-28 19:22 GMT+02:00 Vassil Ognyanov Keremidchiev : > Those numbers are averaged from 5-10 runs. So there is some slow down for > some reason. It's not great and it's just 3%. But I hoped that 8.4 has more > optimizations and will lead to better performance and not worse. > > 2018-02-28 17:47 GMT+02:00 David Feuer : > >> I don't see how 62 seconds rather than 60 is anything close to going off >> the rails. Did I read something wrong? This sounds more like a minor wibble. >> >> On Feb 28, 2018 10:32 AM, "Ben Gamari" wrote: >> >>> Vassil Ognyanov Keremidchiev writes: >>> >>> > Hello! >>> > >>> > I have a small ray-tracer project: https://bitbucket.org/varosi/c >>> graytrace >>> > From time to time I'm testing it with different GHC versions including >>> ARM. >>> > >>> Thanks for doing these tests! I have opened #14870 to make sure we don't >>> lose track of this. It would be interesting to bisect this to see where >>> we went off the rails. >>> >>> This is a very interesting example which the Cabal file says is in the >>> public domain. In principle it would be a nice case to include in nofib, >>> although I suspect it has few too many dependencies. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Feb 28 19:22:06 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 28 Feb 2018 14:22:06 -0500 Subject: GHC 8.4.1-rc1 is slower on a ray-tracer project In-Reply-To: References: <87k1uxqge2.fsf@smart-cactus.org> Message-ID: <87fu5krkbq.fsf@smart-cactus.org> David Feuer writes: > I don't see how 62 seconds rather than 60 is anything close to going off > the rails. Did I read something wrong? This sounds more like a minor wibble. > "Off the rails" was a rhetorical flourish; indeed a single program regressing by 3% isn't a catastrophe. That being said, runtime performance improvements are hard-won prizes. Consider that the largest allocations improvement arising from the "Compiling without Continuations" paper was ~8%. Consequently, if someone comes along with a 3% regression we would remiss not to take it seriously. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: