- ghc-devs - Haskell.org

bkpcabal01 test failure on Mac OS X
by Ben Gamari 08 Oct '16

08 Oct '16

Hi Edward, Our new OS X build bot has noticed that the bkpcabal01 testcase introduced with your Backpack merge seems to fail on OS X with, =====> bkpcabal01(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print-directory bkpcabal01 CLEANUP=1 Actual stderr output differs from expected: --- /dev/null 2016-10-08 22:51:23.000000000 +0300 +++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300 @@ -0,0 +1,4 @@ +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols *** unexpected failure for bkpcabal01(normal) It seems that this message is produced by `ar` while building the .a archive, bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01 ... ("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"]) ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o /Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols I've opened #12673 to track this issue but until we have a chance to fix it I've enabled `ignore_stderr` to the testcase on Darwin. Cheers, - Ben

1 0

Type hole in pattern match
by amindfv＠gmail.com 08 Oct '16

08 Oct '16

Is this intended behavior?: foo :: _ (foo, _) = (True, True) Produces no warning or message at all even with -Wall Tom

3 2

[GHC Proposal] Optional tuple parenthesization
by Ben Gamari 07 Oct '16

07 Oct '16

Hello everyone, Iceland_Jack has just opened Pull Requests #18 [1] and #19 [2] against the ghc-proposals repository, describing a extensions to GHC's LambdaCase extension and pattern matching syntax on tuples. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/18 [2] https://github.com/ghc-proposals/ghc-proposals/pull/19

1 0

Travis broken (type checking patches by SPJ)
by Joachim Breitner 07 Oct '16

07 Oct '16

Hi, our secondary CI infrastructure is in bad shape since a week. The first push that broke it was the one ending with commit fc4ef66 by SPJ: * fc4ef66 - Comments only (vor 7 Tagen)<Simon Peyton Jones> * b612da6 - Fix impredicativity (again) (vor 7 Tagen)<Simon Peyton Jones> * 3012c43 - Add Outputable Report in TcErrors (vor 7 Tagen)<Simon Peyton Jones> * 66a8c19 - Fix a bug in occurs checking (vor 7 Tagen)<Simon Peyton Jones> * 2fbfbca - Fix desugaring of pattern bindings (again) (vor 7 Tagen)<Simon Peyton Jones> * 0b533a2 - A bit of tracing about flattening (vor 7 Tagen)<Simon Peyton Jones> https://github.com/ghc/ghc/compare/f21eedbc223c...fc4ef667ce2b --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ /tmp/ghctest-gSX4vv/test spaces/./boxy/Base1.run/Base1.comp.stderr.normalised 2016-09-30 12:44:57.182659875 +0000 @@ -0,0 +1,18 @@ + +Base1.hs:20:13: + Couldn't match type â€˜a0 -> a0â€™ with â€˜forall a. a -> aâ€™ + Expected type: MEither Sid b + Actual type: MEither (a0 -> a0) b + In the expression: MLeft fid + In an equation for â€˜test1â€™: test1 fid = MLeft fid + +Base1.hs:25:39: + Couldn't match type â€˜a1 -> a1â€™ with â€˜forall a. a -> aâ€™ + Expected type: Maybe (Sid, Sid) + Actual type: Maybe (a1 -> a1, a2 -> a2) + In the expression: Just (x, y) + In a case alternative: MRight y -> Just (x, y) + In the expression: + case m of { + MRight y -> Just (x, y) + _ -> Nothing } *** unexpected failure for Base1(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_aAI Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for RaeBlogPost(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_awK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for TypeLevelVec(normal) A subsequent commit by SPJ fixed the first one. It now compield without -DDEBUG again, but the other two failures (observable only with -DDEBUG) are still there. Since then, Travis has been reporting failures for the master branch. I only noticed now as I pushed something to master, and I got an email. Did you not get notifications about the breakage? If you did, was it unclear how to get to the log file? In any case: Simon, could you have a look and see if the ASSERT is pointing out a real bug introduced with your commits, or whether the ASSERT is wrong, so that we can build master with -DDEBUG again? Thanks, Joachim -- “Comments only” with this failure:Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

RE: Typeable meeting
by Simon Peyton Jones 07 Oct '16

07 Oct '16

Richard Ben and I concluded 1. Currently saturated (->) is treated differently to unsaturated (->), as witnessed by the special kinding rule for FunTy. The shortest path for TypeRep is to do the same: add TrFunTy. 1. Moreover we probably need FunCo for coercions; at the moment it's done with TyConAppCo, but that doesn't work with (->) :: * -> * -> *. Having FunCo would be (a) more efficient for a very common case, (b) deal with the kinding issue. 2. splitAppTy_maybe currently will split a FunTy even when it is not used at kind *. This is probably wrong. Maybe it should return Nothing in the non-* case. Ben is trying this out. 3. Orthogonally, one could imagine generalising the kind of prefix (->) to (->) :: forall r1 r2. TYPE r1 -> TYPE r2 -> Type LiftedPtrRep Then FunTy would become an abbreviation/optimisation, to avoid a plethora of runtime-rep args. And splitAppTy_maybe could succeed all the time on FunTy. Ben is trying this. 4. Under (3) at what kinds is ((->) ?? LiftedPtrRep (Ord Int) Char) called? If we continue to distinguish * from Constraint, we'd need to instantiate ?? with ConstraintRep, and define type Constraint = TYPE ConstraintRep Orthogonally, one might wonder about combining * and Constraint, but we don't yet know how to do that well. | -----Original Message----- | From: Richard Eisenberg [mailto:rae@cs.brynmawr.edu] | Sent: 06 October 2016 15:08 | To: Ben Gamari <ben(a)smart-cactus.org> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Typeable meeting | | Just seeing this now. (Please use my new address: rae(a)cs.brynmawr.edu) I | wasn't available yesterday at that time, anyway. | | Any conclusions reached? | | > On Oct 4, 2016, at 5:39 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: | > | > Simon Peyton Jones <simonpj(a)microsoft.com> writes: | > | >> Ben, and copying Richard who is far better equipped to respond than | me. | >> | >> I'm way behind the curve here. | >> | >> If "this is precisely what mkFunCo does" why not use mkFunCo? Why do | >> you want to "generalise the arrow operation"? | >> | > Perhaps I should have said "this is what mkFunCo is supposed to do". | > However, mkFunCo needs to be adjusted under the generalized (->) | > scheme, since the (->) tycon will gain two additional type arguments | > (corresponding to the RuntimeReps of the argument and result types). | > mkFunCo needs to fill these type arguments when constructing its | result. | > | >> I'm lost as to your goal and the reason why you need to wade through | this particular swamp. | >> | > There are a few reasons, | > | > * We want to provide a pattern to match against function types | > | > pattern TrFun :: TypeRep arg -> TypeRep res -> TypeRep (arg -> | > res) | > | > * T11120 currently fails on my branch as it contains a TypeRep of a | > promoted type containing an unboxed type. Namely, | > | > import Data.Typeable | > data CharHash = CharHash Char# | > main = print $ typeRep (Proxy :: Proxy 'CharHash) | > | > Note how 'CharHash has kind Char# -> Type. This kind occurs in one of | > the terms in `typeRep` needed in the above program, which currently | > results in core lint failures due to the restrictive kind of (->). | > For this reason (->) needs to be polymorphic over runtime | > representation. | > | > This issue is mentioned in ticket:11714#comment:1. | > | > * I believe there were a few other testcases that failed in similar | > ways to T11120. | > | > For what it's worth, the Type /~ Constraint issue that I'm currently | > fighting with in carrying out the (->) generalization is also the | > cause of another Typeable bug, #11715, so I think this is a worthwhile | > thing to sort out. | > | >> Also your text kind of stops... and then repeats itself. | >> | > Oh dear, I apologize for that. Clipboard malfunction. I've included a | > clean version below for reference. | > | >> We could talk at 2pm UK time tomorrow Weds. Richard would you be | free? | >> | > That would work for me. | > | > Cheers, | > | > - Ben | > | > | > | > | > # Background | > | > Consider what happens when we have the coercions, | > | > co1 :: (a ~ b) | > co2 :: (x ~ y) | > | > where | > | > a :: TYPE ra b :: TYPE rb | > x :: TYPE rx y :: TYPE ry | > | > and we want to construct, | > | > co :: (a -> x) ~ (b -> y) | > | > As I understand it this is precisely what Coercion.mkFunCo does. | > Specifically, co should be a TyConAppCo of (->) applied to co1, co2, | > and coercions showing the equalities ra~rx and rb~ry, | > | > (->) (co_ax :: ra ~ rx) (co_by :: rb ~ ry) co1 co2 | > | > Actually implementing mkFunCo to this specification seems to be not | > too difficult, | > | > -- | Build a function 'Coercion' from two other 'Coercion's. That | is, | > -- given @co1 :: a ~ b@ and @co2 :: x ~ y@ produce @co :: (a -> x) | > ~ (b -> y)@. | > mkFunCo :: Role -> Coercion -> Coercion -> Coercion | > mkFunCo r co1 co2 = | > mkTyConAppCo r funTyCon | > [ mkRuntimeRepCo r co1 -- ra ~ rx where a :: TYPE ra, x :: TYPE | > rx | > , mkRuntimeRepCo r co2 -- rb ~ ry where b :: TYPE rb, y :: TYPE | > ry | > , co1 -- a ~ x | > , co2 -- b ~ y | > ] | > | > -- | For a constraint @co :: (a :: TYPE rep1) ~ (b :: TYPE rep2)@ | > produce | > -- @co' :: rep1 ~ rep2@. | > mkRuntimeRepCo :: Role -> Coercion -> Coercion | > mkRuntimeRepCo r co = mkNthCoRole r 0 $ mkKindCo co | > | Just (tycon, [co]) <- splitTyConAppCo_maybe $ mkKindCo co | > = co | > | otherwise | > = pprPanic "mkRuntimeRepCo: Non-TYPE" (ppr co) | > | > So far, so good (hopefully). | > | > # The Problem | > | > Consider what happens when one of the types is, e.g., HasCallStack. | > For the sake of argument let's say | > | > co1 = <HasCallStack>_R | > co2 = <Int>_R | > | > Recall that HasCallStack is, | > | > type HasCallStack = ((?callStack :: CallStack) :: Constraint) | > | > The problem arises when we attempt to evaluate | > | > mkFunCo r co1 co2 | > | > which will look at the kind coercion of co1, | > | > mkKindCo co1 === <Constraint>_R | > | > and then attempt to splitTyConAppCo it, under the assumption that the | > kind coercion is an application of TYPE, from which we can extract the | > RuntimeRep coercion. Instead we find a nullary TyConAppCo of | > Constraint; things then blow up. | > | > This is the problem. | > | > Ultimately it seems all of this is due to the fact that we play it | > fast- and-loose with Type and Constraint in Core (#11715), especially | > with implicit parameters. I worry that resolving this is more than I | > have time to chew on before 8.2.

3 6

Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
by Carter Schonwald 05 Oct '16

05 Oct '16

In writing the following huge wall of text, I had and idea that I think many folks would find palatable: What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple! What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever! My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period. Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both. My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup. I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that! I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against ) On Saturday, September 24, 2016, Brandon Allbery <allbery.b(a)gmail.com> wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > chak(a)justtesting.org > <javascript:_e(%7B%7D,'cvml','chak(a)justtesting.org');>> wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b(a)gmail.com');> > ballbery(a)sinenomine.net > <javascript:_e(%7B%7D,'cvml','ballbery(a)sinenomine.net');> > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

15 31

Status of Harbormaster
by Ben Gamari 04 Oct '16

04 Oct '16

Hello everyone, Over the last few weeks I have been gradually pushing away at increasing our Harbormaster coverage. I'm happy to report that Harbormaster should now test commits on, * x86_64 Ubuntu Linux * x86_64 Mac OS X Sierra * x86_64 Windows (although the bugs are still being worked out here) Differentials are tested on, * x86_64 Ubuntu Linux * x86_64 Windows For those of you following along at home I've roughly documented the configuration on the Phabricator Wiki [1]. One open question is whether we want to enable Differential building on the OS X box. The security implications of allowing essentially anonymous users to build and run untrusted code in our own CI environment are already quite sticky; to enable Differential building on the OS X box would mean that we would be running untrusted code on someone else's hardware, which seems like it may be a step too far. It would be nice to find a way to extend Differential builds to other platforms in the future, however, so we can ensure that we catch bad patches before they even make it to the tree. It's a bit unclear how far we should extend test coverage. In the future I think I will at very least add an i386 Ubuntu environment, but we could go farther still. For instance these platforms immediately come to mind, * x86_64 FreeBSD * x86_64 Solaris * ARM Linux (although this could be quite tricky given the speed of these machines) * AArch64 Linux There is certainly a maintenance and complexity tradeoff that comes with extending our coverage like this, however, so it's quite unclear where the right compromise lies. I'd love to hear what you think. Happy hacking, - Ben [1] https://phabricator.haskell.org/w/ghc_harbormaster/

4 3

SafeHaskell vs TemplateHaskell
by Erik de Castro Lopo 04 Oct '16

04 Oct '16

Hi all, I tried to fix trac ticket #12511 (template-haskell's Language.Haskell.Syntax module should be Trustworthy) but in doing so I began to think this is actually a bad idea. Specifically, I suspect its actually possible to craft something using TH that bypasses the guarantees that Safe is supposed to ensure. Comments? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1

GHC 8.0.2 status
by Ben Gamari 04 Oct '16

04 Oct '16

Hello everyone, The week before ICFP I was able to get the ghc-8.0 branch ready for an 8.0.2 release, which I intended to cut this week. In the intervening time an additional rather serious issue was reported affected Mac OS X Sierra (#12479). Since this issue affects the usability of GHC on the new OS X release, we'll be deferring the 8.0.2 release until it has been resolved. While there appears to be an actionable path forward on this ticket, we will need someone with an affected machine and an understanding of GHC's use of dynamic linking to step up to implement. Otherwise it looks like the release will be delayed at least until October 9, when darchon has time to have a look. Sorry to be the bearer of bad news! Cheers, - Ben

4 3

Patterns & Quality Attributes Research
by Michael Skeen 04 Oct '16

04 Oct '16

Dear Haskell Compiler Community, We are doing undergraduate research on software architecture patterns and quality attributes for Utah Valley University. We recently analyzed the work published on Haskell Compiler in the Architecture of Open Source Applications <http://aosabook.org/en/index.html> (AOSA) and referenced it in a paper we presented at the 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), as attached. As a part of our continuing research we wish to validate our architectural analysis for Haskell Compiler with the current developers. We would like to know if we are missing any patterns or quality attributes that may have been included in Haskell Compiler, or if there are any we listed that aren’t used. Any additional comment on these topics you might have would also, of course, be welcome. We believe we found the following software architectural patterns in this application: Pattern Name Is This Found in the Architecture? (yes / no / don’t know) Comments (optional) Interpreter Layers Pipes & Filters Plugin Rule-Based System Other? We also identified the following quality attributes: Attribute Name Is This Found in the Architecture? Comments (optional) Scalability Usability Performance Portability Reliability Portability Maintainability Testability Modularity Robustness Other? For your convenience, we have a complete list below of the patterns and quality attributes we referred to when conducting our research. To clarify, we are specifically studying architectural patterns, rather than design patterns such as the GoF patterns. Architectural Patterns Considered Quality Attributes Considered Active Repository Scalability Batch Usability Blackboard Extensibility Broker Performance Client Server Portability Event System Flexibility Explicit Invocation Reliability Implicit Invocation Maintainability Indirection Layer Security Interceptor Testability Interpreter Capacity Layers Cost Master and Commander Legality Microkernel Modularity Model View Controller Robustness Peer to Peer Pipes and Filters Plugin Presentation Abstraction Control Publish Subscribe Reflection Rule-Based System Shared Repository Simple Repository State Based Virtual Machine Please respond by October 17, if possible. Thank you for considering our request, and for your continued work on Haskell Compiler. Sincerely, Erich Gubler, Danielle Skinner, Brandon Leishman, Michael Skeen, Neil Harrison, Ph.D. (advisor) Reference: Neil B. Harrison, Erich Gubler, Danielle Skinner, "Software Architecture Pattern Morphology in Open-Source Systems",WICSA, 2016, 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2016 13th Working IEEE/IFIP Conference on Software Architecture (WICSA) 2016, pp. 91-98, doi:10.1109/WICSA.2016.8

1 0