- ghc-devs - Haskell.org

warnings
by Simon Peyton Jones 27 Jul '15

27 Jul '15

Yurgh. I committed a patch but my validate had -Wwarn by mistake. So there are warnings in base (and binary actually). I will sort them out tomorrow. Could revert and re-apply but doesn't seem worth it. Sorry Simon

1 0

TypeLits and type families wrt. equality
by Gabor Greif 27 Jul '15

27 Jul '15

Hi all! I have a problem with following disconnect: equalities for types as detectable by type families, while I am missing a convincing technique to do the same at the value level. (convincing means here: without resorting to unsafeCoerce) Here is a demo snippet illustrating the issue. Try to get the commented line to compile without using unsafeCoerce. ############################################################## {-# LANGUAGE DataKinds, GADTs, TypeOperators , KindSignatures, ScopedTypeVariables, TypeFamilies #-} import Data.Type.Equality import GHC.TypeLits import Data.Proxy data Path (names :: [Symbol]) where Empty :: Path '[] Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ': names) type family StripOut (name :: Symbol) (path :: [Symbol]) where StripOut name '[] = '[] StripOut name (name ': ns) = StripOut name ns StripOut n (name ': ns) = n ': StripOut name ns stripOut :: KnownSymbol name => Proxy name -> Path names -> Path (StripOut name names) stripOut _ Empty = Empty stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n path --stripOut n (Longer n' path) = Longer n' (stripOut n path) ############################################################## I get the error reproduced at the end of this message. My suspicion is that we need to model type inequality (with a new built-in eliminator, perhaps?) that helps us to skip the equation "StripOut name (name ': ns) = StripOut name ns" in the case when sameSymbol would return Nothing. Any ideas? Cheers and thanks Gabor ----------------------------------------------------- Lits.hs:20:31: error: Could not deduce: StripOut name (name1 : names1) ~ (name1 : StripOut name names1) from the context: (names ~ (name1 : names1), KnownSymbol name1) bound by a pattern with constructor: Longer :: forall (name :: Symbol) (names :: [Symbol]). KnownSymbol name => Proxy name -> Path names -> Path (name : names), in an equation for stripOut at Lits.hs:20:13-26 Expected type: Path (StripOut name names) Actual type: Path (name1 : StripOut name names1) Relevant bindings include path :: Path names1 (bound at Lits.hs:20:23) n' :: Proxy name1 (bound at Lits.hs:20:20) n :: Proxy name (bound at Lits.hs:20:10) stripOut :: Proxy name -> Path names -> Path (StripOut name names) (bound at Lits.hs:18:1) In the expression: Longer n' (stripOut n path) In an equation for stripOut : stripOut n (Longer n' path) = Longer n' (stripOut n path) Failed, modules loaded: none.

4 13

RULES in binary
by Simon Peyton Jones 27 Jul '15

27 Jul '15

Lennart In the binary library I'm seeing lots of these warnings: libraries/binary/src/Data/Binary/Get.hs:420:1: warning: Rule "getWord16le/readN" may never fire because 'getWord16le' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function libraries/binary/src/Data/Binary/Builder/Base.hs:510:1: warning: Rule "flush/flush" may never fire because 'flush' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on this function The warnings look right to me: currently everything is very fragile and may not work as you intend. You may want to look into this? Simon

3 6

Handling overflow and division by zero
by Nikita Karetnikov 27 Jul '15

27 Jul '15

Haskell is often marketed as a safe (or safer) language, but there's an issue that makes it less safe as it could be. I'm talking about arithmetic overflows and division by zero. The safeint package tries to address this, but it only supports the Int type because (as I understand it) there are no useful primitives for other common types defined in Data.Int and Data.Word. I've tried adding Int64 support to safeint just to see how it would work without primops. Here's a snippet (I haven't tested this code well, so it may be wrong, sorry about that): shiftRUnsigned :: Word64 -> Int -> Word64 shiftRUnsigned = shiftR -- http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l9… plusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64 plusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError where r = a + b c = (fromIntegral $ (complement (a `xor` b)) .&. (a `xor` r)) `shiftRUnsigned` ((finiteBitSize a) - 1) -- http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l9… minusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64 minusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError where r = a - b c = (fromIntegral $ (a `xor` b) .&. (a `xor` r)) `shiftRUnsigned` ((finiteBitSize a) - 1) -- https://stackoverflow.com/a/1815371 timesSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64 timesSI64 (SI64 a) (SI64 b) = let x = a * b in if a /= 0 && x `div` a /= b then overflowError else SI64 x I may be wrong, but my understanding is that new primops could reduce overhead here. If so, would a patch adding them be accepted? Are there any caveats? In the safeint package, would it be reasonable to return an Either value instead of throwing an exception? Or would it be too much? I haven't created a wiki page or ticket because I don't know much, so I want to get some feedback before doing so. That would be my first patch to GHC (if ever), so maybe I'm not the best candidate, but I've been thinking about it for too long to ignore. :\

3 4

Re: Improving the "Get Haskell Experience"
by Michael Snoyman 24 Jul '15

24 Jul '15

On Fri, Jul 24, 2015 at 11:16 AM Heinrich Apfelmus < apfelmus(a)quantentunnel.de> wrote: > Michael Snoyman wrote: > > > >> Hopefully, they come with suitable documentation. For instance, one > >> thing I don't understand about stack yet is in which location it > >> "magically" installs GHC and packages, and how I can invoke `ghci` from > >> these locations. Somehow, I was unable to understand this from the FAQ. > >> > >> > > I think this FAQ entry should help[1] on the first question: > > > > [1]: https://github.com/commercialhaskell/stack/wiki/FAQ [..] > > > >> Note that stack setup installs GHC into > > ~/.stack/programs/$platform/ghc-$version/ and not a global location. > > Ah, ok. Can I assume that the non-sandboxed packages are also installed > in the ~/.stack directory? That's the other part I didn't understand. > > I'm not sure what "non-sandboxed packages" means. Do you mean snapshot-level packages? If so, yes. If you mean project-specific packages: they're all stored in the .stack-work directory of the project itself. My recommendation overall is: build a project with `stack`, and run `stack path` to get information on all of the different paths it's using for various things. > > For the second question: either `stack ghci` or `stack exec ghci` should > > achieve what you're looking for. The former is a bit more experimental, > and > > does more intelligent stuff at the project level as far as loading up > your > > code. The latter simply runs the ghci command with appropriate PATH and > > GHC_PACKAGE_PATH environment variables set. > > `stack ghci` sounds good to me, then. I really like the short startup > times of ghci and never use `cabal exec ghci` for that reason. > > I think `stack exec ghci` is what you mean, correct? > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

GHC crashing in checkProddableBlock during linking
by Luke Iannini 24 Jul '15

24 Jul '15

Hi all, I'm encountering a crash in GHC 7.10.1 and 7.8.4 on Windows when I attempt to use Template Haskell in anything that relies on a package that contains C++; in my case, bindings to the Bullet physics engine. This is a pretty big blocker for me as I haven't found any good workarounds, so it would be awesome to get a fix in (I guess I just missed 7.10.2) I've made some progress here and a minimal reproduction if anyone can help: https://ghc.haskell.org/trac/ghc/ticket/10672 Cheers Luke

1 0

Improving the "Get Haskell Experience"
by Mark Lentczner 23 Jul '15

23 Jul '15

*tl;dr: We'd like to incorporate stack into Haskell Platform, and stop shipping pre-built packages, so we banish cabal hell, and have a single common way to 'get Haskell' that just works.* At ICFP '14, there were several long group discussions of the state of "getting Haskell", including Haskell Platform, Stackage, and other approaches. Over the last year, there have been a few more public discussions and evolution on the ideas, and other installer developments. In particular, Stackage's LTS package sets are a direct development from this work, and the release of stack has offered new options. Today, drawing from all this good work and ideas from so many, we'd would like to propose a concrete plan: - Haskell Platform becomes the standard way to get *GHC* and related tools: *alex*, *cabal*, *happy*, *hscolour*, and *stack*. It's a user-friendly, cross-platform installer that gives a standard way to "get Haskell" for most users. - Use the *stack* model for package installation: - The global db has only the GHC packages - There is a package db for each curated set, Haskell Platform becomes one such set - Projects each have their own package db, much like sandboxes. - Haskell Platform's installer will no longer include pre-built, pre-installed packages other than GHC's set. Instead, it is configured so that *stack* can be used to build and install, on as needed, the corresponding Haskell Platform release packages. We think this plan solves many different community needs: - We have a clear way to "get Haskell" that works for a wide variety of use cases. - HP installer gets much smaller, and about as minimal as a working installation can get. - By leaving most packages out of the global database, users of cabal-install, will now have far fewer problems. Sandbox builds should now never give users "cabal hell" like warnings. - By building and installing the Platform packages into it's own package db, users get the benefit of building and installing these common packages only once per system, yet can easily bypass them for any given project if desired. - Since the Platform packages are now built and installed as needed, installing on smaller systems or servers without OpenGL will work. To do this, we have a bit of work ahead of us: We need to settle on installation layout for each OS (including getting msys into the Windows installer); decide on the naming and versioning of the Platform package set (is it just LTS? does it have a different life cycle? etc...); getting *stack* ready such a distribution; and configuring (or updating) *cabal-install* to support the three-layer package db scheme. We think we can do this in short order. We recognize this represents a significant change for the Platform, and will require buy-in from the various parts, especially *ghc*, *cabal*, and *stack*. We'd like to get your input. - Michael & Mark

5 5

RE: [commit: ghc] master: Testsuite: recenter haddock.base allocation numbers (1b76997)
by Simon Peyton Jones 23 Jul '15

23 Jul '15

Could it be creeping up because Haddock is doing more than before? Ie not just because GHC is being bad? S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 22 July 2015 17:33 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Testsuite: recenter haddock.base | allocation numbers (1b76997) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/1b76997dba5c35ee956960e1948e | e247dc57c500/ghc | | >--------------------------------------------------------------- | | commit 1b76997dba5c35ee956960e1948ee247dc57c500 | Author: Thomas Miedema <thomasmiedema(a)gmail.com> | Date: Wed Jul 22 18:21:44 2015 +0200 | | Testsuite: recenter haddock.base allocation numbers | | | >--------------------------------------------------------------- | | 1b76997dba5c35ee956960e1948ee247dc57c500 | testsuite/tests/perf/haddock/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/haddock/all.T | b/testsuite/tests/perf/haddock/all.T | index 94f7cbd..1e5a16c 100644 | --- a/testsuite/tests/perf/haddock/all.T | +++ b/testsuite/tests/perf/haddock/all.T | @@ -5,7 +5,7 @@ | test('haddock.base', | [unless(in_tree_compiler(), skip), req_haddock | ,stats_num_field('bytes allocated', | - [(wordsize(64), 9014511528, 5) | + [(wordsize(64), 9418857192, 5) | # 2012-08-14: 5920822352 (amd64/Linux) | # 2012-09-20: 5829972376 (amd64/Linux) | # 2012-10-08: 5902601224 (amd64/Linux) @@ -23,6 +23,7 @@ | test('haddock.base', | # 2014-10-07: 8322584616 (x86_64/Linux) | # 2014-12-14: 9502647104 (x86_64/Linux) - Update to | Haddock 2.16 | # 2014-01-08: 9014511528 (x86_64/Linux) - Eliminate so- | called "silent superclass parameters" (and others) | + # 2015-07-22: 9418857192 (x86_64/Linux) - Just slowly | creeping up. | | ,(platform('i386-unknown-mingw32'), 4434804940, 5) | # 2013-02-10: 3358693084 | (x86/Windows) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

2 2

Test failures: T4945 and haddock.base
by Thomas Miedema 22 Jul '15

22 Jul '15

Simon, Allocation for haddock.base is now 9466142208 bytes according to [1]. Before your changes yesterday it was 9385186792, according to [2]. Thomas [1] https://phabricator.haskell.org/harbormaster/build/5076/?l=0 [2] https://perf.haskell.org/ghc/#revision/9ade087108afe2eec2698b6ce41146df0252…

2 2

build system
by Simon Peyton Jones 21 Jul '15

21 Jul '15

Friends With the new build system I get this kind of output HC [stage 1] compiler/stage2/build/SPARC/AddrMode.o HC [stage 1] compiler/stage2/build/CmmContFlowOpt.o HC [stage 1] compiler/stage2/build/CmmImplementSwitchPlans.o AR libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a C:\fp\HP-2014-2.0.0.0\mingw\bin\ar.exe: creating libraries/Cabal/Cabal/dist-install/build/libHSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.a LD libraries/Cabal/Cabal/dist-install/build/HSCabal-1.23.0.0-752LrSyTT7YLYxOzpNXfM5.o HC [stage 1] utils/ghc-cabal/dist-install/build/Main.o WARNING: file compiler\specialise\Specialise.hs, line 724 But I have no idea which module caused the WARNING, nor do I have a command-line to copy/paste to reproduce it. (With the old module-at-a-time system I could copy/paste the command line for the specific module.) Is there a way to * make things sequential so I can tell which warnings from which module * get a command line to copy/paste to compile that module? Thanks Simon

4 7