July 2015 - ghc-devs - Haskell.org

Ideas for research
by Nikita Kartashov 28 Jul '15

28 Jul '15

Hello ghc-devs, I’m starting a PhD program in September and in need of a topic. Could you point me to some projects that still need to be implemented or even general areas which need to be explored? https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions page is old and probably not up-to-date. I’m not shy of coding or math, and will be able to spend time reading papers to familiarise myself with the arising problems. With regards, Nikita Kartashov

2 1

RE: warnings
by Simon Peyton Jones 28 Jul '15

28 Jul '15

Validating now, but have to go to London for a few hrs. Meanwhile use -Wwarn! From: Simon Peyton Jones Sent: 27 July 2015 17:08 To: ghc-devs Subject: warnings 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

Trac is slow
by Simon Peyton Jones 28 Jul '15

28 Jul '15

Trac is terribly slow today. More than 60 seconds to load a single page. Help! Simon

1 0

RE: Deleting sync-all
by Tamar Christina 27 Jul '15

27 Jul '15

Hi Thomas, Sure I can take care of that part. I'll make a separate issue for it. I also think we should do the first part as well eventually (using mingw-w for for both x64 and x86_64) as that solves #10435 . Regards, Tamar ------------------------------ From: Thomas Miedema <thomasmiedema(a)gmail.com> Sent: ‎7/‎27/‎2015 18:25 To: Tamar Christina <lonetiger(a)gmail.com> Cc: Páli Gábor János <pali.gabor(a)gmail.com>; ghc-devs(a)haskell.org Subject: Re: Deleting sync-all Hi Tamar, feel free to take over that patch <https://phabricator.haskell.org/D339>, or extract the parts you like. It currently does (too) many things, which is part of the reason why it stalled. See my comments in #9218 <https://ghc.haskell.org/trac/ghc/ticket/9218>. Do not wait to get rid of the perl dependency first, because it is yet unclear how to proceed (#9832 <https://ghc.haskell.org/trac/ghc/ticket/9832>). Thomas On Mon, Jul 27, 2015 at 2:34 PM, Tamar Christina <lonetiger(a)gmail.com> wrote: > Hi > > There is a sorta in limbo differential from gintas that would have solved > this by doing it in the configure script. > > I liked that solution. As far as I know the patch was delayed because the > reviewers suggested we get rid of the perl dependency first. > > Regards, > Tamar > ------------------------------ > From: Thomas Miedema <thomasmiedema(a)gmail.com> > Sent: ‎7/‎27/‎2015 10:41 > To: Páli Gábor János <pali.gabor(a)gmail.com> > Cc: ghc-devs(a)haskell.org > Subject: Re: Deleting sync-all > > Hi Gábor, > > instead of changing `ghc.mk`, please change the builder script to also > run `git clone git://git.haskell.org/ghc-tarballs.git`. > > (Edit: while typing this, I saw you just did so) > > The benefits are: > * the windows specific part of creating a source distribution also gets > tested > * the release manager can run `make sdist` on any platform, and they'll > get a complete source distribution they can upload > > Thomas > > On Sun, Jul 26, 2015 at 8:36 PM, Páli Gábor János <pali.gabor(a)gmail.com> > wrote: > >> Hi Thomas, >> >> 2015-07-21 12:45 GMT+02:00 Thomas Miedema <thomasmiedema(a)gmail.com>: >> > To get the sources: >> > >> > git clone --recursive git://git.haskell.org/ghc.git >> > cd ghc >> > git clone git://git.haskell.org/ghc-tarballs.git # Windows only >> >> Apparently, that last line is also needed even on non-Windows systems >> when one wants to make the "sdist" target, at least as I have observed >> on my builders, e.g. [1]. >> >> So I have put together a small patch that aims to fix this -- mind >> you, I have not tested it on Windows, but theoretically it shall just >> work: >> >> --- a/ghc.mk >> +++ b/ghc.mk >> @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep >> sdist-testsuite: sdist-testsuite-prep >> cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - >> $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) >> -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) >> >> +SDIST_TARGETS= sdist-ghc sdist-testsuite >> + >> +ifeq "$(Windows_Host)" "YES" >> +SDIST_TARGETS+= sdist-windows-tarballs >> +endif >> >> .PHONY: sdist >> -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite >> +sdist : $(SDIST_TARGETS) >> >> sdist-manifest : $(SRC_DIST_GHC_TARBALL) >> tar tjf $(SRC_DIST_GHC_TARBALL) | sed >> "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest >> diff --git a/utils/haddock b/utils/haddock >> >> Are there any objections to commit this? >> >> Thanks, >> Gábor >> >> [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html >> > >

1 0

RE: Deleting sync-all
by Tamar Christina 27 Jul '15

27 Jul '15

Hi There is a sorta in limbo differential from gintas that would have solved this by doing it in the configure script. I liked that solution. As far as I know the patch was delayed because the reviewers suggested we get rid of the perl dependency first. Regards, Tamar ------------------------------ From: Thomas Miedema <thomasmiedema(a)gmail.com> Sent: ‎7/‎27/‎2015 10:41 To: Páli Gábor János <pali.gabor(a)gmail.com> Cc: ghc-devs(a)haskell.org Subject: Re: Deleting sync-all Hi Gábor, instead of changing `ghc.mk`, please change the builder script to also run `git clone git://git.haskell.org/ghc-tarballs.git`. (Edit: while typing this, I saw you just did so) The benefits are: * the windows specific part of creating a source distribution also gets tested * the release manager can run `make sdist` on any platform, and they'll get a complete source distribution they can upload Thomas On Sun, Jul 26, 2015 at 8:36 PM, Páli Gábor János <pali.gabor(a)gmail.com> wrote: > Hi Thomas, > > 2015-07-21 12:45 GMT+02:00 Thomas Miedema <thomasmiedema(a)gmail.com>: > > To get the sources: > > > > git clone --recursive git://git.haskell.org/ghc.git > > cd ghc > > git clone git://git.haskell.org/ghc-tarballs.git # Windows only > > Apparently, that last line is also needed even on non-Windows systems > when one wants to make the "sdist" target, at least as I have observed > on my builders, e.g. [1]. > > So I have put together a small patch that aims to fix this -- mind > you, I have not tested it on Windows, but theoretically it shall just > work: > > --- a/ghc.mk > +++ b/ghc.mk > @@ -1183,9 +1183,14 @@ sdist-windows-tarballs: sdist-windows-tarballs-prep > sdist-testsuite: sdist-testsuite-prep > cd $(SRC_DIST_TESTSUITE_ROOT) && "$(TAR_CMD)" chf - > $(SRC_DIST_BASE_NAME) 2> testsuite_log | $(TAR_COMP_CMD) > -c > $(TOP)/$(SRC_DIST_TESTSUITE_TARBALL) > > +SDIST_TARGETS= sdist-ghc sdist-testsuite > + > +ifeq "$(Windows_Host)" "YES" > +SDIST_TARGETS+= sdist-windows-tarballs > +endif > > .PHONY: sdist > -sdist : sdist-ghc sdist-windows-tarballs sdist-testsuite > +sdist : $(SDIST_TARGETS) > > sdist-manifest : $(SRC_DIST_GHC_TARBALL) > tar tjf $(SRC_DIST_GHC_TARBALL) | sed > "s|^ghc-$(ProjectVersion)/||" | sort >sdist-manifest > diff --git a/utils/haddock b/utils/haddock > > Are there any objections to commit this? > > Thanks, > Gábor > > [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/700/15.html >

2 1

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