From simonpj at microsoft.com Mon Sep 1 08:48:52 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 1 Sep 2014 08:48:52 +0000 Subject: cons/build and making rules look boring In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F832F@DB3PRD3001MB020.064d.mgd.msft.net> | makes (:) look "interesting" to the inliner. Unfortunately, as I | discovered after much extreme puzzlement about why rules relating to | scanl were affecting things that had nothing to do with scanl, it | turns out that making (:) look interesting is really quite bad, and | something that we probably never want to happen. Can you give a concrete, reproducible example of the problem you articulate here? (In general, a concrete example brings tremendous focus to discussions, giving readers something specific to bite on.) Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David | Feuer | Sent: 30 August 2014 23:05 | To: ghc-devs | Subject: cons/build and making rules look boring | | I think I may have figured out at least part of the reason that | cons/build gives bad results. I actually ran into a clue when working | on scanl. It seems at least part of the problem is that a rule like | | x : build g = build (\c n -> c x (g c n)) | | makes (:) look "interesting" to the inliner. Unfortunately, as I | discovered after much extreme puzzlement about why rules relating to | scanl were affecting things that had nothing to do with scanl, it | turns out that making (:) look interesting is really quite bad, and | something that we probably never want to happen. | | As a result, the only ways I see to try to make rules like that work | properly are | | 1. If constructors are *always* best treated as boring, and the | inliner knows when's a constructor, make it treat them all as boring. | | 2. Offer a BORINGRULE annotation to indicate that the rule should not | make its LHS "interesting", or | | 3. (I don't like this option much) Make a special case forcing (:) in | particular to be boring. | | David | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From david.feuer at gmail.com Mon Sep 1 09:14:45 2014 From: david.feuer at gmail.com (David Feuer) Date: Mon, 1 Sep 2014 05:14:45 -0400 Subject: cons/build and making rules look boring In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221F832F@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF221F832F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: The rule to make scanl fuse looks like this: "scanl" [~1] forall f a bs . scanl f a bs = build (\c n -> a `c` foldr (scanlFB f c) (constScanl n) bs a) I initially tried reversing it with something like this rule (I'm not sure it was exactly like this, but it was similar): "scanlList" [1] forall f a bs . a : foldr (scanlFB f (:)) (constScanl []) bs a) = scanl f a bs What I found was that this implementation led to poor performance on a couple nofib benchmarks (I don't remember which off the top of my head). When I dug down into them to see how they were using scanl, I found that they *weren't*, either directly or indirectly. When I compared core2core and dump-inlinings, I saw that the core looked pretty much the same for a while, but the inliner was saying different things about how it was making judgements about what to inline. Eventually, I realized that it was looking at (:) differently *in general*, and giving it an inlining bonus, because it appeared as the outermost name in the "scanlList" rule. In at least one case, that changed its decision about whether to inline something. I only know this is bad because the benchmarks said so?I don't know the precise reasons. On Sep 1, 2014 4:49 AM, "Simon Peyton Jones" wrote: > | makes (:) look "interesting" to the inliner. Unfortunately, as I > | discovered after much extreme puzzlement about why rules relating to > | scanl were affecting things that had nothing to do with scanl, it > | turns out that making (:) look interesting is really quite bad, and > | something that we probably never want to happen. > > Can you give a concrete, reproducible example of the problem you > articulate here? (In general, a concrete example brings tremendous focus > to discussions, giving readers something specific to bite on.) > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David > | Feuer > | Sent: 30 August 2014 23:05 > | To: ghc-devs > | Subject: cons/build and making rules look boring > | > | I think I may have figured out at least part of the reason that > | cons/build gives bad results. I actually ran into a clue when working > | on scanl. It seems at least part of the problem is that a rule like > | > | x : build g = build (\c n -> c x (g c n)) > | > | makes (:) look "interesting" to the inliner. Unfortunately, as I > | discovered after much extreme puzzlement about why rules relating to > | scanl were affecting things that had nothing to do with scanl, it > | turns out that making (:) look interesting is really quite bad, and > | something that we probably never want to happen. > | > | As a result, the only ways I see to try to make rules like that work > | properly are > | > | 1. If constructors are *always* best treated as boring, and the > | inliner knows when's a constructor, make it treat them all as boring. > | > | 2. Offer a BORINGRULE annotation to indicate that the rule should not > | make its LHS "interesting", or > | > | 3. (I don't like this option much) Make a special case forcing (:) in > | particular to be boring. > | > | David > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Sep 1 07:26:44 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 01 Sep 2014 08:26:44 +0100 Subject: [Haskell] ANNOUNCE: GHC version 7.8.3 In-Reply-To: References: <917BB1CE-5AB4-4F67-881A-60B375E1DEEA@serpentine.com> Message-ID: <54041FB4.7050608@gmail.com> Hi Sven - you would need to compile the module with -dynamic or -dynamic-too to have it be picked up by the new dynamically-linked GHCi in 7.8. Cheers, Simon On 05/08/2014 12:32, Sven Panne wrote: > Coming a bit late to the party, but I've just realized this when > playing around with the platform release candidate: I've successfully > built and installed the 2014 RC3 on x64 Ubuntu Linux 12.04 LTS using > ghc-7.8.3-x86_64-unknown-linux-centos65.tar.bz2 from the GHC download > page. But somehow loading compiled code into ghci doesn't work, ghci > always uses interpreted code. To verify this I've followed the simple > example at http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ghci-compiled.html: > > ------------------------------------------------------------------------------------------------- > svenpanne at svenpanne:~/ghci-test$ ll > total 16 > -rw-r----- 1 svenpanne eng 33 Aug 5 13:01 A.hs > -rw-r----- 1 svenpanne eng 24 Aug 5 13:02 B.hs > -rw-r----- 1 svenpanne eng 24 Aug 5 13:02 C.hs > -rw-r----- 1 svenpanne eng 15 Aug 5 13:02 D.hs > svenpanne at svenpanne:~/ghci-test$ more *.hs > :::::::::::::: > A.hs > :::::::::::::: > module A where > import B > import C > :::::::::::::: > B.hs > :::::::::::::: > module B where > import D > :::::::::::::: > C.hs > :::::::::::::: > module C where > import D > :::::::::::::: > D.hs > :::::::::::::: > module D where > svenpanne at svenpanne:~/ghci-test$ ghci-7.6.3 > GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :! ghc-7.6.3 -c D.hs > Prelude> :load A > [2 of 4] Compiling C ( C.hs, interpreted ) > [3 of 4] Compiling B ( B.hs, interpreted ) > [4 of 4] Compiling A ( A.hs, interpreted ) > Ok, modules loaded: D, C, A, B. > *A> :show modules > D ( D.hs, D.o ) > C ( C.hs, interpreted ) > A ( A.hs, interpreted ) > B ( B.hs, interpreted ) > *A> > Leaving GHCi. > svenpanne at svenpanne:~/ghci-test$ rm *.hi *.o > svenpanne at svenpanne:~/ghci-test$ ghci-7.8.3 > GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Prelude> :! ghc-7.8.3 -c D.hs > Prelude> :load A > [1 of 4] Compiling D ( D.hs, interpreted ) > [2 of 4] Compiling C ( C.hs, interpreted ) > [3 of 4] Compiling B ( B.hs, interpreted ) > [4 of 4] Compiling A ( A.hs, interpreted ) > Ok, modules loaded: D, C, A, B. > *A> :show modules > D ( D.hs, interpreted ) > C ( C.hs, interpreted ) > A ( A.hs, interpreted ) > B ( B.hs, interpreted ) > *A> > Leaving GHCi. > ------------------------------------------------------------------------------------------------- > > Using strace showed that ghci-7.8.3 reads D.hs twice (huh?) and D.hi > once, but only "stat"s D.o (never reads its contents): > > ------------------------------------------------------------------------------------------------- > [...] > 12124 stat("D.hs", {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 stat("./D.hs", {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 open("./D.hs", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90c12938) = -1 > ENOTTY (Inappropriate ioctl for device) > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 lseek(11, 0, SEEK_CUR) = 0 > 12124 read(11, "module D where\n", 8096) = 15 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 lseek(11, 0, SEEK_CUR) = 15 > 12124 close(11) = 0 > 12124 open("./D.hs", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90c12938) = -1 > ENOTTY (Inappropriate ioctl for device) > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=15, ...}) = 0 > 12124 read(11, "module D where\n", 8096) = 15 > 12124 close(11) = 0 > 12124 stat("./D.o", {st_mode=S_IFREG|0640, st_size=933, ...}) = 0 > 12124 stat("Prelude.hs", 0x7f28b26e2b30) = -1 ENOENT (No such file or directory) > 12124 stat("Prelude.lhs", 0x7f28b26e2cd0) = -1 ENOENT (No such file or > directory) > 12124 stat("B.hs", {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 stat("./B.hs", {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 open("./B.hs", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90c12938) = -1 > ENOTTY (Inappropriate ioctl for device) > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 lseek(11, 0, SEEK_CUR) = 0 > 12124 read(11, "module B where\nimport D\n", 8096) = 24 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 lseek(11, 0, SEEK_CUR) = 24 > 12124 close(11) = 0 > 12124 open("./B.hs", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90c12938) = -1 > ENOTTY (Inappropriate ioctl for device) > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=24, ...}) = 0 > 12124 read(11, "module B where\nimport D\n", 8096) = 24 > 12124 close(11) = 0 > 12124 stat("./B.o", 0x7f28b26fa780) = -1 ENOENT (No such file or directory) > 12124 stat("Prelude.hs", 0x7f28b26fa900) = -1 ENOENT (No such file or directory) > 12124 stat("Prelude.lhs", 0x7f28b26faaa0) = -1 ENOENT (No such file or > directory) > 12124 mkdir("/tmp/ghc12124_0", 0777) = 0 > 12124 stat("/tmp/ghc12124_0/ghc12124_1.o", 0x7f28b26facf0) = -1 ENOENT > (No such file or directory) > 12124 open("./D.hi", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=500, ...}) = 0 > 12124 ioctl(11, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90c12938) = -1 > ENOTTY (Inappropriate ioctl for device) > 12124 fstat(11, {st_mode=S_IFREG|0640, st_size=500, ...}) = 0 > 12124 read(11, "\1\372\316d\0\0\0\0\0\0\0\0\4\0"..., 8096) = 500 > 12124 close(11) = 0 > 12124 select(2, [], [1], NULL, {0, 0}) = 1 (out [1], left {0, 0}) > 12124 write(1, "[1 of 4] Compiling D ( D.hs, > interpreted )\n", 58) = 58 > [...] > ------------------------------------------------------------------------------------------------- > > This looks wrong to me. Did I miss something and/or did something > stupid? Known bug? > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Mon Sep 1 07:21:07 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 01 Sep 2014 08:21:07 +0100 Subject: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea) In-Reply-To: <1407154428.1818.7.camel@joachim-breitner.de> References: <20140801175727.61A0A240EA@ghc.haskell.org> <618BE556AADD624C9C918AA5D5911BEF22086308@DB3PRD3001MB020.064d.mgd.msft.net> <1406928426.6407.2.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF2208890B@DB3PRD3001MB020.064d.mgd.msft.net> <1407150134-sup-8316@sabre> <1407150511.1818.5.camel@joachim-breitner.de> <1407154428.1818.7.camel@joachim-breitner.de> Message-ID: <54041E63.5090609@gmail.com> On 04/08/2014 13:13, Joachim Breitner wrote: > Hi, > > > Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner: >> Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang: >>> Yes, on my box, this test is now failing (because the stat is too good): >>> >>> Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% >>> Lower bound haddock.base(normal) max_bytes_used: 115159039 >>> Upper bound haddock.base(normal) max_bytes_used: 140749937 >>> Actual haddock.base(normal) max_bytes_used: 113167424 >>> Deviation haddock.base(normal) max_bytes_used: -11.6 % >> >> ugh. >> >> What are your compilation settings? Plain "validate"? >> >> Looks like the ghcspeed instance settings still don?t quite match what >> validate does... >> >> But I don?t see anything in >> mk/validate-settings.mk >> which would yield different results than >> echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk >> echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk >> >> I?m starting a plain validate run on that machine, to see if it is >> compilation settings or some other variable. > > validate goes through without a problem. So it seems to be dependent on > other things. > > Are these very flaky measures (max_bytes_used) at all useful? So far, I > have only seen friction due to them, and any real problem would likely > be caught by either bytes_allocated or nofib measurements (I hope). > Maybe we should simply remove them from the test suite, and stop > worrying? From testsuite/tests/perf/compiler/all.T: # Note [residency] # # Residency (peak_megabytes_allocated and max_bytes_used) is sensitive # to when the major GC runs, which makes it inherently inaccurate. # Sometime an innocuous change somewhere can shift things around such # that the samples occur at a different time, and the residency # appears to change (up or down) when the underlying profile hasn't # really changed. # # However, please don't just ignore changes in residency. If you see # a change in one of these figures, please check whether it is real or # not as follows: # # * Run the test with old and new compilers, adding +RTS -h -i0.01 # (you don't need to compile anything for profiling or enable profiling # libraries to get a heap profile). # * view the heap profiles, read off the maximum residency. If it has # really changed, then you know there's an issue. This advice is hard to follow for the Haddock tests, because the test doesn't actually run anything, it just uses the information previously collected. I think we should probably remove the max_bytes_used limits for the Haddock tests. Cheers, Simon From svenpanne at gmail.com Mon Sep 1 10:30:18 2014 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 1 Sep 2014 12:30:18 +0200 Subject: [Haskell] ANNOUNCE: GHC version 7.8.3 In-Reply-To: <54041FB4.7050608@gmail.com> References: <917BB1CE-5AB4-4F67-881A-60B375E1DEEA@serpentine.com> <54041FB4.7050608@gmail.com> Message-ID: 2014-09-01 9:26 GMT+02:00 Simon Marlow : > Hi Sven - you would need to compile the module with -dynamic or -dynamic-too > to have it be picked up by the new dynamically-linked GHCi in 7.8. Ah, OK... Adding -dynamic makes this work, but with -dynamic-too, ghci still loads the interpreted version. I didn't follow the linking story in detail, so this is all a bit confusing. I think that at least http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ghci-compiled.html needs some update, because as it is, it doesn't reflect reality. From ggreif at gmail.com Mon Sep 1 11:09:49 2014 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 1 Sep 2014 13:09:49 +0200 Subject: [Haskell] ANNOUNCE: GHC version 7.8.3 In-Reply-To: References: <917BB1CE-5AB4-4F67-881A-60B375E1DEEA@serpentine.com> <54041FB4.7050608@gmail.com> Message-ID: This makes me thinking: Can we employ this "technique" (or some variation of it) to have an *interpreter-only* version of TH for cross-compiled targets? Many TH use-cases do not necessitate the loading and running of native libraries, and e.g. for generating some lenses the interpreter-only TH solution would be a great progress already. So, instead of adding the TH-feature to cross-compilation, one could strip a normal stage-2 build from its ability to load TH dylibs, and see how far we get compiling `lens` (this reminds me of https://www.fpcomplete.com/user/edwardk/editorial/procrustean-mathematics#centipede-mathematics). Then we could try to figure out what it takes to transfer this feature set back to cross targets. Just my 2 cents, Gabor On 9/1/14, Sven Panne wrote: > 2014-09-01 9:26 GMT+02:00 Simon Marlow : >> Hi Sven - you would need to compile the module with -dynamic or >> -dynamic-too >> to have it be picked up by the new dynamically-linked GHCi in 7.8. > > Ah, OK... Adding -dynamic makes this work, but with -dynamic-too, ghci > still loads the interpreted version. I didn't follow the linking story > in detail, so this is all a bit confusing. I think that at least > http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ghci-compiled.html > needs some update, because as it is, it doesn't reflect reality. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From merijn at inconsistent.nl Mon Sep 1 21:41:33 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Mon, 1 Sep 2014 14:41:33 -0700 Subject: PROPOSAL: Make Data.Type.Bool.If polykinded Message-ID: <83E4E7CC-3488-4ED0-BDB3-1CDF408187FA@inconsistent.nl> Ola! Currently we have: type family If cond tru fls where If True tru fls = tru If False tru fls = fls Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it?s impossible to do foo :: If cond () (?Condition does not hold? ~ ??) => Foo -> Bar or similar fancy constraints. I hereby propose altering If to: type family If (cond :: Bool) (tru :: k) (fls :: k) :: k where If True tru fls = tru If False tru fls = fls Allowing it to work with kinds other than *. Discussion period: 2 weeks? Seems like a minor change. Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From slyich at gmail.com Mon Sep 1 21:53:20 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Tue, 2 Sep 2014 00:53:20 +0300 Subject: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6 In-Reply-To: <87d2c4krhj.fsf@karetnikov.org> References: <87d2c4krhj.fsf@karetnikov.org> Message-ID: <20140902005320.221c02ea@sf> On Thu, 14 Aug 2014 01:30:00 +0400 Nikita Karetnikov wrote: > /usr/bin/ld: rts/dist/build/Adjustor.dyn_o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC > rts/dist/build/Adjustor.dyn_o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[1]: *** [rts/dist/build/libHSrts-ghc7.9.20140809.so] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 Hi Nikita! I have happened to find seemingly related bug in PIC handing on other PIC-sensitive RISCs: https://phabricator.haskell.org/D177 (also in ghc's master) I think it might help you to get ghci on your mipsel. Thanks in advance! -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From nikita at karetnikov.org Tue Sep 2 04:48:22 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 02 Sep 2014 08:48:22 +0400 Subject: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6 In-Reply-To: <20140902005320.221c02ea@sf> (Sergei Trofimovich's message of "Tue, 2 Sep 2014 00:53:20 +0300") References: <87d2c4krhj.fsf@karetnikov.org> <20140902005320.221c02ea@sf> Message-ID: <87tx4qy6eh.fsf@karetnikov.org> > I have happened to find seemingly related bug in PIC handing > on other PIC-sensitive RISCs: > > https://phabricator.haskell.org/D177 (also in ghc's master) > > I think it might help you to get ghci on your mipsel. Thanks for your work. Is it necessary to do anything special in order to build GHCi except the usual ?./sync-all get && perl boot && ./configure && make?? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From slyich at gmail.com Tue Sep 2 06:21:43 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Tue, 2 Sep 2014 09:21:43 +0300 Subject: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6 In-Reply-To: <87tx4qy6eh.fsf@karetnikov.org> References: <87d2c4krhj.fsf@karetnikov.org> <20140902005320.221c02ea@sf> <87tx4qy6eh.fsf@karetnikov.org> Message-ID: <20140902092143.52d679d7@sf> On Tue, 02 Sep 2014 08:48:22 +0400 Nikita Karetnikov wrote: > > I have happened to find seemingly related bug in PIC handing > > on other PIC-sensitive RISCs: > > > > https://phabricator.haskell.org/D177 (also in ghc's master) > > > > I think it might help you to get ghci on your mipsel. > > Thanks for your work. Is it necessary to do anything special in order > to build GHCi except the usual ?./sync-all get && perl boot && > ./configure && make?? Yeah, those commands should be enough. -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From ezyang at mit.edu Tue Sep 2 07:08:23 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 02 Sep 2014 09:08:23 +0200 Subject: Proposal: run GHC API tests on fast In-Reply-To: References: <1401411058-sup-8260@sabre> <1408726908-sup-9449@sabre> <1408805088.2033.3.camel@joachim-breitner.de> <1408816584-sup-9084@sabre> <1408816742.4687.2.camel@joachim-breitner.de> Message-ID: <1409641685-sup-502@sabre> I pushed a fix for the tests in ghc-api. Edward Excerpts from Reid Barton's message of 2014-08-23 20:07:40 +0200: > I have seen this too just running "make THREADS=8". Looks like it's because > the other tests in this directory are cleaning too aggressively. From the > Makefile: > > ... > clean: > rm -f *.o *.hi > > T6145: clean > '$(TEST_HC)' $(TEST_HC_OPTS) --make -v0 -package ghc T6145 > ./T6145 "`'$(TEST_HC)' $(TEST_HC_OPTS) --print-libdir | tr -d '\r'`" > ... > > so ghcApi.o is getting removed before the final link step, I would guess. > > Regards, > Reid Barton From eir at cis.upenn.edu Tue Sep 2 08:20:36 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Tue, 2 Sep 2014 10:20:36 +0200 Subject: PROPOSAL: Make Data.Type.Bool.If polykinded In-Reply-To: <83E4E7CC-3488-4ED0-BDB3-1CDF408187FA@inconsistent.nl> References: <83E4E7CC-3488-4ED0-BDB3-1CDF408187FA@inconsistent.nl> Message-ID: Hi Merijn, I believe that `If` is already the way you want: ?> :k If If :: Bool -> k -> k -> k The problem in your code is that GHC is a little... er... unprincipled about the kind of `()`. It basically assumes that `()` is of kind `*` unless it is very, absolutely, abundantly obvious that it should have kind `Constraint`. Your code is not abundantly obvious enough in this regard. If you say `If cond (() :: Constraint) (...) => ...`, I believe your code will work. Does this in fact work for you? Richard On Sep 1, 2014, at 11:41 PM, Merijn Verstraaten wrote: > Ola! > > Currently we have: > > type family If cond tru fls where > If True tru fls = tru > If False tru fls = fls > > Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it?s impossible to do > > foo :: If cond () (?Condition does not hold? ~ ??) => Foo -> Bar > > or similar fancy constraints. > > I hereby propose altering If to: > > type family If (cond :: Bool) (tru :: k) (fls :: k) :: k where > If True tru fls = tru > If False tru fls = fls > > Allowing it to work with kinds other than *. > > Discussion period: 2 weeks? Seems like a minor change. > > Cheers, > Merijn > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From marlowsd at gmail.com Tue Sep 2 08:30:57 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 02 Sep 2014 10:30:57 +0200 Subject: [Haskell] ANNOUNCE: GHC version 7.8.3 In-Reply-To: References: <917BB1CE-5AB4-4F67-881A-60B375E1DEEA@serpentine.com> <54041FB4.7050608@gmail.com> Message-ID: <54058041.70300@gmail.com> On 01/09/2014 12:30, Sven Panne wrote: > 2014-09-01 9:26 GMT+02:00 Simon Marlow : >> Hi Sven - you would need to compile the module with -dynamic or -dynamic-too >> to have it be picked up by the new dynamically-linked GHCi in 7.8. > > Ah, OK... Adding -dynamic makes this work, but with -dynamic-too, ghci > still loads the interpreted version. I didn't follow the linking story > in detail, so this is all a bit confusing. I think that at least > http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/ghci-compiled.html > needs some update, because as it is, it doesn't reflect reality. Yes, -dynamic-too doesn't work: https://ghc.haskell.org/trac/ghc/ticket/8736 You're right about the docs, I'll take a look at fixing that. Cheers, Simon From mail at joachim-breitner.de Tue Sep 2 08:42:08 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 02 Sep 2014 10:42:08 +0200 Subject: Proposal: run GHC API tests on fast In-Reply-To: <1409641685-sup-502@sabre> References: <1401411058-sup-8260@sabre> <1408726908-sup-9449@sabre> <1408805088.2033.3.camel@joachim-breitner.de> <1408816584-sup-9084@sabre> <1408816742.4687.2.camel@joachim-breitner.de> <1409641685-sup-502@sabre> Message-ID: <1409647328.2223.0.camel@joachim-breitner.de> Hi, Am Dienstag, den 02.09.2014, 09:08 +0200 schrieb Edward Z.Yang: > I pushed a fix for the tests in ghc-api. thanks! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From marek.28.93 at gmail.com Tue Sep 2 09:26:18 2014 From: marek.28.93 at gmail.com (Marek Wawrzos) Date: Tue, 2 Sep 2014 11:26:18 +0200 Subject: Problems with building GHC 7.8.3 on Windows In-Reply-To: <5400A34C.5030401@mail.ru> References: <5400A34C.5030401@mail.ru> Message-ID: I have finally builded GHC 7.8.3 on Windows. The wiki page with MSYS2 that you linked to proved to be useful reference. Indeed using the latest 64 bit MSYS2 as building environment solved my problems. However there are some issues with the instructions presented: -- the MSYS2 package that is linked to in the page fails to initial update. Using the latest official MSYS2 package does solve that ( https://sourceforge.net/projects/msys2/files/Base/x86_64 ); -- initial update has to be done along the instructions from http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ ; There are some error outputs during initial update but they do not seem to cause any harm I thing it might be a good idea to give stronger encouragement to use MSYS2 on the page with Windows-specific instructions. It suggests that old MSYS can be used successfully while it apparently fails and is not supported. 2014-08-29 17:59 GMT+02:00 kyra : > 1. I see you've set ticket's 'Architecture' field to be 'x86_64' while > make output suggests you try to build 32-bit ghc. > > 2. You are using 'old' MSys which is known to be problematic when building > GHC. It's much better to use MSYS2 now: https://ghc.haskell.org/trac/ > ghc/wiki/Building/Preparation/Windows/MSYS2. > > Also, remember, MSYS2 is only a *build environment*, so you can use 64-bit > MSYS2 to build 32-bit GHC on 64-bit Windows. My experience is that 64-bit > MSYS2 is more solid and stable than 32-bit MSYS2. And it's extremely > important to remember you must *not* use msys2_shell.bat to start MSYS2 > shell, only mingwXX_shell.bat (XX stands for 32 or 64) shall be used to > start MSYS2 shell -- otherwise GHC make system would not recognize build > triplet. > > Cheers, > Kyra > > > > On 8/29/2014 17:50, Marek Wawrzos wrote: > >> Hello, >> >> I am trying to compile GHC 7.8.3 on Windows. I was following the >> instructions from the GHC wiki, but I have encountered errors during the >> make process. >> >> I have filed a bug report describing my issue: >> https://ghc.haskell.org/trac/ghc/ticket/9513 >> >> Does anyone had working setup for building GHC and would be willing to >> share information on how to achieve it? >> >> -- >> Best regards, >> Marek Wawrzos >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Z powa?aniem, Marek Wawrzos -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Sep 2 12:07:05 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 02 Sep 2014 14:07:05 +0200 Subject: wORD_SIZE vs platformWordSize of targetPlatform In-Reply-To: References: Message-ID: <5405B2E9.6040401@gmail.com> On 08/08/2014 13:15, Johan Tibell wrote: > We seem to have two ways to get the same piece of information. We can > get the target (?) word size as wORD_SIZE but there's also the > platformWordSize field in the Platform data type, which is held as > targetPlatform in DynFlags. Which one should I use? Most code uses > wORD_SIZE. We should kill one or the other, probably platformWordSize. Cheers, Simon From kazu at iij.ad.jp Wed Sep 3 05:48:13 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 03 Sep 2014 14:48:13 +0900 (JST) Subject: deriving Bits Message-ID: <20140903.144813.1241744461502200301.kazu@iij.ad.jp> Hi, Recently, I found that we can put Bits in "deriving". I checked the GHC manual but it seems to me that this page does not cover Bits: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/deriving.html Are there any other classes which can be automatically derived and are not listed in this page? If the number of such classes is not large, how about adding them to this page? --Kazu From simonpj at microsoft.com Wed Sep 3 06:22:48 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Sep 2014 06:22:48 +0000 Subject: deriving Bits In-Reply-To: <20140903.144813.1241744461502200301.kazu@iij.ad.jp> References: <20140903.144813.1241744461502200301.kazu@iij.ad.jp> Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F91A2@DB3PRD3001MB020.064d.mgd.msft.net> Can you give an example? GHC has no specific code for Bits as far as I know. Perhaps you are using GeneralisedNewtypeDeriving? You don't give enough context to say. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Kazu | Yamamoto | Sent: 03 September 2014 06:48 | To: ghc-devs at haskell.org | Subject: deriving Bits | | Hi, | | Recently, I found that we can put Bits in "deriving". I checked the | GHC manual but it seems to me that this page does not cover Bits: | | https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/deriving.h | tml | | Are there any other classes which can be automatically derived and are | not listed in this page? | | If the number of such classes is not large, how about adding them to | this page? | | --Kazu | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From kazu at iij.ad.jp Wed Sep 3 06:34:38 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 03 Sep 2014 15:34:38 +0900 (JST) Subject: deriving Bits In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221F91A2@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140903.144813.1241744461502200301.kazu@iij.ad.jp> <618BE556AADD624C9C918AA5D5911BEF221F91A2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140903.153438.1697744323885007356.kazu@iij.ad.jp> Hi Simon, > Can you give an example? GHC has no specific code for Bits as far > as I know. Perhaps you are using GeneralisedNewtypeDeriving? You > don't give enough context to say. Yes, I'm using GeneralisedNewtypeDeriving. So, my question should be: Are there any other classes which can be automatically derived if GeneralisedNewtypeDeriving is specified and are not listed in this page? --Kazu From simonpj at microsoft.com Wed Sep 3 06:37:35 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Sep 2014 06:37:35 +0000 Subject: deriving Bits In-Reply-To: <20140903.153438.1697744323885007356.kazu@iij.ad.jp> References: <20140903.144813.1241744461502200301.kazu@iij.ad.jp> <618BE556AADD624C9C918AA5D5911BEF221F91A2@DB3PRD3001MB020.064d.mgd.msft.net> <20140903.153438.1697744323885007356.kazu@iij.ad.jp> Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F920B@DB3PRD3001MB020.064d.mgd.msft.net> As the GND documentation says, it works for ANY class. So we can't list them! It works for classes you define and we don't know about. Here is the documentation: http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#newtype-deriving Simon | -----Original Message----- | From: Kazu Yamamoto [mailto:kazu at iij.ad.jp] | Sent: 03 September 2014 07:35 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: deriving Bits | | Hi Simon, | | > Can you give an example? GHC has no specific code for Bits as far | > as I know. Perhaps you are using GeneralisedNewtypeDeriving? You | > don't give enough context to say. | | Yes, I'm using GeneralisedNewtypeDeriving. So, my question should be: | | Are there any other classes which can be automatically derived if | GeneralisedNewtypeDeriving is specified and are not listed in this | page? | | --Kazu From kazu at iij.ad.jp Wed Sep 3 06:54:48 2014 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 03 Sep 2014 15:54:48 +0900 (JST) Subject: deriving Bits In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221F920B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF221F91A2@DB3PRD3001MB020.064d.mgd.msft.net> <20140903.153438.1697744323885007356.kazu@iij.ad.jp> <618BE556AADD624C9C918AA5D5911BEF221F920B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140903.155448.2145881732257823588.kazu@iij.ad.jp> Simon, > As the GND documentation says, it works for ANY class. So we can't > list them! Understand. Thanks. --Kazu From merijn at inconsistent.nl Wed Sep 3 17:16:53 2014 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Wed, 3 Sep 2014 10:16:53 -0700 Subject: PROPOSAL: Make Data.Type.Bool.If polykinded In-Reply-To: References: <83E4E7CC-3488-4ED0-BDB3-1CDF408187FA@inconsistent.nl> Message-ID: <8D77DDD4-46BF-4BA3-9D9B-2B987736D0E6@inconsistent.nl> Hi Richard, It would appear that you?re right! I had expected GHC to infer the kind Constraint for () from the second argument, rather than reporting an error, but adding an explicit annotation works. I would still say that warrants a clearer error message from GHC, but at least it works :) Cheers, Merijn On 02 Sep 2014, at 01:20 , Richard Eisenberg wrote: > Hi Merijn, > > I believe that `If` is already the way you want: > > ?> :k If > If :: Bool -> k -> k -> k > > The problem in your code is that GHC is a little... er... unprincipled about the kind of `()`. It basically assumes that `()` is of kind `*` unless it is very, absolutely, abundantly obvious that it should have kind `Constraint`. Your code is not abundantly obvious enough in this regard. If you say `If cond (() :: Constraint) (...) => ...`, I believe your code will work. > > Does this in fact work for you? > > Richard > > On Sep 1, 2014, at 11:41 PM, Merijn Verstraaten wrote: > >> Ola! >> >> Currently we have: >> >> type family If cond tru fls where >> If True tru fls = tru >> If False tru fls = fls >> >> Unfortunately, this appears to turned into a monomorphicly kinded type family by GHC, which means it?s impossible to do >> >> foo :: If cond () (?Condition does not hold? ~ ??) => Foo -> Bar >> >> or similar fancy constraints. >> >> I hereby propose altering If to: >> >> type family If (cond :: Bool) (tru :: k) (fls :: k) :: k where >> If True tru fls = tru >> If False tru fls = fls >> >> Allowing it to work with kinds other than *. >> >> Discussion period: 2 weeks? Seems like a minor change. >> >> Cheers, >> Merijn >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mail at joachim-breitner.de Wed Sep 3 19:47:25 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Sep 2014 21:47:25 +0200 Subject: Extending fold/build fusion In-Reply-To: <1394649376.12060.12.camel@kirk> References: <1390932396.2641.46.camel@kirk> <1391159897.3184.10.camel@kirk> <1392029440.7172.2.camel@kirk> <1394649376.12060.12.camel@kirk> Message-ID: <1409773645.1805.2.camel@joachim-breitner.de> Dear Akio, Am Mittwoch, den 12.03.2014, 19:36 +0100 schrieb Joachim Breitner: > Dear Akio, > > Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano: > > I modified the base library to use foldrW/buildW, with no changes to > > foldl yet. nofib showed a very big regression in cryptarithm2, so I'm > > looking into it. > > any news on this front? Did you find out what happened in cryptarithm2? > Do you need help with that? I haven?t heard from you in quite some time. Are you still on this project? Recent investigations into fusion by David Feuer has increased interest in your approach (https://ghc.haskell.org/trac/ghc/ticket/9545). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Wed Sep 3 20:28:58 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 3 Sep 2014 15:28:58 -0500 Subject: Problems with building GHC 7.8.3 on Windows In-Reply-To: References: <5400A34C.5030401@mail.ru> Message-ID: Thanks for the input Marek. I kept the pages separate at first because it wasn't clear if we wanted to buy into MSYS2 - hence why it's on a separate page. I think it's proven itself enough that we can now move the pages around - making the current page a 'legacy only' page, and moving the MSYS2 docs to the forefront. On Tue, Sep 2, 2014 at 4:26 AM, Marek Wawrzos wrote: > I have finally builded GHC 7.8.3 on Windows. The wiki page with MSYS2 that > you linked to proved to be useful reference. Indeed using the latest 64 bit > MSYS2 as building environment solved my problems. However there are some > issues with the instructions presented: > -- the MSYS2 package that is linked to in the page fails to initial update. > Using the latest official MSYS2 package does solve that ( > https://sourceforge.net/projects/msys2/files/Base/x86_64 ); > -- initial update has to be done along the instructions from > http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ ; > There are some error outputs during initial update but they do not seem to > cause any harm > I thing it might be a good idea to give stronger encouragement to use MSYS2 > on the page with Windows-specific instructions. It suggests that old MSYS > can be used successfully while it apparently fails and is not supported. > > > 2014-08-29 17:59 GMT+02:00 kyra : >> >> 1. I see you've set ticket's 'Architecture' field to be 'x86_64' while >> make output suggests you try to build 32-bit ghc. >> >> >> 2. You are using 'old' MSys which is known to be problematic when building >> GHC. It's much better to use MSYS2 now: >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. >> >> Also, remember, MSYS2 is only a *build environment*, so you can use 64-bit >> MSYS2 to build 32-bit GHC on 64-bit Windows. My experience is that 64-bit >> MSYS2 is more solid and stable than 32-bit MSYS2. And it's extremely >> important to remember you must *not* use msys2_shell.bat to start MSYS2 >> shell, only mingwXX_shell.bat (XX stands for 32 or 64) shall be used to >> start MSYS2 shell -- otherwise GHC make system would not recognize build >> triplet. >> >> Cheers, >> Kyra >> >> >> >> On 8/29/2014 17:50, Marek Wawrzos wrote: >>> >>> Hello, >>> >>> I am trying to compile GHC 7.8.3 on Windows. I was following the >>> instructions from the GHC wiki, but I have encountered errors during the >>> make process. >>> >>> I have filed a bug report describing my issue: >>> https://ghc.haskell.org/trac/ghc/ticket/9513 >>> >>> Does anyone had working setup for building GHC and would be willing to >>> share information on how to achieve it? >>> >>> -- >>> Best regards, >>> Marek Wawrzos >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > -- > Z powa?aniem, > Marek Wawrzos > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Wed Sep 3 20:31:03 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 3 Sep 2014 15:31:03 -0500 Subject: Status updates Message-ID: Hi *, Here are some status updates for the past week, which have been a bit light. - I spent a bunch of time code reviewing things and merging patches this week. There are still things in Phabricator that need some review, so please review them if you get a chance! You will probably learn things and learning things is good. [1] - I spent more time getting a Windows builder working, and talking with upstream about it. I believe it should Basically Work, but unfortunately the changes for this have not gone upstream yet, so it will probably be a week or two before I can officially do that - I have spent some time fixing some bugs, and I'm posting a review for some shortly, notably 7602! Unrelated to what I in particular am doing Right Now: - I would still _really_ like help with the Applicative Monad patch; I haven't touched it much. Please pester me if you have some cycles to spare. Or just helping me brainstorm would be really really useful![2] - After some minor instability in the tree earlier this week (test failures), everything is back to normal (Thanks to Edward & Simon). Please ping here if you're still having trouble on your machine. - I still think we should turn on --slow mode for our buildbots soon, but this will cause noise. I'd really like some inputs on this - maybe someone would like to help clean up the 'slow' vaildate failures? Bonus points for this, since you don't even have to - Gabor Pali & I had a minor discussion this last week about fixing nightly documentation snapshots. We've had complaints about this in the past and the prior system totally disappeared, so it will be really nice to fix this! Binary snapshots should be possible too, but documentation is perhaps the more key thing. A little work is necessary for this though, and my time is limited as always. Please let me know if you'd like to help with this, and I'll pull you into the loop with Gabor so can tackle this. ---------------------------- I've probably forgotten some things other people have done the past week, including myself. If you have any questions, suggestions, or want to pop in on this email and say something, you should. :) [1] https://phabricator.haskell.org/differential/ [2] https://phabricator.haskell.org/D13 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Wed Sep 3 20:33:53 2014 From: austin at well-typed.com (Austin Seipp) Date: Wed, 3 Sep 2014 15:33:53 -0500 Subject: Status updates In-Reply-To: References: Message-ID: On Wed, Sep 3, 2014 at 3:31 PM, Austin Seipp wrote: > - I still think we should turn on --slow mode for our buildbots soon, > but this will cause noise. I'd really like some inputs on this - maybe > someone would like to help clean up the 'slow' vaildate failures? > Bonus points for this, since you don't even have to Hmmm, I accidentally the rest of this paragraph. To finish: Bonus points here, since you can leave most of the 'heavy lifting' to phabricator. I can just turn on --slow mode, you submit a patch, and Phabricator tells you if it works. :) And if you'd like to fix some problems but are shy, this might be a good place to start! (Tests are small, self contained, and should be easy to follow via the bug tracker - there shouldn't be *too* much to wade through to get started.) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From pali.gabor at gmail.com Wed Sep 3 20:47:55 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Wed, 3 Sep 2014 22:47:55 +0200 Subject: Status updates In-Reply-To: References: Message-ID: 2014-09-03 22:31 GMT+02:00 Austin Seipp : > - Gabor Pali & I had a minor discussion this last week about fixing > nightly documentation snapshots. We've had complaints about this in > the past and the prior system totally disappeared, so it will be > really nice to fix this! Binary snapshots should be possible too, but > documentation is perhaps the more key thing. I have not followed up on it, but for your information, I have started building and publishing snapshots for the GHC documentation here: http://haskell.inf.elte.hu/docs/ It is based on the snapshots provided by the builders I have and it uses a script that is derived from the mkDocs utility in the source tree (under "distrib"). As a consequence, the method is a bit fragile, as it needs at least a Windows and non-Windows build to be built in order to extract and combine the files from them. Unfortunately, my Windows builders are not fully stable yet, although they deemed to be usable enough mostly. From simonpj at microsoft.com Wed Sep 3 20:54:13 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 3 Sep 2014 20:54:13 +0000 Subject: Status updates In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF221F983C@DB3PRD3001MB020.064d.mgd.msft.net> That's great! Austin, can you fix the links on http://www.haskell.org/haskellwiki/GHC so that the "current HEAD snapshot" link (currently dead) points to the right place? thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of P?li | G?bor J?nos | Sent: 03 September 2014 21:48 | To: Austin Seipp | Cc: ghc-devs at haskell.org | Subject: Re: Status updates | | 2014-09-03 22:31 GMT+02:00 Austin Seipp : | > - Gabor Pali & I had a minor discussion this last week about fixing | > nightly documentation snapshots. We've had complaints about this in | > the past and the prior system totally disappeared, so it will be | > really nice to fix this! Binary snapshots should be possible too, but | > documentation is perhaps the more key thing. | | I have not followed up on it, but for your information, I have started | building and publishing snapshots for the GHC documentation here: | | http://haskell.inf.elte.hu/docs/ | | It is based on the snapshots provided by the builders I have and it | uses a script that is derived from the mkDocs utility in the source | tree (under "distrib"). As a consequence, the method is a bit | fragile, as it needs at least a Windows and non-Windows build to be | built in order to extract and combine the files from them. | Unfortunately, my Windows builders are not fully stable yet, although | they deemed to be usable enough mostly. | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From marlowsd at gmail.com Thu Sep 4 08:56:40 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Sep 2014 10:56:40 +0200 Subject: Can Phabricator be made to understand git better? In-Reply-To: References: Message-ID: <54082948.1070201@gmail.com> You normally want to do "arc diff HEAD^" in my experience. I believe you get to choose this to be the default when you initialize arc the first time, and I set it to HEAD^ for my arc. I'm not sure if you can change the default later, but you can always say "arc diff HEAD^". Cheers, Simon On 10/08/2014 12:17, Johan Tibell wrote: > Hi, > > I have to fight Phab too much because it doesn't understand git or git > working conventions very well. For example, the other day I uploaded > https://phabricator.haskell.org/D128, built from a single git commit on > a feature branch I made on a local feature branch (based on my local > master). > > First, doing that was in itself a bit of a pain. 'arc diff' didn't do > the right thing and included some random commit(s) instead of my single > commit in my feature branch. Perhaps it tried to diff against > origin/master or something, which doesn't make any sense if you know how > git is meant to be used (doing that would imply that you have to > constantly sync with upstream to create a patch.) I eventually got it to > used the right commit by doing 'arc diff `. > > Second, today when I wanted to update my commit to address some review > comments I 1) amended my commit in my feature branch and 2) ran 'arc > diff', expecting that it would do the right thing. It didn't and now > D128 contains a bunch of changes that aren't mine. I don't know where > they came from. > > Is there a way to configure Phab so it works with git established workflows? > > -- Johan > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Thu Sep 4 09:04:03 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Sep 2014 11:04:03 +0200 Subject: Can Phabricator be made to understand git better? In-Reply-To: <54082948.1070201@gmail.com> References: <54082948.1070201@gmail.com> Message-ID: <54082B03.1070602@gmail.com> I think this should set the default for you: arc set-config base "git:HEAD^" see https://secure.phabricator.com/book/phabricator/article/arcanist_commit_ranges/ Cheers, Simon On 04/09/2014 10:56, Simon Marlow wrote: > You normally want to do "arc diff HEAD^" in my experience. I believe > you get to choose this to be the default when you initialize arc the > first time, and I set it to HEAD^ for my arc. I'm not sure if you can > change the default later, but you can always say "arc diff HEAD^". > > Cheers, > Simon > > On 10/08/2014 12:17, Johan Tibell wrote: >> Hi, >> >> I have to fight Phab too much because it doesn't understand git or git >> working conventions very well. For example, the other day I uploaded >> https://phabricator.haskell.org/D128, built from a single git commit on >> a feature branch I made on a local feature branch (based on my local >> master). >> >> First, doing that was in itself a bit of a pain. 'arc diff' didn't do >> the right thing and included some random commit(s) instead of my single >> commit in my feature branch. Perhaps it tried to diff against >> origin/master or something, which doesn't make any sense if you know how >> git is meant to be used (doing that would imply that you have to >> constantly sync with upstream to create a patch.) I eventually got it to >> used the right commit by doing 'arc diff `. >> >> Second, today when I wanted to update my commit to address some review >> comments I 1) amended my commit in my feature branch and 2) ran 'arc >> diff', expecting that it would do the right thing. It didn't and now >> D128 contains a bunch of changes that aren't mine. I don't know where >> they came from. >> >> Is there a way to configure Phab so it works with git established >> workflows? >> >> -- Johan >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> From marlowsd at gmail.com Thu Sep 4 09:49:39 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Sep 2014 11:49:39 +0200 Subject: Unique as special boxing type & hidden constructors In-Reply-To: <1408104042-sup-2896@sabre> References: <13aaa2dd98944a3e95cc03c5139fbbb7@EXMBX31.ad.utwente.nl> <1408104042-sup-2896@sabre> Message-ID: <540835B3.30408@gmail.com> FastInt = Int#, so newtype doesn't work here. Cheers, Simon On 15/08/2014 14:01, Edward Z. Yang wrote: > The definition dates back to 1996, so it seems plausible that > newtype is the way to go now. > > Edward > > Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100: >> Dear all, >> >> >> I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. >> >> Right now, I'm looking at Unique and two questions come up: >> >>> data Unique = MkUnique FastInt >> >> >> 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? >> >> >> 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? >> >> I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): >> >>> getKeyFastInt (MkUnique x) = x >> >>> mkUniqueGrimily x = MkUnique (iUnbox x) >> >> >> I would propose to just make Unique a newtype for an Int and making the constructor visible. >> >> >> Regards, >> >> Philip > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From ezyang at mit.edu Thu Sep 4 09:54:29 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 04 Sep 2014 11:54:29 +0200 Subject: Unique as special boxing type & hidden constructors In-Reply-To: <540835B3.30408@gmail.com> References: <13aaa2dd98944a3e95cc03c5139fbbb7@EXMBX31.ad.utwente.nl> <1408104042-sup-2896@sabre> <540835B3.30408@gmail.com> Message-ID: <1409824450-sup-6760@sabre> Newtype of Int, to be clear. Edward Excerpts from Simon Marlow's message of 2014-09-04 11:49:39 +0200: > FastInt = Int#, so newtype doesn't work here. > > Cheers, > Simon > > On 15/08/2014 14:01, Edward Z. Yang wrote: > > The definition dates back to 1996, so it seems plausible that > > newtype is the way to go now. > > > > Edward > > > > Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100: > >> Dear all, > >> > >> > >> I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. > >> > >> Right now, I'm looking at Unique and two questions come up: > >> > >>> data Unique = MkUnique FastInt > >> > >> > >> 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? > >> > >> > >> 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? > >> > >> I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): > >> > >>> getKeyFastInt (MkUnique x) = x > >> > >>> mkUniqueGrimily x = MkUnique (iUnbox x) > >> > >> > >> I would propose to just make Unique a newtype for an Int and making the constructor visible. > >> > >> > >> Regards, > >> > >> Philip > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > From alexander at plaimi.net Thu Sep 4 11:01:15 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 04 Sep 2014 13:01:15 +0200 Subject: Copyright headers etc. Message-ID: <5408467B.7040302@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We should probably do something about copyright headers. They're all very out of date and basically useless. I suggest just having a CONTRIBUTORS file with one name per line, and pointing to that in the files. But IANAL, and copyright is complicated, so other ideas are welcome. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQIRnsACgkQRtClrXBQc7XDlAD/TEAkGaXPD3jzTDxOYVlyCSwP RIMvBcKuJqZvX+atIOMA/A4e4yuy5QIy9YR7U50jdZVK63fONkFyXa6iTYwuxTCE =rVWx -----END PGP SIGNATURE----- From p.k.f.holzenspies at utwente.nl Thu Sep 4 11:25:15 2014 From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl) Date: Thu, 4 Sep 2014 11:25:15 +0000 Subject: Unique as special boxing type & hidden constructors In-Reply-To: <540835B3.30408@gmail.com> References: <13aaa2dd98944a3e95cc03c5139fbbb7@EXMBX31.ad.utwente.nl> <1408104042-sup-2896@sabre>,<540835B3.30408@gmail.com> Message-ID: <61add7797f05486788905e1996186201@EXMBX31.ad.utwente.nl> Dear Simon, The point is to have newtype Unique = Unique Int where we use the boxing of Int, instead of creating our own boxing. Actually, it seems useful to move to newtype Unique = Unique Word (see other discussions about unnecessary signedness). I've been working on this (although only as a side-project, so progress is very slow) and I've discovered a lot of API-out-of-sync-ness; there are comments stating we don't export mkUnique, so that we can keep track of all the Chars we use. Unfortunately, we *do* export mkUnique from Unique and we do *not* have consistent use of Chars everywhere. I'm working to replace the Char-mechanism with a (rather straightforward) sum-type UniqueDomain. This should also help get a more consistent treatment of serialisation (the one in the module Unique is *slightly* different from the one in BinIface). I'm still not quite sure how to do the performance tests on the actual compilation (i.e. runtime of GHC itself). If anything, moving Uniques to a higher abstraction (coerced boxed values, instead of manually boxed stuff) is actually a good litmus test of how far GHC's optimisations have come since '96 ;) If you have any more input, especially on performance stuff (what would be the worst acceptable performance hit and measured on what, for example), it would be *very* welcome! Regards, Philip ________________________________________ From: Simon Marlow Sent: 04 September 2014 11:49 To: Edward Z. Yang; Holzenspies, P.K.F. (EWI) Cc: ghc-devs Subject: Re: Unique as special boxing type & hidden constructors FastInt = Int#, so newtype doesn't work here. Cheers, Simon On 15/08/2014 14:01, Edward Z. Yang wrote: > The definition dates back to 1996, so it seems plausible that > newtype is the way to go now. > > Edward > > Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100: >> Dear all, >> >> >> I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. >> >> Right now, I'm looking at Unique and two questions come up: >> >>> data Unique = MkUnique FastInt >> >> >> 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? >> >> >> 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? >> >> I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): >> >>> getKeyFastInt (MkUnique x) = x >> >>> mkUniqueGrimily x = MkUnique (iUnbox x) >> >> >> I would propose to just make Unique a newtype for an Int and making the constructor visible. >> >> >> Regards, >> >> Philip > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From marlowsd at gmail.com Thu Sep 4 14:39:34 2014 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 04 Sep 2014 16:39:34 +0200 Subject: Unique as special boxing type & hidden constructors In-Reply-To: <61add7797f05486788905e1996186201@EXMBX31.ad.utwente.nl> References: <13aaa2dd98944a3e95cc03c5139fbbb7@EXMBX31.ad.utwente.nl> <1408104042-sup-2896@sabre>, <540835B3.30408@gmail.com> <61add7797f05486788905e1996186201@EXMBX31.ad.utwente.nl> Message-ID: <540879A6.5030404@gmail.com> On 04/09/2014 13:25, p.k.f.holzenspies at utwente.nl wrote: > Dear Simon, > > The point is to have > > newtype Unique = Unique Int Yes, I misunderstood, thanks! > where we use the boxing of Int, instead of creating our own boxing. Actually, it seems useful to move to > > newtype Unique = Unique Word > > (see other discussions about unnecessary signedness). > > I've been working on this (although only as a side-project, so progress is very slow) and I've discovered a lot of API-out-of-sync-ness; there are comments stating we don't export mkUnique, so that we can keep track of all the Chars we use. Unfortunately, we *do* export mkUnique from Unique and we do *not* have consistent use of Chars everywhere. I'm working to replace the Char-mechanism with a (rather straightforward) sum-type UniqueDomain. This should also help get a more consistent treatment of serialisation (the one in the module Unique is *slightly* different from the one in BinIface). > > I'm still not quite sure how to do the performance tests on the actual compilation (i.e. runtime of GHC itself). If anything, moving Uniques to a higher abstraction (coerced boxed values, instead of manually boxed stuff) is actually a good litmus test of how far GHC's optimisations have come since '96 ;) > > If you have any more input, especially on performance stuff (what would be the worst acceptable performance hit and measured on what, for example), it would be *very* welcome! There are compiler performance tests in testsuite/tests/perf/compiler. They will only fail if the performance gets worse by 10% or so (depending on the test), so instead of checking for failure just run the tests manually and compare the allocation values before and after your change (remember to save a copy of the original compiler binary so that you can do comparisons). Another way to test performance is to compile a large module, e.g. nofib/spectral/simple/Main.hs is a good one. Cheers, Simon > Regards, > Philip > > > > ________________________________________ > From: Simon Marlow > Sent: 04 September 2014 11:49 > To: Edward Z. Yang; Holzenspies, P.K.F. (EWI) > Cc: ghc-devs > Subject: Re: Unique as special boxing type & hidden constructors > > FastInt = Int#, so newtype doesn't work here. > > Cheers, > Simon > > On 15/08/2014 14:01, Edward Z. Yang wrote: >> The definition dates back to 1996, so it seems plausible that >> newtype is the way to go now. >> >> Edward >> >> Excerpts from p.k.f.holzenspies's message of 2014-08-15 11:52:47 +0100: >>> Dear all, >>> >>> >>> I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. >>> >>> Right now, I'm looking at Unique and two questions come up: >>> >>>> data Unique = MkUnique FastInt >>> >>> >>> 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? >>> >>> >>> 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? >>> >>> I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): >>> >>>> getKeyFastInt (MkUnique x) = x >>> >>>> mkUniqueGrimily x = MkUnique (iUnbox x) >>> >>> >>> I would propose to just make Unique a newtype for an Int and making the constructor visible. >>> >>> >>> Regards, >>> >>> Philip >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > From carter.schonwald at gmail.com Thu Sep 4 17:30:50 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 4 Sep 2014 19:30:50 +0200 Subject: Copyright headers etc. In-Reply-To: <5408467B.7040302@plaimi.net> References: <5408467B.7040302@plaimi.net> Message-ID: I'm happy to double check with the several IP lawyers in my family, but that's totally not needed. :-) On Sep 4, 2014 1:01 PM, "Alexander Berntsen" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > We should probably do something about copyright headers. They're all > very out of date and basically useless. > > I suggest just having a CONTRIBUTORS file with one name per line, and > pointing to that in the files. But IANAL, and copyright is > complicated, so other ideas are welcome. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQIRnsACgkQRtClrXBQc7XDlAD/TEAkGaXPD3jzTDxOYVlyCSwP > RIMvBcKuJqZvX+atIOMA/A4e4yuy5QIy9YR7U50jdZVK63fONkFyXa6iTYwuxTCE > =rVWx > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Thu Sep 4 21:20:46 2014 From: dan.doel at gmail.com (Dan Doel) Date: Thu, 4 Sep 2014 17:20:46 -0400 Subject: Extending fold/build fusion In-Reply-To: <1409773645.1805.2.camel@joachim-breitner.de> References: <1390932396.2641.46.camel@kirk> <1391159897.3184.10.camel@kirk> <1392029440.7172.2.camel@kirk> <1394649376.12060.12.camel@kirk> <1409773645.1805.2.camel@joachim-breitner.de> Message-ID: I've been looking into this a bit in the past day or so, and I feel like some of the stuff in the repository doesn't make sense (to me, at least). For instance, if you start examining the generated code, you'll see quirks like, taking map as an example: map f xs = go xs [] where go xs n = case xs of [] -> n y:ys -> f y : go ys n In other words, the loop passes along the empty list in an argument for the base case, which is a waste. This stems from the definition of foldrW: foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' Specifically, the z' becomes this extra threaded argument, and never disappears. It is possible to fix this by changing the definition of foldrW to be: ... [] -> z0 ... And ghc then recognizes that the z' being threaded is useless and eliminates it. But this raises the question of why it's being threaded this way in the first place. It seems like the types in Wrap are inappropriate in some way, at least for the general case. But I'm not yet certain what they should be. There are also fusion problems with the current implementation that neither I nor David have fully figured out yet. For instance: bar = map (+1) (eft 0 1000) does not fuse, even after trying many tweaks to the definitions (due to the eft 0 1000 being pulled out into a let for reasons we don't yet understand; it even happens with -fno-full-laziness). However: bar = foldl (+) 0 (map (+1) (eft 0 1000)) fuses fully. The only way to fix the former I've yet found is making buildW CONLIKE, but that may not be appropriate in general (probably isn't). I have a sneaking suspicion that the strangeness mentioned in the first part of this mail may be a contributing factor to this latter issue, too. -- Dan On Wed, Sep 3, 2014 at 3:47 PM, Joachim Breitner wrote: > Dear Akio, > > > Am Mittwoch, den 12.03.2014, 19:36 +0100 schrieb Joachim Breitner: > > Dear Akio, > > > > Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano: > > > I modified the base library to use foldrW/buildW, with no changes to > > > foldl yet. nofib showed a very big regression in cryptarithm2, so I'm > > > looking into it. > > > > any news on this front? Did you find out what happened in cryptarithm2? > > Do you need help with that? > > I haven?t heard from you in quite some time. Are you still on this > project? > > Recent investigations into fusion by David Feuer has increased interest > in your approach (https://ghc.haskell.org/trac/ghc/ticket/9545). > > Greetings, > Joachim > > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 5 06:43:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 5 Sep 2014 06:43:05 +0000 Subject: slow Trac Message-ID: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> Is it my imagination or is Trac taking ages to render pages at the moment? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Sep 5 06:52:20 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 5 Sep 2014 01:52:20 -0500 Subject: slow Trac In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Yes. It seems to be OK for me (for now). The servers have been experiencing a lot of high load today on their parent virtualization host, and I've been investigating to try and tone it down, but to not much avail yet. I'll keep everyone posted (and I've updated status.haskell.org). On Fri, Sep 5, 2014 at 1:43 AM, Simon Peyton Jones wrote: > Is it my imagination or is Trac taking ages to render pages at the moment? > > Simon -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mikolaj at well-typed.com Fri Sep 5 07:00:24 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Fri, 5 Sep 2014 09:00:24 +0200 Subject: slow Trac In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > status.haskell.org Yay, that's neat. > I'll keep everyone posted Thank you, Austin. From dan.doel at gmail.com Fri Sep 5 08:10:28 2014 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 5 Sep 2014 04:10:28 -0400 Subject: Extending fold/build fusion In-Reply-To: References: <1390932396.2641.46.camel@kirk> <1391159897.3184.10.camel@kirk> <1392029440.7172.2.camel@kirk> <1394649376.12060.12.camel@kirk> <1409773645.1805.2.camel@joachim-breitner.de> Message-ID: To answer myself some after having fiddled with this more.... The failure-to-fuse is apparently only an issue if I put the fusible thing in the same module as the combinators, for reasons I can't explain. If a separate module imports and defines bar, things fuse fine. I'm still not sure what to do about the weird nil-passing definitions. I came up with one possibility, which is to create a different build: nilWrap :: b -> Wrap (Simple b) b nilWrap z = Wrap (\(Simple s) e r -> s e r) (\u -> Simple $ \e _ -> u e z) buildPlain :: (forall b f. Wrap f b -> (a -> b -> b) -> b -> b) -> [a] buildPlain g = g (nilWrap []) (:) [] This uses the wrapping to plug in the same nil case at every step, which eliminates the extra argument when used. But, I don't think this is usable. Some definitions are okay with this wrapper, but others aren't, and I believe that foldrW/buildW fusion can cause it to get into places where it isn't okay. For instance, if we use nilWrap in foldr, then: foldr f z (reverse xs) does the wrong thing. On Thu, Sep 4, 2014 at 5:20 PM, Dan Doel wrote: > I've been looking into this a bit in the past day or so, and I feel like > some of the stuff in the repository doesn't make sense (to me, at least). > > For instance, if you start examining the generated code, you'll see quirks > like, taking map as an example: > > map f xs = go xs [] > where > go xs n = case xs of > [] -> n > y:ys -> f y : go ys n > > In other words, the loop passes along the empty list in an argument for > the base case, which is a waste. This stems from the definition of foldrW: > > foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 > where > go = unwrap $ \list z' -> case list of > [] -> z' > x:xs -> f x $ wrap go xs z' > > Specifically, the z' becomes this extra threaded argument, and never > disappears. It is possible to fix this by changing the definition of foldrW > to be: > > ... > [] -> z0 > ... > > And ghc then recognizes that the z' being threaded is useless and > eliminates it. But this raises the question of why it's being threaded this > way in the first place. It seems like the types in Wrap are inappropriate > in some way, at least for the general case. But I'm not yet certain what > they should be. > > There are also fusion problems with the current implementation that > neither I nor David have fully figured out yet. For instance: > > bar = map (+1) (eft 0 1000) > > does not fuse, even after trying many tweaks to the definitions (due to > the eft 0 1000 being pulled out into a let for reasons we don't yet > understand; it even happens with -fno-full-laziness). However: > > bar = foldl (+) 0 (map (+1) (eft 0 1000)) > > fuses fully. The only way to fix the former I've yet found is making > buildW CONLIKE, but that may not be appropriate in general (probably > isn't). I have a sneaking suspicion that the strangeness mentioned in the > first part of this mail may be a contributing factor to this latter issue, > too. > > -- Dan > > > On Wed, Sep 3, 2014 at 3:47 PM, Joachim Breitner > wrote: > >> Dear Akio, >> >> >> Am Mittwoch, den 12.03.2014, 19:36 +0100 schrieb Joachim Breitner: >> > Dear Akio, >> > >> > Am Dienstag, den 11.02.2014, 08:04 +0900 schrieb Akio Takano: >> > > I modified the base library to use foldrW/buildW, with no changes to >> > > foldl yet. nofib showed a very big regression in cryptarithm2, so I'm >> > > looking into it. >> > >> > any news on this front? Did you find out what happened in cryptarithm2? >> > Do you need help with that? >> >> I haven?t heard from you in quite some time. Are you still on this >> project? >> >> Recent investigations into fusion by David Feuer has increased interest >> in your approach (https://ghc.haskell.org/trac/ghc/ticket/9545). >> >> Greetings, >> Joachim >> >> >> -- >> Joachim ?nomeata? Breitner >> mail at joachim-breitner.de ? http://www.joachim-breitner.de/ >> Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Sep 5 08:21:34 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 5 Sep 2014 03:21:34 -0500 Subject: slow Trac In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Update: Trac should be much more responsive now (and Hackage too), but Hackage still needs more investigation. Still ongoing for the moment... On Fri, Sep 5, 2014 at 2:00 AM, Mikolaj Konarski wrote: >> status.haskell.org > > Yay, that's neat. > >> I'll keep everyone posted > > Thank you, Austin. > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From slyich at gmail.com Fri Sep 5 20:03:10 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Fri, 5 Sep 2014 23:03:10 +0300 Subject: validate --slow bugs (was Re: Status updates) In-Reply-To: References: Message-ID: <20140905230310.1cd71e29@sf> On Wed, 3 Sep 2014 15:31:03 -0500 Austin Seipp wrote: > Hi *, > > Here are some status updates for the past week, which have been a bit light. Woot! Great list! > - I still think we should turn on --slow mode for our buildbots soon, > but this will cause noise. I'd really like some inputs on this - maybe > someone would like to help clean up the 'slow' vaildate failures? > Bonus points for this, since you don't even have to That's a great goal, but --slow enables compiler debug assertions, which seem to trigger real errors (full log of failures attached). I've filled tickets for some of those assertion failures. If someone more experienced in the area could guide us hints on how to fix them (CCed Simon PJ). If they all are non-issues please tell and I'll drop them. If they are real bugs I can try to debug them a bit and gather more info (maybe something specific is of interest?). Highlights: *** unexpected failure for T3500b(threaded2) =====> T3500b(dyn) 3766 of 4100 [0, 12, 0] cd ./typecheck/should_run && '/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o T3500b T3500b.hs -O -dynamic >T3500b.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T3500b.hs, T3500b.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140905 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired foldr/augment To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 12441 Is it bad? cd ./ghc-api && $MAKE -s --no-print-directory T8628 T8628.run.stdout 2>T8628.run.stderr Actual stderr output differs from expected: --- /dev/null 2014-08-25 09:46:54.593424088 +0300 +++ ./ghc-api/T8628.run.stderr 2014-09-05 22:49:20.705589132 +0300 @@ -0,0 +1,4 @@ +WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 + Ghci3.$fShowX +WARNING: file compiler/simplCore/SimplEnv.lhs, line 539 + Ghci3.$fShowX *** unexpected failure for T8628(normal) This looks nasty. =====> tc124(hpc) 3135 of 4100 [0, 3, 0] cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc-validate/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc124.hs -O -fhpc -hpcdir .hpc.tc124 -fno-warn-incomplete-patterns >tc124.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** : Warning: In the type ?a_12 -> a_aia -> a_aia? @ a_12 is out of scope *** Offending Program *** Foo.f :: Foo.T -> (GHC.Types.Int, GHC.Types.Char) [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 90 30}] .... This also looks scary. Thanks! -- Sergei -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: validate-slow.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From nikita at karetnikov.org Fri Sep 5 20:21:32 2014 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Sat, 06 Sep 2014 00:21:32 +0400 Subject: Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6 In-Reply-To: <20140902092143.52d679d7@sf> (Sergei Trofimovich's message of "Tue, 2 Sep 2014 09:21:43 +0300") References: <87d2c4krhj.fsf@karetnikov.org> <20140902005320.221c02ea@sf> <87tx4qy6eh.fsf@karetnikov.org> <20140902092143.52d679d7@sf> Message-ID: <87mwadzulv.fsf@karetnikov.org> >>> I have happened to find seemingly related bug in PIC handing >>> on other PIC-sensitive RISCs: >>> >>> https://phabricator.haskell.org/D177 (also in ghc's master) >>> >>> I think it might help you to get ghci on your mipsel. The following error occurred on 31f43e806beeac434b1330ba5a04746ae79275fc: /usr/bin/ar: creating libraries/haskeline/dist-install/build/libHShaske_2vN4xw6O9xk8OwkNKI7sbg.a "rm" -f libraries/haskeline/dist-install/build/libHShaske_2vN4xw6O9xk8OwkNKI7sbg.a.contents Panic! libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.hi exists, but libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o does not. make[1]: *** [libraries/Cabal/Cabal/dist-install/build/Language/Haskell/Extension.dyn_o] Error 1 make: *** [all] Error 2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From mail at joachim-breitner.de Fri Sep 5 21:34:29 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 05 Sep 2014 23:34:29 +0200 Subject: slow Trac In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1409952869.4939.0.camel@joachim-breitner.de> Hi, Am Freitag, den 05.09.2014, 03:21 -0500 schrieb Austin Seipp: > Update: Trac should be much more responsive now (and Hackage too), but > Hackage still needs more investigation. Still ongoing for the > moment... I?m still observing bad response times, and errors like "database locked". If they are gone when I do the HIW Trac+Phab demo, that?d be great. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Fri Sep 5 21:46:26 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 5 Sep 2014 16:46:26 -0500 Subject: slow Trac In-Reply-To: <1409952869.4939.0.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF221FA134@DB3PRD3001MB020.064d.mgd.msft.net> <1409952869.4939.0.camel@joachim-breitner.de> Message-ID: Hmmm, Trac is running a high CPU now. I'm looking at it. We had a problem a few weeks ago with aggressive webspiders crawling/indexing the changesets for GHC, which put Trac at a relatively high load as it computed lots of diffs. We redirected the changeset view temporarily - I'm looking at why it's all cranky now. FWIW, Phabricator is located in an entirely separate part of the world with its own dedicated resources (including buildbot for patches), and should be unaffected. In fact, I think I know how to speed up the page load times even further for Phab... On Fri, Sep 5, 2014 at 4:34 PM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 05.09.2014, 03:21 -0500 schrieb Austin Seipp: >> Update: Trac should be much more responsive now (and Hackage too), but >> Hackage still needs more investigation. Still ongoing for the >> moment... > > I?m still observing bad response times, and errors like "database > locked". > > If they are gone when I do the HIW Trac+Phab demo, that?d be great. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From thomasmiedema at gmail.com Sat Sep 6 09:54:55 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sat, 6 Sep 2014 11:54:55 +0200 Subject: validate --slow bugs (was Re: Status updates) In-Reply-To: <20140905230310.1cd71e29@sf> References: <20140905230310.1cd71e29@sf> Message-ID: > > > - I still think we should turn on --slow mode for our buildbots soon, > > but this will cause noise. I'd really like some inputs on this - maybe > > someone would like to help clean up the 'slow' vaildate failures? > > Bonus points for this, since you don't even have to > > That's a great goal, but --slow enables compiler debug assertions, > which seem to trigger real errors (full log of failures attached). Also note that when debugging is on, tests that call `compiler_stats_num_field` are currently skipped . This applies to almost all tests in `tests/perf/compiler`. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sat Sep 6 10:17:29 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 6 Sep 2014 10:17:29 +0000 Subject: Trac Message-ID: <618BE556AADD624C9C918AA5D5911BEF221FAAF2@DB3PRD3001MB020.064d.mgd.msft.net> Trac is still very slow, and super-hard to update a wiki page without getting "database locked" and often losing all your eits. It would be great if this could be fixed somehow. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Sat Sep 6 11:10:54 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 6 Sep 2014 11:10:54 +0000 Subject: Problems with building GHC 7.8.3 on Windows In-Reply-To: References: <5400A34C.5030401@mail.ru> Message-ID: <618BE556AADD624C9C918AA5D5911BEF221FAB86@DB3PRD3001MB020.064d.mgd.msft.net> Marek This sounds great. Can you update the wiki page so that it says exactly what to do? I?m copying Neil Mitchell who is interested in doing the same Thank you! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Marek Wawrzos Sent: 02 September 2014 10:26 Cc: ghc-devs at haskell.org Subject: Re: Problems with building GHC 7.8.3 on Windows I have finally builded GHC 7.8.3 on Windows. The wiki page with MSYS2 that you linked to proved to be useful reference. Indeed using the latest 64 bit MSYS2 as building environment solved my problems. However there are some issues with the instructions presented: -- the MSYS2 package that is linked to in the page fails to initial update. Using the latest official MSYS2 package does solve that ( https://sourceforge.net/projects/msys2/files/Base/x86_64 ); -- initial update has to be done along the instructions from http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ ; There are some error outputs during initial update but they do not seem to cause any harm I thing it might be a good idea to give stronger encouragement to use MSYS2 on the page with Windows-specific instructions. It suggests that old MSYS can be used successfully while it apparently fails and is not supported. 2014-08-29 17:59 GMT+02:00 kyra >: 1. I see you've set ticket's 'Architecture' field to be 'x86_64' while make output suggests you try to build 32-bit ghc. 2. You are using 'old' MSys which is known to be problematic when building GHC. It's much better to use MSYS2 now: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2. Also, remember, MSYS2 is only a *build environment*, so you can use 64-bit MSYS2 to build 32-bit GHC on 64-bit Windows. My experience is that 64-bit MSYS2 is more solid and stable than 32-bit MSYS2. And it's extremely important to remember you must *not* use msys2_shell.bat to start MSYS2 shell, only mingwXX_shell.bat (XX stands for 32 or 64) shall be used to start MSYS2 shell -- otherwise GHC make system would not recognize build triplet. Cheers, Kyra On 8/29/2014 17:50, Marek Wawrzos wrote: Hello, I am trying to compile GHC 7.8.3 on Windows. I was following the instructions from the GHC wiki, but I have encountered errors during the make process. I have filed a bug report describing my issue: https://ghc.haskell.org/trac/ghc/ticket/9513 Does anyone had working setup for building GHC and would be willing to share information on how to achieve it? -- Best regards, Marek Wawrzos _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Z powa?aniem, Marek Wawrzos -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Sep 7 03:05:44 2014 From: david.feuer at gmail.com (David Feuer) Date: Sat, 6 Sep 2014 23:05:44 -0400 Subject: Trying to fix an efficiency issue noted in a TODO in SAT.hs Message-ID: compiler/simplCore/SAT.hs has a TODO comment about the fact that it does a fair bit of appending onto the ends of lists, and that should be done differently. I made an attempt to fix it. The complexity of the recursion, however, leaves me uncertain as to whether I really did or not. I've attached a diff and I hope someone will be able to take a look at it. The only use of Sequence.fromList is source line 172, and the only significant use of Foldable.toList (aside from pretty-printing) is on source line 402. Note that the use of Sequence may be temporary?I want to get the right code structure down before choosing the best data structure. Thanks, David Feuer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- diff --git a/compiler/simplCore/SAT.lhs b/compiler/simplCore/SAT.lhs index a0b3151..aae3e69 100644 --- a/compiler/simplCore/SAT.lhs +++ b/compiler/simplCore/SAT.lhs @@ -67,10 +67,16 @@ import VarSet import Unique import UniqSet import Outputable - import Data.List import FastString +--We're probably not really going to use Data.Sequence +--this is just a temporary temporary thing to see what we'll +--actually need. +import qualified Data.Sequence as S +import Data.Foldable (toList) +import Data.Sequence (Seq, (|>), (<|), (><), fromList) + #include "HsVersions.h" \end{code} @@ -118,7 +124,7 @@ data Staticness a = Static a | NotStatic type IdAppInfo = (Id, SATInfo) -type SATInfo = [Staticness App] +type SATInfo = Seq (Staticness App) -- [Staticness App] type IdSATInfo = IdEnv SATInfo emptyIdSATInfo :: IdSATInfo emptyIdSATInfo = emptyUFM @@ -129,7 +135,7 @@ pprIdSATInfo id_sat_info = vcat (map pprIdAndSATInfo (Map.toList id_sat_info)) -} pprSATInfo :: SATInfo -> SDoc -pprSATInfo staticness = hcat $ map pprStaticness staticness +pprSATInfo staticness = hcat $ map pprStaticness $ toList staticness pprStaticness :: Staticness App -> SDoc pprStaticness (Static (VarApp _)) = ptext (sLit "SV") @@ -139,15 +145,22 @@ pprStaticness NotStatic = ptext (sLit "NS") mergeSATInfo :: SATInfo -> SATInfo -> SATInfo -mergeSATInfo [] _ = [] -mergeSATInfo _ [] = [] -mergeSATInfo (NotStatic:statics) (_:apps) = NotStatic : mergeSATInfo statics apps -mergeSATInfo (_:statics) (NotStatic:apps) = NotStatic : mergeSATInfo statics apps -mergeSATInfo ((Static (VarApp v)):statics) ((Static (VarApp v')):apps) = (if v == v' then Static (VarApp v) else NotStatic) : mergeSATInfo statics apps -mergeSATInfo ((Static (TypeApp t)):statics) ((Static (TypeApp t')):apps) = (if t `eqType` t' then Static (TypeApp t) else NotStatic) : mergeSATInfo statics apps -mergeSATInfo ((Static (CoApp c)):statics) ((Static (CoApp c')):apps) = (if c `coreEqCoercion` c' then Static (CoApp c) else NotStatic) : mergeSATInfo statics apps -mergeSATInfo l r = pprPanic "mergeSATInfo" $ ptext (sLit "Left:") <> pprSATInfo l <> ptext (sLit ", ") - <> ptext (sLit "Right:") <> pprSATInfo r +mergeSATInfo l r = S.zipWith mergeSA l r + where + mergeSA NotStatic _ = NotStatic + mergeSA _ NotStatic = NotStatic + mergeSA (Static (VarApp v)) (Static (VarApp v')) + | v == v' = Static (VarApp v) + | otherwise = NotStatic + mergeSA (Static (TypeApp t)) (Static (TypeApp t')) + | t `eqType` t' = Static (TypeApp t) + | otherwise = NotStatic + mergeSA (Static (CoApp c)) (Static (CoApp c')) + | c `coreEqCoercion` c' = Static (CoApp c) + | otherwise = NotStatic + mergeSA _ _ = pprPanic "mergeSATInfo" $ ptext (sLit "Left:") + <> pprSATInfo l <> ptext (sLit ", ") + <> ptext (sLit "Right:") <> pprSATInfo r mergeIdSATInfo :: IdSATInfo -> IdSATInfo -> IdSATInfo mergeIdSATInfo = plusUFM_C mergeSATInfo @@ -156,7 +169,7 @@ mergeIdSATInfos :: [IdSATInfo] -> IdSATInfo mergeIdSATInfos = foldl' mergeIdSATInfo emptyIdSATInfo bindersToSATInfo :: [Id] -> SATInfo -bindersToSATInfo vs = map (Static . binderToApp) vs +bindersToSATInfo vs = fromList $ map (Static . binderToApp) vs where binderToApp v | isId v = VarApp v | isTyVar v = TypeApp $ mkTyVarTy v | otherwise = CoApp $ mkCoVarCo v @@ -178,7 +191,7 @@ satTopLevelExpr expr interesting_ids = do satExpr :: CoreExpr -> IdSet -> SatM (CoreExpr, IdSATInfo, Maybe IdAppInfo) satExpr var@(Var v) interesting_ids = do let app_info = if v `elementOfUniqSet` interesting_ids - then Just (v, []) + then Just (v, S.empty) else Nothing return (var, emptyIdSATInfo, app_info) @@ -195,8 +208,7 @@ satExpr (App fn arg) interesting_ids = do case fn_app of Nothing -> satRemainder Nothing Just (fn_id, fn_app_info) -> - -- TODO: remove this use of append somehow (use a data structure with O(1) append but a left-to-right kind of interface) - let satRemainderWithStaticness arg_staticness = satRemainder $ Just (fn_id, fn_app_info ++ [arg_staticness]) + let satRemainderWithStaticness arg_staticness = satRemainder $ Just (fn_id, fn_app_info |> arg_staticness) in case arg of Type t -> satRemainderWithStaticness $ Static (TypeApp t) Coercion c -> satRemainderWithStaticness $ Static (CoApp c) @@ -371,7 +383,7 @@ saTransformMaybe binder maybe_arg_staticness rhs_binders rhs_body where should_transform staticness = n_static_args > 1 -- THIS IS THE DECISION POINT where - n_static_args = length (filter isStaticValue staticness) + n_static_args = S.length (S.filter isStaticValue staticness) saTransform :: Id -> SATInfo -> [Id] -> CoreExpr -> SatM CoreBind saTransform binder arg_staticness rhs_binders rhs_body @@ -385,13 +397,17 @@ saTransform binder arg_staticness rhs_binders rhs_body -- rhs_binders = [\alpha, \beta, c, n, xs] -- rhs_body = e - binders_w_staticness = rhs_binders `zip` (arg_staticness ++ repeat NotStatic) + (rhs_binders_known_staticness, rhs_binders_unknown_staticness) = splitAt (S.length arg_staticness) rhs_binders + + binders_w_known_staticness = rhs_binders_known_staticness `zip` toList arg_staticness + binders_w_staticness = binders_w_known_staticness ++ + map (\x->(x,NotStatic)) rhs_binders_unknown_staticness -- Any extra args are assumed NotStatic non_static_args :: [Var] -- non_static_args = [xs] -- rhs_binders_without_type_capture = [\alpha', \beta', c, n, xs] - non_static_args = [v | (v, NotStatic) <- binders_w_staticness] + non_static_args = [v | (v, NotStatic) <- binders_w_known_staticness] ++ rhs_binders_unknown_staticness clone (bndr, NotStatic) = return bndr clone (bndr, _ ) = do { uniq <- newUnique From mail at joachim-breitner.de Sun Sep 7 07:40:45 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 07 Sep 2014 09:40:45 +0200 Subject: Trying to fix an efficiency issue noted in a TODO in SAT.hs In-Reply-To: References: Message-ID: <1410075645.24043.1.camel@joachim-breitner.de> Hi David, Am Samstag, den 06.09.2014, 23:05 -0400 schrieb David Feuer: > compiler/simplCore/SAT.hs has a TODO comment about the fact that it > does a fair bit of appending onto the ends of lists, and that should > be done differently. I made an attempt to fix it. Great! We need people to work on GHC?s own performance. Did you profile first, and did it show up there? You know, premature optimization... so it might be that your fix is a nice improvement and useful exercise (and very welcome as such), but without much real-world effect. Nofib can report compiler runtimes. Another way to measuring the effect is compare the output of the perf/compiler test cases with "make VERBOSE=4". BTW, code review is easier on Phabricator. Maye you want to get started using that? See https://ghc.haskell.org/trac/ghc/wiki/Phabricator for instructions. Greeting, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From alan.zimm at gmail.com Sun Sep 7 08:30:07 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sun, 7 Sep 2014 10:30:07 +0200 Subject: GHC AST Annotations In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221F4F10@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF221F53EE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: If this is done right it can enable this sort of thing : http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/ On Fri, Sep 5, 2014 at 5:11 PM, Alan & Kim Zimmerman wrote: > Hi Neil > > Thanks for the feedback. > > I am going to start putting together a proof of concept, aiming to > identify what annotations are needed to roundtrip source. > > The first version will make use of the index into a separate structure > scheme, so that it can be used with existing GHC ASTs. Hopefully the > information gained will help in understanding what is needed for the > changes to the future AST. > > The concept I will be working with is a pretty-printer, where relative > spacing for the particular elements is derived from the initial SrcSpan > information. Any new elements added or changed in the AST can then have > only relative information, and the final render should honour the layout > from the original. > > It may be possible to harmonise this with Chris Done's hindent package, > which is a code-specific pretty printer for haskell-src-exts. > > Alan > > > On Sat, Aug 30, 2014 at 11:18 PM, Neil Mitchell > wrote: > >> Since Alan is trying to do something for HaRe that I want for HLint on >> top of haskell-src-exts, he asked me for my opinions on the proposal. >> There seem to be two approaches to take: >> >> * Add SrcSpan's throughout. The HSE approach of having a list of inner >> source spans is nasty - the details of which source space goes where >> is entirely undocumented and hard to discover. Even worse, for things >> like instance, which may or may not have a where after, the number of >> inner SrcSpan's changes. Simon's idea of hsdo_do_loc is much cleaner, >> and easily extends to Maybe SrcSpan if the keyword is optional. >> >> * Having the annotation be a type parameter gives much greater >> flexibility. In particular, it would let you mark certain nodes as >> being added/deleted. However, since SrcSpan has an Int in it, you can >> always pass around a separate IntMap and make the SrcSpan really be an >> index into more detailed information. It's nasty, but only the people >> who use it pay for it. >> >> Both approaches have disadvantages. You could always combine both >> ideas, and have a SrcSpan and entirely separately an annotation (which >> defaults to (), rather than SrcSpanInfo), but maybe that's too much >> extra baggage on the AST. >> >> Thanks, Neil >> >> >> On Sat, Aug 30, 2014 at 3:32 PM, Alan & Kim Zimmerman >> wrote: >> > A further use case would be to be able to convert all the locations to >> be >> > relative, or include a relative portion, so that as tools manipulate >> the AST >> > by adding or removing parts the layout can be preserved. >> > >> > I think I may need to make a wip branch for this and experiment, it is >> > always easier to comment on concrete things. >> > >> > Alan >> > >> > >> > On Thu, Aug 28, 2014 at 10:38 PM, Simon Peyton Jones < >> simonpj at microsoft.com> >> > wrote: >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> It?s probably not too bad if you use record syntax; thus >> >> >> >> | HsDo { hsdo_do_loc :: SrcSpan -- of the word "do" >> >> >> >> , hsdo_blocks :: BlockSrcSpans >> >> >> >> , hsdo_ctxt :: HsStmtContext Name >> >> >> >> , hsdo_stmts :: [ExprLStmt id] >> >> >> >> , hsdo_type :: PostTcType } >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com] >> >> Sent: 28 August 2014 19:35 >> >> To: Richard Eisenberg >> >> Cc: Simon Peyton Jones; ghc-devs at haskell.org >> >> Subject: Re: GHC AST Annotations >> >> >> >> >> >> >> >> This does have the advantage of being explicit. I modelled the initial >> >> proposal on HSE as a proven solution, and I think that they were >> trying to >> >> keep it non-invasive, to allow both an annotated and non-annoted AST. >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> The other question, which is probably orthogonal to this, is whether we >> >> want the annotation to be a parameter to the AST, which allows it to be >> >> overridden by various tools for various purposes, or fixed as in >> Richard's >> >> suggestion. >> >> >> >> A parameterised annotation allows the annotations to be manipulated via >> >> something like for HSE: >> >> >> >> -- |AST nodes are annotated, and this class allows manipulation of the >> >> annotations. >> >> class Functor ast => Annotated ast where >> >> >> >> -- |Retrieve the annotation of an AST node. >> >> ann :: ast l -> l >> >> >> >> -- |Change the annotation of an AST node. Note that only the >> annotation >> >> of the node itself is affected, and not >> >> -- the annotations of any child nodes. if all nodes in the AST tree >> are >> >> to be affected, use fmap. >> >> >> >> amap :: (l -> l) -> ast l -> ast l >> >> >> >> >> >> >> >> Alan >> >> >> >> >> >> >> >> On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg >> >> wrote: >> >> >> >> For what it's worth, my thought is not to use SrcSpanInfo (which, to >> me, >> >> is the wrong way to slice the abstraction) but instead to add SrcSpan >> fields >> >> to the relevant nodes. For example: >> >> >> >> | HsDo SrcSpan -- of the word "do" >> >> BlockSrcSpans >> >> (HsStmtContext Name) -- The parameterisation is >> >> unimportant >> >> -- because in this context we >> never >> >> use >> >> -- the PatGuard or ParStmt variant >> >> [ExprLStmt id] -- "do":one or more stmts >> >> PostTcType -- Type of the whole expression >> >> >> >> ... >> >> >> >> data BlockSrcSpans = LayoutBlock Int -- the parameter is the >> indentation >> >> level >> >> ... -- stuff to track the appearance >> of >> >> any semicolons >> >> | BracesBlock ... -- stuff to track the braces and >> >> semicolons >> >> >> >> >> >> The way I understand it, the SrcSpanInfo proposal means that we would >> have >> >> lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I >> think. >> >> >> >> Popping up a level, I do support the idea of including this info in the >> >> AST. >> >> >> >> Richard >> >> >> >> >> >> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones < >> simonpj at microsoft.com> >> >> wrote: >> >> >> >> > In general I?m fine with this direction of travel. Some specifics: >> >> > >> >> > ? You?d have to be careful to document, for every data >> >> > constructor in HsSyn, what the association between the [SrcSpan] in >> the >> >> > SrcSpanInfo and the ?sub-entities? >> >> > ? Many of the sub-entities will have their own SrcSpanInfo >> >> > wrapped around them, so there?s some unhelpful duplication. Maybe >> you only >> >> > want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities >> (like the >> >> > syntactic keywords) that do not show up as children in the syntax >> tree? >> >> > Anyway do by all means create a GHC Trac wiki page to describe your >> >> > proposed design, concretely. >> >> > >> >> > Simon >> >> > >> >> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> Alan & >> >> > Kim Zimmerman >> >> > Sent: 28 August 2014 15:00 >> >> > To: ghc-devs at haskell.org >> >> > Subject: GHC AST Annotations >> >> > >> >> > Now that the landmines have hopefully been cleared from the AST via >> [1] >> >> > I would like to propose changing the location information in the AST. >> >> > >> >> > Right now the locations of syntactic markers such as >> do/let/where/in/of >> >> > in the source are discarded from the AST, although they are retained >> in the >> >> > rich token stream. >> >> > >> >> > The haskell-src-exts package deals with this by means of using the >> >> > SrcSpanInfo data type [2] which contains the SrcSpan as per the >> current GHC >> >> > Located type but also has a list of SrcSpan s for the syntactic >> markers, >> >> > depending on the particular AST fragment being annotated. >> >> > >> >> > In addition, the annotation type is provided as a parameter to the >> AST, >> >> > so that it can be changed as required, see [3]. >> >> > >> >> > The motivation for this change is then >> >> > >> >> > 1. Simplify the roundtripping and modification of source by >> explicitly >> >> > capturing the missing location information for the syntactic markers. >> >> > >> >> > 2. Allow the annotation to be a parameter so that it can be replaced >> >> > with a different one in tools, for example HaRe would include the >> tokens for >> >> > the AST fragment leaves. >> >> > >> >> > 3. Aim for some level compatibility with haskell-src-exts so that >> tools >> >> > developed for it could be easily ported to GHC, for example >> exactprint [4]. >> >> > >> >> > >> >> > >> >> > I would like feedback as to whether this would be acceptable, or if >> the >> >> > same goals should be achieved a different way. >> >> > >> >> > >> >> > >> >> > Regards >> >> > >> >> > Alan >> >> > >> >> > >> >> > >> >> > >> >> > [1] https://phabricator.haskell.org/D157 >> >> > >> >> > [2] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-SrcLoc.html#t:SrcSpanInfo >> >> > >> >> > [3] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-Syntax.html#t:Annotated >> >> > >> >> > [4] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-ExactPrint.html#v:exactPrint >> >> > >> >> >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs at haskell.org >> >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Sep 7 14:21:46 2014 From: david.feuer at gmail.com (David Feuer) Date: Sun, 7 Sep 2014 10:21:46 -0400 Subject: Trying to fix an efficiency issue noted in a TODO in SAT.lhs Message-ID: Joachim Breitner wrote: > Did you profile first, and did it show up there? You know, premature > optimization... so it might be that your fix is a nice improvement and > useful exercise (and very welcome as such), but without much real-world > effect. You're right, of course. I read the comment and figured it made sense, but it may not really make much. In particular, the lists involved will usually be short, so O(n^2) may not actually be bad. It would probably be more valuable for me to start by trying to make it easier to follow what's going on (and I've submitted one patch to do so for one of the functions) and think about efficiency later or not at all. > BTW, code review is easier on Phabricator. Maybe you want to get started > using that? See https://ghc.haskell.org/trac/ghc/wiki/Phabricator for > instructions. I'll take a look. There are a million tools to learn. -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Sun Sep 7 16:47:02 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 7 Sep 2014 11:47:02 -0500 Subject: NOTE: Minor downtime for Trac/ghc/git.haskell.org today Message-ID: Hi *, In about 1 hour from now (12:30pm CDT), Trac, git.haskell.org, and ghc.haskell.org may be temporarily unavailable for 5 to 10 minutes or so. We're moving the server to a new dedicated host as a result of all the availability problems the past few days. The downtime will mostly accommodate the time needed for DNS switchover to a new IP. As a bonus, the new server should keep us going for a very long time, and has a nice amount of bandwidth dedicated to it, as well as IPv6. Please DO NOT push things to the git repositories; it will be blocked. Don't edit Trac; we'll be revoking ACL write permissions most likely for a short window. Note that I have set the DNS TTLs for Haskell.org to a very low value to facilitate the IP change. If you have connectivity problems after that, let me know. I'll email again when the expected downtime is starting/completed. You can also check http://status.haskell.org for more. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Sun Sep 7 17:31:36 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 7 Sep 2014 12:31:36 -0500 Subject: NOTE: Minor downtime for Trac/ghc/git.haskell.org today In-Reply-To: References: Message-ID: Hi *, The migration is now starting. On Sun, Sep 7, 2014 at 11:47 AM, Austin Seipp wrote: > Hi *, > > In about 1 hour from now (12:30pm CDT), Trac, git.haskell.org, and > ghc.haskell.org may be temporarily unavailable for 5 to 10 minutes or > so. We're moving the server to a new dedicated host as a result of all > the availability problems the past few days. The downtime will mostly > accommodate the time needed for DNS switchover to a new IP. > > As a bonus, the new server should keep us going for a very long time, > and has a nice amount of bandwidth dedicated to it, as well as IPv6. > > Please DO NOT push things to the git repositories; it will be blocked. > Don't edit Trac; we'll be revoking ACL write permissions most likely > for a short window. > > Note that I have set the DNS TTLs for Haskell.org to a very low value > to facilitate the IP change. If you have connectivity problems after > that, let me know. > > I'll email again when the expected downtime is starting/completed. You > can also check http://status.haskell.org for more. > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Sun Sep 7 18:16:43 2014 From: austin at well-typed.com (Austin Seipp) Date: Sun, 7 Sep 2014 13:16:43 -0500 Subject: NOTE: Minor downtime for Trac/ghc/git.haskell.org today In-Reply-To: References: Message-ID: Hi all, The switchover should now be complete, and the old server has been shut down. Please let me know if anything is wrong. You may still be resolving the old IP address for a little while, but hopefully the more aggressive TTL will kick in soon. On Sun, Sep 7, 2014 at 12:31 PM, Austin Seipp wrote: > Hi *, > > The migration is now starting. > > On Sun, Sep 7, 2014 at 11:47 AM, Austin Seipp wrote: >> Hi *, >> >> In about 1 hour from now (12:30pm CDT), Trac, git.haskell.org, and >> ghc.haskell.org may be temporarily unavailable for 5 to 10 minutes or >> so. We're moving the server to a new dedicated host as a result of all >> the availability problems the past few days. The downtime will mostly >> accommodate the time needed for DNS switchover to a new IP. >> >> As a bonus, the new server should keep us going for a very long time, >> and has a nice amount of bandwidth dedicated to it, as well as IPv6. >> >> Please DO NOT push things to the git repositories; it will be blocked. >> Don't edit Trac; we'll be revoking ACL write permissions most likely >> for a short window. >> >> Note that I have set the DNS TTLs for Haskell.org to a very low value >> to facilitate the IP change. If you have connectivity problems after >> that, let me know. >> >> I'll email again when the expected downtime is starting/completed. You >> can also check http://status.haskell.org for more. >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Mon Sep 8 07:21:40 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 08 Sep 2014 09:21:40 +0200 Subject: HEAD fails to bootstrap with HEAD? Message-ID: <540D5904.2050102@centrum.cz> Hello, I've noticed that probably after cabal/ghc-pkg changes done recently HEAD fails to build with HEAD in following way: [80 of 80] Compiling Main ( utils/ghc-cabal/Main.hs, bootstrapping/Main.o ) Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal "inplace/bin/mkdirhier" compiler/stage1/build//. "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. "inplace/bin/ghc-cabal" configure libraries/Cabal/Cabal dist-boot "" --with-ghc="/opt/ghc-7.9.20140906-amd64/bin/ghc" --with-ghc-pkg="/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg" --package-db=/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --with-hscolour="/export/home/karel/.cabal/bin/HsColour" --configure-option=CFLAGS=" -m64 -fno-stack-protector " --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 " --gcc-options=" -m64 -fno-stack-protector -m64 " --configure-option=--with-gmp-includes="/usr/include/gmp" --configure-option=--with-gmp-libraries="/usr/lib/" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.1" --constraint "binary == 0.7.1.0" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.1" --constraint "transformers == 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/xpg4/bin/ar" --with-alex="/export/home/karel/.cabal/bin/alex" --with-happy="/export/home/karel/.cabal/bin/happy" Configuring Cabal-1.21.1.0... ghc-cabal: '/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. gmake[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 gmake: *** [all] Error 2 I've been able to solve this by: $ rm libraries/bootstrapping.conf $ /opt/ghc-7.9.20140906-amd64/bin/ghc-pkg init libraries/bootstrapping.conf however it's kind of impractical to do that on buildbot (solaris/amd64). Is it possible to fix that somehow? Thanks! Karel From david.feuer at gmail.com Mon Sep 8 21:21:59 2014 From: david.feuer at gmail.com (David Feuer) Date: Mon, 8 Sep 2014 17:21:59 -0400 Subject: What is testsuite/tests/rename/should_fail/rnfail018.hs supposed to test? Message-ID: When I compile this with 7.8.3, it gives an error message saying that type variables a and m are not in scope. If I add them to the forall, it tells me I need FlexibleContexts. If I add that, then it gives me an error about an ambiguous type variable. Clearly, something crashed ghc-4.04proto, but there's no indication of what that was. If this test is still at all relevant, it probably needs to be updated to target something more narrowly. The program: {-# LANGUAGE MultiParamTypeClasses, ExplicitForAll #-} module ShouldFail where -- !!! For-all with parens -- This one crashed ghc-4.04proto; the parens after the for-all fooled it class Monad m => StateMonad s m where getState :: m s setState0 :: forall b. (StateMonad (a,b) m => m a) setState0 = getState >>= \ (l,_r) -> return l David Feuer -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Sep 8 22:01:17 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 9 Sep 2014 00:01:17 +0200 Subject: No context in error messages Message-ID: Hi everybody, I am working with Hint, after some discussion with Daniel Gorin, I decided to post here, I hope it's the right place. My problem with Hint is that I cannot get context in error messages while interpreting a string. If you run the attached file example.hs, you get: GhcError {errMsg = "No instance for (GHC.Num.Num GHC.Base.String)\n arising from a use of `GHC.Num.+'\nPossible fix:\n add an instance declaration for (GHC.Num.Num GHC.Base.String)"} There is no context (line number, code snippets...), plus the error message uses fully qualified names, which is not very readable. It's very hard to figure out where the problem is when interpreting a long string. But the same error in a file that is loaded with Hint gives the correct message (uncomment the putStrLn in SomeModule.hs to get it): GhcError {errMsg = ":\n [1 of 1] Compiling SomeModule ( SomeModule.hs, interpreted )"},GhcError {errMsg = "SomeModule.hs:5:22:\n No instance for (Num String) arising from a use of `+'\n Possible fix: add an instance declaration for (Num String)\n In the second argument of `($)', namely `\"bar\" + 1'\n In a stmt of a 'do' block: putStrLn $ \"bar\" + 1\n In the expression:\n do { putStrLn \"bar\";\n putStrLn $ \"bar\" + 1 }"} This error is much better: it gives line number plus some code snippets ("In the second argument of..."). There might be a flag that is not correctly set in GHC? After a quick look I'm thinking of GHC.DynFlags (I'm no expert). Now it is configured with: configureDynFlags :: GHC.DynFlags -> GHC.DynFlags configureDynFlags dflags = dflags{GHC.ghcMode = GHC.CompManager, GHC.hscTarget = GHC.HscInterpreted, GHC.ghcLink = GHC.LinkInMemory, GHC.verbosity = 0} Thanks, Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: example.hs Type: text/x-haskell Size: 713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SomeModule.hs Type: text/x-haskell Size: 136 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Tue Sep 9 06:54:15 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 9 Sep 2014 08:54:15 +0200 Subject: What is testsuite/tests/rename/should_fail/rnfail018.hs supposed to test? In-Reply-To: References: Message-ID: <201409090854.16093.jan.stolarek@p.lodz.pl> David, the comment in the test says what crashed ghc-4.04proto: "the parens after the for-all fooled it". So I suppose that "forall b. StateMonad (a,b) m => m a" worked fine but "forall b. (StateMonad (a,b) m => m a)" crashed GHC. This test is in a should_fail folder, which means that the compilation of this file should fail and GHC should report an error. Take a look at the rnfail018.stderr file. It says what output do we expect on the standard error. You can see that we expect a and m to be out of scope, which according to your mail is exactly what happens. Note also the file name - rnfail - which stands for "renamer failure" (you can see this also from names of directories). Janek Dnia poniedzia?ek, 8 wrze?nia 2014, David Feuer napisa?: > When I compile this with 7.8.3, it gives an error message saying that type > variables a and m are not in scope. If I add them to the forall, it tells > me I need FlexibleContexts. If I add that, then it gives me an error about > an ambiguous type variable. Clearly, something crashed ghc-4.04proto, but > there's no indication of what that was. If this test is still at all > relevant, it probably needs to be updated to target something more > narrowly. > > The program: > > {-# LANGUAGE MultiParamTypeClasses, ExplicitForAll #-} > module ShouldFail where > -- !!! For-all with parens > -- This one crashed ghc-4.04proto; the parens after the for-all fooled it > > class Monad m => StateMonad s m where > getState :: m s > > setState0 :: forall b. (StateMonad (a,b) m => m a) > setState0 = getState >>= \ (l,_r) -> return l > > David Feuer From simonpj at microsoft.com Tue Sep 9 10:51:10 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 9 Sep 2014 10:51:10 +0000 Subject: Trying to fix an efficiency issue noted in a TODO in SAT.hs In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF222057F0@DB3PRD3001MB020.064d.mgd.msft.net> The static argument transformation is currently run only when ?fstatic-argument-transformation is specified; i.e almost never. It has not received any love for some time. I note the following comment from Max Bolingbroke in DynFlags.hs -- , ([2], Opt_StaticArgumentTransformation) -- Max writes: I think it's probably best not to enable SAT with -O2 for the -- 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate -- several improvements to the heuristics, and I'm concerned that without -- those changes SAT will interfere with some attempts to write "high -- performance Haskell", as we saw in some posts on Haskell-Cafe earlier -- this year. In particular, the version in HEAD lacks the tail call -- criterion, so many things that look like reasonable loops will be -- turned into functions with extra (unnecessary) thunk creation. I?m therefore reluctant to commit refactoring to SAT. They will, in effect, be entirely un-tested. There is a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9374 Do by all means add your diffs to it, so that if anyone (possibly even you) picks it up they will get the benefit of your work. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer Sent: 07 September 2014 04:06 To: ghc-devs Subject: Trying to fix an efficiency issue noted in a TODO in SAT.hs compiler/simplCore/SAT.hs has a TODO comment about the fact that it does a fair bit of appending onto the ends of lists, and that should be done differently. I made an attempt to fix it. The complexity of the recursion, however, leaves me uncertain as to whether I really did or not. I've attached a diff and I hope someone will be able to take a look at it. The only use of Sequence.fromList is source line 172, and the only significant use of Foldable.toList (aside from pretty-printing) is on source line 402. Note that the use of Sequence may be temporary?I want to get the right code structure down before choosing the best data structure. Thanks, David Feuer -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Tue Sep 9 11:27:47 2014 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 9 Sep 2014 13:27:47 +0200 Subject: No context in error messages In-Reply-To: References: Message-ID: Anyway, I think I figured it out: Hint is using the Show instance of ErrMsg. But it is defined only in term of errMsgShortString: https://www.haskell.org/ghc/docs/7.6.3/html/libraries/ghc-7.6.3/src/ErrUtils.html#ErrMsg So we are missing the context infos. On Tue, Sep 9, 2014 at 12:01 AM, Corentin Dupont wrote: > Hi everybody, > I am working with Hint, after some discussion with Daniel Gorin, I decided > to post here, I hope it's the right place. > My problem with Hint is that I cannot get context in error messages while > interpreting a string. If you run the attached file example.hs, you get: > > GhcError {errMsg = "No instance for (GHC.Num.Num GHC.Base.String)\n > arising from a use of `GHC.Num.+'\nPossible fix:\n add an instance > declaration for (GHC.Num.Num GHC.Base.String)"} > > There is no context (line number, code snippets...), plus the error > message uses fully qualified names, which is not very readable. > It's very hard to figure out where the problem is when interpreting a long > string. > But the same error in a file that is loaded with Hint gives the correct > message (uncomment the putStrLn in SomeModule.hs to get it): > > GhcError {errMsg = ":\n [1 of 1] Compiling > SomeModule ( SomeModule.hs, interpreted )"},GhcError {errMsg = > "SomeModule.hs:5:22:\n No instance for (Num String) arising from a use > of `+'\n Possible fix: add an instance declaration for (Num String)\n > In the second argument of `($)', namely `\"bar\" + 1'\n In a stmt of a > 'do' block: putStrLn $ \"bar\" + 1\n In the expression:\n do { > putStrLn \"bar\";\n putStrLn $ \"bar\" + 1 }"} > > This error is much better: it gives line number plus some code snippets > ("In the second argument of..."). > > There might be a flag that is not correctly set in GHC? After a quick look > I'm thinking of GHC.DynFlags (I'm no expert). Now it is configured with: > configureDynFlags :: GHC.DynFlags -> GHC.DynFlags > configureDynFlags dflags = dflags{GHC.ghcMode = GHC.CompManager, > GHC.hscTarget = GHC.HscInterpreted, > GHC.ghcLink = GHC.LinkInMemory, > GHC.verbosity = 0} > > Thanks, > Corentin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Sep 9 13:34:03 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 9 Sep 2014 08:34:03 -0500 Subject: Status updates Message-ID: Hi *, Here are some status updates: - I've merged the Applicative Monad patchset! Yay! Many thanks to Nathan Howell for helping me out in the end there. Please let me know if anything explodes horribly (I hope not). - Gabor has set up some build documentation for us based on HEAD, hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix haskell.org/ghc to link to this properly (there may be other dead links, please let me know). - As I'm sure most of you were aware, it was a slow week due to ICFP & related events being most of last week. - As I'm also sure you were aware, Haskell.org suffered a lot of instability this past week. I've been focusing most of my efforts since about Thursday on this, since it's come and gone a lot and has needed some consistent monitoring. Unfortunately, it is not done yet, and there is still more work to be done. :( - ghc.haskell.org was migrated to a new server in the US as a part of this effort this weekend (send a thanks to Herbert). In general, you should notice nothing really new, but latency for UK citizens may be a bit higher than it was before now. - Now that Applicative/Monad is done, there are some more changes to 'base' that will happen (Bifunctors, Foldable/Traversable) that will need to happen. So I'm sure this discussion will start soon. - I still can't set up the Windows bot yet, sorry! Phabricator work is still not yet available upstream. Hopefully soon. - Sergei spent some time filing bugs that we should fix in the testsuite, because they fail --slow validate. I believe these are two of them: - https://ghc.haskell.org/trac/ghc/ticket/9567 - https://ghc.haskell.org/trac/ghc/ticket/9566 We'll probably need to fix these before we turn it on. Simon, these look like something up your alley... - For those who missed ICFP, Simon gave a nice status update for GHC, which is on YouTube: https://www.youtube.com/watch?v=Ex79K4lvJno&list=PL4UWOFngo5DW6nKDjK0UB5Oy9zmdWdo7K&index=5 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mail at joachim-breitner.de Tue Sep 9 13:43:58 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 09 Sep 2014 15:43:58 +0200 Subject: Status updates In-Reply-To: References: Message-ID: <1410270238.2713.3.camel@joachim-breitner.de> Hi, Am Dienstag, den 09.09.2014, 08:34 -0500 schrieb Austin Seipp: > - I've merged the Applicative Monad patchset! Yay! Many thanks to > Nathan Howell for helping me out in the end there. Please let me know > if anything explodes horribly (I hope not). Not horrible, but still, it breaks: "inplace/bin/ghc-cabal" check libraries/filepath "inplace/bin/ghc-cabal" configure libraries/filepath dist-install "" --with-ghc="/home/travis/build/ghc/ghc/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/travis/build/ghc/ghc/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/opt/alex/3.1.3/bin/alex" --with-happy="/opt/happy/1.19.4/bin/happy" Configuring filepath-1.3.0.2... ghc-cabal: At least the following dependencies are missing: base >=4 && <4.8 https://s3.amazonaws.com/archive.travis-ci.org/jobs/34812365/log.txt > - Gabor has set up some build documentation for us based on HEAD, > hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix > haskell.org/ghc to link to this properly (there may be other dead > links, please let me know). It?s a blank page for me. Thanks for the update and your work! Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From austin at well-typed.com Tue Sep 9 13:47:00 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 9 Sep 2014 08:47:00 -0500 Subject: Status updates In-Reply-To: <1410270238.2713.3.camel@joachim-breitner.de> References: <1410270238.2713.3.camel@joachim-breitner.de> Message-ID: Yes, brainfart - sorry! Herbert kept telling me to bump base's version number after that change - so I did. But I accidentally broke part of the bootstrap process in my haste. Not AMP related, at least. :) A fix is incoming shortly. On Tue, Sep 9, 2014 at 8:43 AM, Joachim Breitner wrote: > Hi, > > > Am Dienstag, den 09.09.2014, 08:34 -0500 schrieb Austin Seipp: >> - I've merged the Applicative Monad patchset! Yay! Many thanks to >> Nathan Howell for helping me out in the end there. Please let me know >> if anything explodes horribly (I hope not). > > Not horrible, but still, it breaks: > > "inplace/bin/ghc-cabal" check libraries/filepath > "inplace/bin/ghc-cabal" configure libraries/filepath dist-install "" --with-ghc="/home/travis/build/ghc/ghc/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/travis/build/ghc/ghc/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="/usr/bin/gcc" --with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/opt/alex/3.1.3/bin/alex" --with-happy="/opt/happy/1.19.4/bin/happy" > Configuring filepath-1.3.0.2... > ghc-cabal: At least the following dependencies are missing: > base >=4 && <4.8 > > https://s3.amazonaws.com/archive.travis-ci.org/jobs/34812365/log.txt > >> - Gabor has set up some build documentation for us based on HEAD, >> hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix >> haskell.org/ghc to link to this properly (there may be other dead >> links, please let me know). > > It?s a blank page for me. > > > Thanks for the update and your work! > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Tue Sep 9 13:49:03 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 09 Sep 2014 15:49:03 +0200 Subject: Status updates In-Reply-To: <1410270238.2713.3.camel@joachim-breitner.de> References: <1410270238.2713.3.camel@joachim-breitner.de> Message-ID: <540F054F.9020805@centrum.cz> >> - Gabor has set up some build documentation for us based on HEAD, >> hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix >> haskell.org/ghc to link to this properly (there may be other dead >> links, please let me know). > > It?s a blank page for me. Should probably be http://haskell.inf.elte.hu/builders/ Karel From austin at well-typed.com Tue Sep 9 13:50:16 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 9 Sep 2014 08:50:16 -0500 Subject: Status updates In-Reply-To: <540F054F.9020805@centrum.cz> References: <1410270238.2713.3.camel@joachim-breitner.de> <540F054F.9020805@centrum.cz> Message-ID: Nope, my bad again. The actual link is: http://haskell.inf.elte.hu/docs/ On Tue, Sep 9, 2014 at 8:49 AM, Karel Gardas wrote: > >>> - Gabor has set up some build documentation for us based on HEAD, >>> hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix >>> haskell.org/ghc to link to this properly (there may be other dead >>> links, please let me know). >> >> >> It?s a blank page for me. > > > Should probably be http://haskell.inf.elte.hu/builders/ > > Karel > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From carter.schonwald at gmail.com Tue Sep 9 13:52:24 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 9 Sep 2014 09:52:24 -0400 Subject: Status updates In-Reply-To: References: <1410270238.2713.3.camel@joachim-breitner.de> <540F054F.9020805@centrum.cz> Message-ID: not sure why, but in the build docs, the version numbers on the module packages look... bonkers http://haskell.inf.elte.hu/docs/7.9.20140908/html/libraries/index.html eg GHC.PackageDb binpa_JutoagPF9VL3G583BCA0 On Tue, Sep 9, 2014 at 9:50 AM, Austin Seipp wrote: > Nope, my bad again. The actual link is: > > http://haskell.inf.elte.hu/docs/ > > On Tue, Sep 9, 2014 at 8:49 AM, Karel Gardas > wrote: > > > >>> - Gabor has set up some build documentation for us based on HEAD, > >>> hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix > >>> haskell.org/ghc to link to this properly (there may be other dead > >>> links, please let me know). > >> > >> > >> It?s a blank page for me. > > > > > > Should probably be http://haskell.inf.elte.hu/builders/ > > > > Karel > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slyich at gmail.com Tue Sep 9 17:32:09 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Tue, 9 Sep 2014 20:32:09 +0300 Subject: Status updates In-Reply-To: References: Message-ID: <20140909203209.02eec146@sf> On Tue, 9 Sep 2014 08:34:03 -0500 Austin Seipp wrote: > - Sergei spent some time filing bugs that we should fix in the > testsuite, because they fail --slow validate. I believe these are two > of them: > > - https://ghc.haskell.org/trac/ghc/ticket/9567 > - https://ghc.haskell.org/trac/ghc/ticket/9566 Yeah, I believe the complete list for --slow is only 5 failures: https://ghc.haskell.org/trac/ghc/ticket/9565 - dead loop in simplifier https://ghc.haskell.org/trac/ghc/ticket/9424 - debugged ghc does not unload Show instances after data redefinition (or not :]) https://ghc.haskell.org/trac/ghc/ticket/9426 - something similar with redefinition in ghci https://ghc.haskell.org/trac/ghc/ticket/9566 - corelint error in simplifier https://ghc.haskell.org/trac/ghc/ticket/9567 - another corelint error in simplifier -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From simonpj at microsoft.com Wed Sep 10 09:53:05 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 10 Sep 2014 09:53:05 +0000 Subject: deleting branches Message-ID: <618BE556AADD624C9C918AA5D5911BEF2220B735@DB3PRD3001MB020.064d.mgd.msft.net> I accidentally created a branch (in the main repo) called origin/origin/wip/new-flatten-skolems-Aug14 I was trying to make a local branch to track the existing origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a local branch called origin/wip/new-flatten-skolems-Aug14, which I then pushed, creating the one above. It's quite confusing to me that branches (listed with git branch -av) have names like wip/rae and remotes/origin/wip/rae I suspect that the "remotes/origin" part isn't really part of the name of the branch at all, even though it is not syntactically distinguished. Anyway, I'd like to delete that branch from the main repo on the server, but I don't know how to do so. I tried git branch -D origin/origin/wip/new-flatten-skolems-Aug14 error: branch 'origin/origin/wip/new-flatten-skolems-Aug14' not found. My model of branch naming is not working well. Can anyone advise? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Sep 10 10:00:39 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 10 Sep 2014 12:00:39 +0200 Subject: deleting branches In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2220B735@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Wed, 10 Sep 2014 09:53:05 +0000") References: <618BE556AADD624C9C918AA5D5911BEF2220B735@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87sijz6bi0.fsf@gmail.com> On 2014-09-10 at 11:53:05 +0200, Simon Peyton Jones wrote: > I accidentally created a branch (in the main repo) called > origin/origin/wip/new-flatten-skolems-Aug14 > I was trying to make a local branch to track the existing > origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a > local branch called origin/wip/new-flatten-skolems-Aug14, which I then > pushed, creating the one above. > It's quite confusing to me that branches (listed with git branch -av) have names like > wip/rae > and > remotes/origin/wip/rae > I suspect that the "remotes/origin" part isn't really part of the name > of the branch at all, even though it is not syntactically > distinguished. > Anyway, I'd like to delete that branch from the main repo on the > server, but I don't know how to do so. I tried Here's the problem: you are not allowed to delete anything outside the "wip/" namespace (partly because we don't want you do delete a branch like "ghc-7.8" or "master", and partly because the submodule gitlink integrity check assumes that all branches outside "wip/" are to exist forever) however, here's how you'd usually delete that *remote* branch, if you were allowed to (and what I've just done for you, as I have the necessary perms being an Git admin): git push origin :origin/wip/new-flatten-skolems-Aug14 'git branch -D' deletes only your local branches In the future, we will restrict the ability to create new branches outside the "wip/" namespace to avoid such mistakes From afarmer at ittc.ku.edu Wed Sep 10 10:14:37 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Wed, 10 Sep 2014 11:14:37 +0100 Subject: deleting branches In-Reply-To: <87sijz6bi0.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF2220B735@DB3PRD3001MB020.064d.mgd.msft.net> <87sijz6bi0.fsf@gmail.com> Message-ID: Note the colon before the name... that is what causes the remote branch to be deleted. My understanding is that you are literally pushing a void local branch over the remote branch, which effectively deletes it. Since Git 1.7, I believe you can also: git push origin --delete origin/wip/new-flatten-skolems-Aug14 which is just sugar for what Herbert said. On Wed, Sep 10, 2014 at 11:00 AM, Herbert Valerio Riedel wrote: > On 2014-09-10 at 11:53:05 +0200, Simon Peyton Jones wrote: >> I accidentally created a branch (in the main repo) called >> origin/origin/wip/new-flatten-skolems-Aug14 >> I was trying to make a local branch to track the existing >> origin/wip/new-flatten-skolems-Aug14, but only succeeded in creating a >> local branch called origin/wip/new-flatten-skolems-Aug14, which I then >> pushed, creating the one above. >> It's quite confusing to me that branches (listed with git branch -av) have names like >> wip/rae >> and >> remotes/origin/wip/rae >> I suspect that the "remotes/origin" part isn't really part of the name >> of the branch at all, even though it is not syntactically >> distinguished. > > >> Anyway, I'd like to delete that branch from the main repo on the >> server, but I don't know how to do so. I tried > > Here's the problem: you are not allowed to delete anything outside the > "wip/" namespace (partly because we don't want you do delete a branch > like "ghc-7.8" or "master", and partly because the submodule gitlink > integrity check assumes that all branches outside "wip/" are to exist > forever) > > however, here's how you'd usually delete that *remote* branch, if you > were allowed to (and what I've just done for you, as I have the > necessary perms being an Git admin): > > git push origin :origin/wip/new-flatten-skolems-Aug14 > > > 'git branch -D' deletes only your local branches > > > In the future, we will restrict the ability to create new branches > outside the "wip/" namespace to avoid such mistakes > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From jan.stolarek at p.lodz.pl Wed Sep 10 11:32:26 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 10 Sep 2014 13:32:26 +0200 Subject: Random infrastructure requests, questions and suggestions Message-ID: <201409101332.26593.jan.stolarek@p.lodz.pl> Herbert, Austin, all, I have some questions and suggestions regarding our infrastructure: 1. Would it be possible to add a new custom field to Trac called "Wiki page"? Tickets that are about implementing a larger feature have an accompanying wiki page that summarizes the design. It would help my workflow if I could just get to that wiki page from the top of a Trac ticket. 2. I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only has links to previous ticket/next ticket in the top right of the page. So to get to the index of wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki index appears in the top right of the page. Would it be possible to have link to wiki index also in the ticket view? 3. Is it possible to enable tooltips in Phabricator? I'm not yet all that familiar with the interface and having icons that have no text and no tooltip is problematic. I need to actually click on it to see what it does (or figure it out from the link target). 4. When browsing the code in diffusion I see that my name is not linked to my phabricator account, for example here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/ Why is that happening? 5. I was thinking that perhaps harbormaster could also measure performance changes resulting from a patch, eg. by running nofib. I'm not sure if that's easy to implement or not and whether we have enough computing power to do that but I thought it's worth sharing that idea. Janek From mail at joachim-breitner.de Thu Sep 11 07:34:56 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 11 Sep 2014 09:34:56 +0200 Subject: The list fusion lab Message-ID: <1410420896.2792.3.camel@joachim-breitner.de> Hi, especially David and Dan, I wanted to announce this only when I had time to polish more corners, but since you are busy hacking on list fusion, experimenting with foldrW etc., maybe it?s better to release early (and you might enjoy polishing the corners yourself). Together with John Wiegly at ICFP, I started to create a list performance laboratory. You can find it at: https://github.com/nomeata/list-fusion-lab The idea is simple: Have a number of modules (in ListImpls/) that provide the same list functions (see ListImpls/exports). Then there is a test suite (Benchmarks.hs) and a driver (driver.hs). The latter takes, as arguments, a number of ghc binaries and a number of modules from ListImpls, compiles a small helper (ListTestsTemplate.hs) with all combinations (using CPP to select the right module), runs the benchmarks and aggregates the results. Note that the tests are not run in the same process as the runner, which reduces the number of libraries that the tested compiler needs to have installed. It is half finished in a few ways: * The reporting is unfinished. We used criterion?s default, but it is not quite what we want to see. * It still requires the tested compiler to have criterion installed, which is tricky for GHC-HEAD. I?d like to have two modules providing a function "(Int -> ()) -> IO Double", one with criterion and one with some ad-hoc measurement, and a way for the driver to choose. This way you can get rough measurements without criterion. * I?d like to also measure allocations. Again, that?d be nicer with a way of running the benchmarks without criterion. * There are clearly not enough benchmarks. The plan for this is that when evaluating a different implementation of a list function, or possibly a completely different fusion implementation (foldrW, stream fusion), we can simply add it here and have something reliable to base our decisions on, instead of waiting for one of the experienced wizards to come along and cast a verdict. Enjoy, and send pull requests! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From david.feuer at gmail.com Thu Sep 11 13:46:05 2014 From: david.feuer at gmail.com (David Feuer) Date: Thu, 11 Sep 2014 09:46:05 -0400 Subject: The list fusion lab Message-ID: Joachim Breitner wrote: > Together with John Wiegly at ICFP, I started to create a list > performance laboratory. You can find it at: > https://github.com/nomeata/list-fusion-lab Many thanks to you both! This sounds like an excellent idea. I do hope someone figures out a way around the criterion dependency shortly. Alternatively/longer term, I would love to see criterion refactored a bit?separating benchmarking and analysis into separate packages would presumably help with its dependency problems, and having the benchmarking side work with GHC HEAD reliably would be a Good Thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Sep 12 13:52:14 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 12 Sep 2014 15:52:14 +0200 Subject: AMP performance effect Message-ID: <1410529934.3292.7.camel@joachim-breitner.de> Hi, nothing overly exciting, but since I am running this ghcspeed thing, I guess I should inform you about changes, just to get some practice doing that :-) Due to various build failures, the AMP landing patch was not measured in isolation, so these numbers reflect the effect of these patches: $ git log fdfe6..1e400 --oneline 1e40037 Update nofib submodule to fix errors in main suite. 841924c build.mk.sample: Stage1 needn't be built with -fllvm 68ecc57 base: replace ver 4.7.1.0 references by 4.8.0.0 c6f502b Bump `base` version to 4.8.0.0 for real 27a642c Revert "base: Bump version to 4.8.0.0" 0829f4c base: Bump version to 4.8.0.0 d94de87 Make Applicative a superclass of Monad If you want to have a look yourself, see http://ghcspeed-nomeata.rhcloud.com/changes/?rev=1e40037604&exe=2&env=1 Notable points: * nofib running times are unchanged on average. * binary sizes are consistently reduced by a small amount (-0.7%) * one nofib benchmarks show significant increases in allocation: - cryptalgorithm2 +17,5% Unfortunately, cryptalgorithm?s runtime is below the cut-off, so I cannot tell if that has changed significantly. - all other nofib benchmarks have unchanged allocation numbers * some testsuite benchmarks as well: - T3064 +28% - T5631 + 7% - T9020 +18% - haddock-* +3% - many with no change at all, some with noise up to +2,7% I don?t think this requires action, but if someone feels inclined to find out what happened to cryptoalgorithm2 (which uses StateT), feel free to give it a shot! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ezyang at mit.edu Fri Sep 12 14:00:01 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 12 Sep 2014 10:00:01 -0400 Subject: AMP performance effect In-Reply-To: <1410529934.3292.7.camel@joachim-breitner.de> References: <1410529934.3292.7.camel@joachim-breitner.de> Message-ID: <1410530374-sup-3078@sabre> Hello Joachim, You are probably seeing the effects of this bug for cryptarithm1: https://ghc.haskell.org/trac/ghc/ticket/9570#ticket Cheers, Edward Excerpts from Joachim Breitner's message of 2014-09-12 09:52:14 -0400: > Hi, > > nothing overly exciting, but since I am running this ghcspeed thing, I > guess I should inform you about changes, just to get some practice doing > that :-) > > Due to various build failures, the AMP landing patch was not measured in > isolation, so these numbers reflect the effect of these patches: > > $ git log fdfe6..1e400 --oneline > 1e40037 Update nofib submodule to fix errors in main suite. > 841924c build.mk.sample: Stage1 needn't be built with -fllvm > 68ecc57 base: replace ver 4.7.1.0 references by 4.8.0.0 > c6f502b Bump `base` version to 4.8.0.0 for real > 27a642c Revert "base: Bump version to 4.8.0.0" > 0829f4c base: Bump version to 4.8.0.0 > d94de87 Make Applicative a superclass of Monad > > If you want to have a look yourself, see > http://ghcspeed-nomeata.rhcloud.com/changes/?rev=1e40037604&exe=2&env=1 > > Notable points: > * nofib running times are unchanged on average. > * binary sizes are consistently reduced by a small amount (-0.7%) > * one nofib benchmarks show significant increases in allocation: > - cryptalgorithm2 +17,5% > Unfortunately, cryptalgorithm?s runtime is below the cut-off, so I > cannot tell if that has changed significantly. > - all other nofib benchmarks have unchanged allocation numbers > * some testsuite benchmarks as well: > - T3064 +28% > - T5631 + 7% > - T9020 +18% > - haddock-* +3% > - many with no change at all, some with noise up to +2,7% > > I don?t think this requires action, but if someone feels inclined to > find out what happened to cryptoalgorithm2 (which uses StateT), feel > free to give it a shot! > > Greetings, > Joachim > From mail at joachim-breitner.de Fri Sep 12 14:06:51 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 12 Sep 2014 16:06:51 +0200 Subject: AMP performance effect In-Reply-To: <1410530374-sup-3078@sabre> References: <1410529934.3292.7.camel@joachim-breitner.de> <1410530374-sup-3078@sabre> Message-ID: <1410530811.3292.10.camel@joachim-breitner.de> Hi, Am Freitag, den 12.09.2014, 10:00 -0400 schrieb Edward Z. Yang: > You are probably seeing the effects of this bug for cryptarithm1: > > https://ghc.haskell.org/trac/ghc/ticket/9570#ticket possibly. But you report runtime differences without changes in allocation numbers, whereas I observed changes in allocation numbers. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From johan.tibell at gmail.com Fri Sep 12 14:10:01 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 12 Sep 2014 16:10:01 +0200 Subject: AMP performance effect In-Reply-To: <1410529934.3292.7.camel@joachim-breitner.de> References: <1410529934.3292.7.camel@joachim-breitner.de> Message-ID: On Fri, Sep 12, 2014 at 3:52 PM, Joachim Breitner wrote: > nothing overly exciting, but since I am running this ghcspeed thing, I > guess I should inform you about changes, just to get some practice doing > that :-) I'm very much in support of doing this. Once we think pagespeed is stable enough, I would be for sending automated emails on regressions. If you need a different machine to host it, you can reach out to admin at haskell.org. If they don't have one, I have a quiet quite powerful machine in a data center. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Sep 12 14:28:06 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 12 Sep 2014 16:28:06 +0200 Subject: AMP performance effect In-Reply-To: References: <1410529934.3292.7.camel@joachim-breitner.de> Message-ID: <1410532086.3292.14.camel@joachim-breitner.de> Hi, Am Freitag, den 12.09.2014, 16:10 +0200 schrieb Johan Tibell: > Once we think pagespeed is stable enough, I would be for sending > automated emails on regressions. it is quite noisy, which is mostly due to the fact that I track the ?number of failing testcases? as a performance value, which regularly goes +? (e.g. from 0 to 1). I?m still worried about sending mails out, but interested parties are welcome to subscribe to the RSS feed at http://ghcspeed-nomeata.rhcloud.com/feeds/latest_significant/ Also, ghcspeed has no support for sending mails yet, so we would either have to add that or use the RSS feed with some RSS-to-mail tool. > If you need a different machine to host it, you can reach out to > admin at haskell.org. If they don't have one, I have a quiet quite > powerful machine in a data center. During ICFP, Ryan Newton also offered me a machine. We can actually start using a new maching while keeping the old one running, codespeed allows to distinguish between them. So let?s start on this: Either give me a user account somewhere, or ? as it is simple ? try it yourself using the scripts in https://github.com/nomeata/codespeed/tree/ghc/tools/ghc (maybe while I?m in IRC or so). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mikolaj at well-typed.com Fri Sep 12 17:02:39 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Fri, 12 Sep 2014 19:02:39 +0200 Subject: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux Message-ID: Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors): http://www.haskell.org/haskellwiki/GHC_under_Wine https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 Examples of both kinds of binaries, for a project with gtk2hs and TH dependency: https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0 Please share your success reports here or on the wiki and let's exchange ideas, file concrete tickets and propose patches to make the two processes more accessible. Some tickets are mentioned in the wikis or can be traced from there, but there may be others I'm not aware of, so let's link them where appropriate. Hope this helps somebody, Mikolaj From mikolaj at well-typed.com Fri Sep 12 17:12:53 2014 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Fri, 12 Sep 2014 19:12:53 +0200 Subject: win32 GHC 7.8.3 works under Wine and i386-linux GHC 7.8.3 works under amd64-linux In-Reply-To: References: Message-ID: (cross-com^H^H^Hposting to glasgow-haskell-users at haskell.org) Well, sorf-of. A few extra unobvious parameters and workarounds are required in each case, but it's doable, (arguably) simpler than real cross-compilation and already exhibits problems that real cross-compilation may in some circumstances face. Wiki pages (kudos to all previous authors): http://www.haskell.org/haskellwiki/GHC_under_Wine https://ghc.haskell.org/trac/ghc/wiki/Building/Compiling32on64 Examples of both kinds of binaries, for a project with gtk2hs and TH dependency: https://github.com/LambdaHack/LambdaHack/releases/tag/v0.4.99.0 Please share your success reports here or on the wiki and let's exchange ideas, file concrete tickets and propose patches to make the two processes more accessible. Some tickets are mentioned in the wikis or can be traced from there, but there may be others I'm not aware of, so let's link them where appropriate. Hope this helps somebody, Mikolaj From ezyang at mit.edu Fri Sep 12 17:45:44 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 12 Sep 2014 13:45:44 -0400 Subject: HEAD fails to bootstrap with HEAD? In-Reply-To: <540D5904.2050102@centrum.cz> References: <540D5904.2050102@centrum.cz> Message-ID: <1410543878-sup-4757@sabre> Hello Karel, When this commit makes it in https://github.com/haskell/cabal/commit/8d59dc9fba584a9fdb810f4d84f7f3ccb089dd08 it will work; but updating Cabal to HEAD is blocking on https://ghc.haskell.org/trac/ghc/ticket/9583 Cheers, Edward Excerpts from Karel Gardas's message of 2014-09-08 03:21:40 -0400: > Hello, > > I've noticed that probably after cabal/ghc-pkg changes done recently > HEAD fails to build with HEAD in following way: > > [80 of 80] Compiling Main ( utils/ghc-cabal/Main.hs, > bootstrapping/Main.o ) > Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ... > "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal > "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal > "inplace/bin/mkdirhier" compiler/stage1/build//. > "rm" -f compiler/stage1/build/Config.hs > Creating compiler/stage1/build/Config.hs ... > done. > "inplace/bin/ghc-cabal" configure libraries/Cabal/Cabal dist-boot "" > --with-ghc="/opt/ghc-7.9.20140906-amd64/bin/ghc" > --with-ghc-pkg="/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg" > --package-db=/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf > --disable-library-for-ghci --enable-library-vanilla > --disable-library-profiling --disable-shared > --with-hscolour="/export/home/karel/.cabal/bin/HsColour" > --configure-option=CFLAGS=" -m64 -fno-stack-protector " > --configure-option=LDFLAGS=" -m64 " --configure-option=CPPFLAGS=" -m64 > " --gcc-options=" -m64 -fno-stack-protector -m64 " > --configure-option=--with-gmp-includes="/usr/include/gmp" > --configure-option=--with-gmp-libraries="/usr/lib/" --constraint > "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.1" --constraint > "binary == 0.7.1.0" --constraint "bin-package-db == 0.0.0.0" > --constraint "hoopl == 3.10.0.1" --constraint "transformers == > 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" > --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/xpg4/bin/ar" > --with-alex="/export/home/karel/.cabal/bin/alex" > --with-happy="/export/home/karel/.cabal/bin/happy" > Configuring Cabal-1.21.1.0... > ghc-cabal: '/opt/ghc-7.9.20140906-amd64/bin/ghc-pkg' exited with an error: > ghc-pkg: ghc no longer supports single-file style package databases > (/export/home/karel/vcs/ghc-src/head/libraries/bootstrapping.conf) use > 'ghc-pkg init' to create the database with the correct format. > gmake[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 > gmake: *** [all] Error 2 > > > I've been able to solve this by: > > $ rm libraries/bootstrapping.conf > $ /opt/ghc-7.9.20140906-amd64/bin/ghc-pkg init libraries/bootstrapping.conf > > however it's kind of impractical to do that on buildbot (solaris/amd64). > Is it possible to fix that somehow? > > Thanks! > Karel From moritz at lichtzwerge.de Fri Sep 12 18:53:19 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Fri, 12 Sep 2014 20:53:19 +0200 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe Message-ID: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> Hi, when trying to compile a ghc HEAD on LLVM ARM, I end up getting an exception: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for arm-apple-ios): globalRegMaybe After some digging I found that a new call to globalRegMaybe was introduced here: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on 2014-04-29 in commit: http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf3353412b9877 In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was changed: http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a8308e..HEAD:/includes/CodeGen.Platform.hs introducing a set of new ifdef/elif/endif pairs. Especially for MACHREGS_NO_REGS, namely: -#endif globalRegMaybe _ = Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif ARM.hs (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: #define MACHREGS_NO_REGS 0 #define MACHREGS_arm 1 where MACHREGS_arm 1 has no effect on the subsequently imported CodeGen.Platform.hs. Therefore I propose that a change to ARM.hs is made to set MACHREGS_NO_REGS to 1. Cheers, Moritz From david.feuer at gmail.com Sat Sep 13 04:01:55 2014 From: david.feuer at gmail.com (David Feuer) Date: Sat, 13 Sep 2014 00:01:55 -0400 Subject: FoldrW/buildW issues In-Reply-To: <1410546936.27344.2.camel@joachim-breitner.de> References: <1410546936.27344.2.camel@joachim-breitner.de> Message-ID: On Sep 12, 2014 2:35 PM, "Joachim Breitner" wrote: > Interesting. I assumed that some wrap.unwrap=id law would hold, or at > least some moral approximation (e.g. disregarding bottoms in an > acceptable manner). But if the wrappers have to do arbitrary stuff that > can arbitrarily interact with how the producer calls them, this becomes > a bit less appealing. No, nothing pleasant like that, I'm afraid. isoSimple is like that of course, but once it gets to foldl, the fusion rule is handing the builder a wrap/unwrap pair that isn't even close to that. > > 2. Somewhat related to the above, this framework has a huge amount of > > "wiggle room". There is very little to guide the choice of Wrap type. > > I guess that would be resolved by time and experience, if we?d employ > that scheme. But maybe we don?t. The only way I would imagine would be if it turned out there were a few types that could be composed somehow. But when I, experimentally, applied Dan Doel's scanl wrapper type combined with Simple to (!!), I just got wrong answers. > > Do you have any ideas? > > Directly related to foldrW, no. > > About list fusion and foldl in general, some half-baked. > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. How does that work exactly? Where do you stick the oneShot/why is it valid? > Another idea, probably with the same effect: What happens if we extend > build :: (forall b. (a -> b -> b) -> b -> b) -> [a] > to > buildI :: (forall b. (a -> b -> b) -> b -> (b -> b) -> b) -> [a] > where the extra argument is the identity, but magically ?improves values > of type b?. So with > > enum = buildI $ \c n imp -> go 0 > where go i = imp $ case i of 100 -> n ; _ -> i `c` go (i+1) > > and > > foldl f a0 = foldrI (\x k a -> k (f x a)) id (\k a -> k a) a0 > > we might get good code (but this is half-baked and written as I go). It sounds a lot like the foldrW/buildW thing again, but maybe you can do better with it. > Shouldn?t this be on ghc-dev where others can join an, and people will > find it in the archives later? I prefer to reserve private mail to, > well, private matters :-) If you like. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Sep 13 07:51:01 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 13 Sep 2014 09:51:01 +0200 Subject: FoldrW/buildW issues In-Reply-To: References: <1410546936.27344.2.camel@joachim-breitner.de> Message-ID: <1410594661.2818.3.camel@joachim-breitner.de> Hi, Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: > On Sep 12, 2014 2:35 PM, "Joachim Breitner" > wrote: > > Interesting. I assumed that some wrap.unwrap=id law would hold, or > at > > least some moral approximation (e.g. disregarding bottoms in an > > acceptable manner). But if the wrappers have to do arbitrary stuff > that > > can arbitrarily interact with how the producer calls them, this > becomes > > a bit less appealing. > > No, nothing pleasant like that, I'm afraid. isoSimple is like that of > course, but once it gets to foldl, the fusion rule is handing the > builder a wrap/unwrap pair that isn't even close to that. and parametricity doesn?t help here? Note that due to the forall in the type of buildW, you can probably reason about what kind of values buildW can produce, as it can only use whatever the consumer handed to it. Maybe there is an invariant for that type, and the worker/wrapper pair is the identity for values that fulfill that invariant. > > > Do you have any ideas? > > > > Directly related to foldrW, no. > > > > About list fusion and foldl in general, some half-baked. > > > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > > function, semantically the identity, but tell the compiler not to share > > the result of the computation. Using that in the definition of > > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > > more reliable. I need to investigate if that solves the sumConcatInits > > problem. > > How does that work exactly? Where do you stick the oneShot/ Quite simple, see the attached patch. I think I lost the corresponding patch to base due to the merge, but all it did was to write foldl k z xs = foldr (\v fn -> oneShot (\ z -> fn ( k z v ))) id xs z also see http://www.joachim-breitner.de/publications/CallArity-TFP.pdf ?6.2. > why is it valid? Because the type of build allows the builder to use each result of the ?constructor? to be used once, and the whole result is called once, by foldl, with z as the argument. ... at least if the list is finite. If build re-uses a result, then because it builds an infinite list (e.g. in repeat x = build $ \c _ -> let r = x `c` r in r ) and I?m not quite sure if that is a problem. Probably not here, because foldl applied to an infinite list is is ? anyways. But with others (e.g. scanl) I might be wrong and the oneShot trick might not work there. > > Another idea, probably with the same effect: What happens if we extend > > build :: (forall b. (a -> b -> b) -> b -> b) -> [a] > > to > > buildI :: (forall b. (a -> b -> b) -> b -> (b -> b) -> b) -> [a] > > where the extra argument is the identity, but magically ?improves values > > of type b?. So with > > > > enum = buildI $ \c n imp -> go 0 > > where go i = imp $ case i of 100 -> n ; _ -> i `c` go (i+1) > > > > and > > > > foldl f a0 = foldrI (\x k a -> k (f x a)) id (\k a -> k a) a0 > > > > we might get good code (but this is half-baked and written as I go). > > It sounds a lot like the foldrW/buildW thing again, but maybe you can > do better with it. Yes, it is very much inspired by it, but possibly simpler, and much weaker: It doesn?t try to undo the continuation style of foldl, but only helps the compiler a bit. I don?t like it a lot, though. Gru?, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: oneShot.patch Type: text/x-patch Size: 3246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From david.feuer at gmail.com Sun Sep 14 17:03:06 2014 From: david.feuer at gmail.com (David Feuer) Date: Sun, 14 Sep 2014 13:03:06 -0400 Subject: FoldrW/buildW issues Message-ID: Joachim Breitner wrote: > Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: > > On Sep 12, 2014 2:35 PM, "Joachim Breitner" > > wrote: > > > Interesting. I assumed that some wrap.unwrap=id law would hold, or > > at > > > least some moral approximation (e.g. disregarding bottoms in an > > > acceptable manner). But if the wrappers have to do arbitrary stuff > > that > > > can arbitrarily interact with how the producer calls them, this > > becomes > > > a bit less appealing. > > > > No, nothing pleasant like that, I'm afraid. isoSimple is like that of > > course, but once it gets to foldl, the fusion rule is handing the > > builder a wrap/unwrap pair that isn't even close to that. > > and parametricity doesn't help here? Note that due to the forall in the > type of buildW, you can probably reason about what kind of values buildW > can produce, as it can only use whatever the consumer handed to it. > Maybe there is an invariant for that type, and the worker/wrapper pair > is the identity for values that fulfill that invariant. > That seems reasonable, and I suspect without any proof that Takano Akio's wrapper for foldl and Dan Doel's wrapper for reverse probably satisfy it. Scans seem to be more of a challenge. It appears to me that Dan's scanl wrapper probably does *not* satisfy that requirement, and I don't know enough to have much chance of finding one that does. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Sun Sep 14 18:08:34 2014 From: dan.doel at gmail.com (Dan Doel) Date: Sun, 14 Sep 2014 14:08:34 -0400 Subject: FoldrW/buildW issues In-Reply-To: References: Message-ID: Which scanl wrapper are you referring to? The first one I figured out was quite wrong in certain ways. But I think the new one is less controversial; it's a lot like the reverse one. On Sun, Sep 14, 2014 at 1:03 PM, David Feuer wrote: > Joachim Breitner wrote: > >> Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: >> > On Sep 12, 2014 2:35 PM, "Joachim Breitner" >> > wrote: >> > > Interesting. I assumed that some wrap.unwrap=id law would hold, or >> > at >> > > least some moral approximation (e.g. disregarding bottoms in an >> > > acceptable manner). But if the wrappers have to do arbitrary stuff >> > that >> > > can arbitrarily interact with how the producer calls them, this >> > becomes >> > > a bit less appealing. >> > >> > No, nothing pleasant like that, I'm afraid. isoSimple is like that of >> > course, but once it gets to foldl, the fusion rule is handing the >> > builder a wrap/unwrap pair that isn't even close to that. >> >> and parametricity doesn't help here? Note that due to the forall in the >> type of buildW, you can probably reason about what kind of values buildW >> can produce, as it can only use whatever the consumer handed to it. >> Maybe there is an invariant for that type, and the worker/wrapper pair >> is the identity for values that fulfill that invariant. >> > > That seems reasonable, and I suspect without any proof that Takano Akio's > wrapper for foldl and Dan Doel's wrapper for reverse probably satisfy it. > Scans seem to be more of a challenge. It appears to me that Dan's scanl > wrapper probably does *not* satisfy that requirement, and I don't know > enough to have much chance of finding one that does. > > David > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Sep 14 18:47:34 2014 From: david.feuer at gmail.com (David Feuer) Date: Sun, 14 Sep 2014 14:47:34 -0400 Subject: FoldrW/buildW issues In-Reply-To: References: Message-ID: Your scanl wrapper might be right for scanl, but it does not satisfy the condition Joachim proposed. In particular, if we define (!!) :: [a] -> Int -> a xs !! n | n < 0 = error "Negative index." | otherwise = foldrW indexWrap indexCons (error "Large index.") xs n where indexCons x _ 0 = x indexCons _ r n = r (n-1) indexWrap = isoSimple then the simple test print $ (reverse $ eft 1 1000) !! 50 works just fine. If we replace isoSimple with scanlWrap isoSimple, then the test fails. That is, this produces wrap and unwrap so that wrap . unwrap is not much like the identity; it needs to interact with scanlCons in some fashion to work properly. This does not seem to be at all unusual for worker/wrapper pairs, but i believe it means we need to find a more general local correctness criterion than Joachim proposed, if I understood him correctly. David On Sun, Sep 14, 2014 at 2:08 PM, Dan Doel wrote: > Which scanl wrapper are you referring to? > > The first one I figured out was quite wrong in certain ways. But I think > the new one is less controversial; it's a lot like the reverse one. > > On Sun, Sep 14, 2014 at 1:03 PM, David Feuer > wrote: > >> Joachim Breitner wrote: >> >>> Am Samstag, den 13.09.2014, 00:01 -0400 schrieb David Feuer: >>> > On Sep 12, 2014 2:35 PM, "Joachim Breitner" >>> > wrote: >>> > > Interesting. I assumed that some wrap.unwrap=id law would hold, or >>> > at >>> > > least some moral approximation (e.g. disregarding bottoms in an >>> > > acceptable manner). But if the wrappers have to do arbitrary stuff >>> > that >>> > > can arbitrarily interact with how the producer calls them, this >>> > becomes >>> > > a bit less appealing. >>> > >>> > No, nothing pleasant like that, I'm afraid. isoSimple is like that of >>> > course, but once it gets to foldl, the fusion rule is handing the >>> > builder a wrap/unwrap pair that isn't even close to that. >>> >>> and parametricity doesn't help here? Note that due to the forall in the >>> type of buildW, you can probably reason about what kind of values buildW >>> can produce, as it can only use whatever the consumer handed to it. >>> Maybe there is an invariant for that type, and the worker/wrapper pair >>> is the identity for values that fulfill that invariant. >>> >> >> That seems reasonable, and I suspect without any proof that Takano Akio's >> wrapper for foldl and Dan Doel's wrapper for reverse probably satisfy it. >> Scans seem to be more of a challenge. It appears to me that Dan's scanl >> wrapper probably does *not* satisfy that requirement, and I don't know >> enough to have much chance of finding one that does. >> >> David >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Sep 14 20:11:35 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Sep 2014 22:11:35 +0200 Subject: The list fusion lab In-Reply-To: References: Message-ID: <1410725495.2862.4.camel@joachim-breitner.de> Hi, Am Donnerstag, den 11.09.2014, 09:46 -0400 schrieb David Feuer: > Joachim Breitner wrote: > > Together with John Wiegly at ICFP, I started to create a list > > performance laboratory. You can find it at: > > https://github.com/nomeata/list-fusion-lab > > Many thanks to you both! This sounds like an excellent idea. I do hope > someone figures out a way around the criterion dependency shortly. If you run it without --criterion, it?ll use a very naive benchmarking. Maybe someone with experience in this area can have a look at the code: https://github.com/nomeata/list-fusion-lab/blob/master/MeasureNaive.hs But anyways, the list-fusion-lab should be in shape to start putting some benchmarks and alternative implementation in; we can polish the rough edges as we use it. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sun Sep 14 20:16:55 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Sep 2014 22:16:55 +0200 Subject: FoldrW/buildW issues In-Reply-To: References: Message-ID: <1410725815.2862.6.camel@joachim-breitner.de> Hi, Am Sonntag, den 14.09.2014, 14:47 -0400 schrieb David Feuer: > Your scanl wrapper might be right for scanl, but it does not satisfy > the condition Joachim proposed. In particular, if we define > > (!!) :: [a] -> Int -> a > xs !! n > | n < 0 = error "Negative index." > | otherwise = foldrW indexWrap indexCons (error "Large index.") xs n > where > indexCons x _ 0 = x > indexCons _ r n = r (n-1) > indexWrap = isoSimple > > > then the simple test > > > print $ (reverse $ eft 1 1000) !! 50 > > > > works just fine. If we replace isoSimple with scanlWrap isoSimple, > then the test fails. That is, this produces wrap and unwrap so that > wrap . unwrap is not much like the identity; it needs to interact with > scanlCons in some fashion to work properly. This does not seem to be > at all unusual for worker/wrapper pairs, but i believe it means we > need to find a more general local correctness criterion than Joachim > proposed, if I understood him correctly. it would be easier to follow your discussion if you include concrete pointers to code in your mail, or include the code in question; i?m having trouble finding scanlWrap and scanlCons... (and so has Google). Anyways, the correctness criterion, if any, would relate scanlWrap with scanlCons and scanlNil; breakage due to using scanlWrap in a different consumer does not mean that we cannot find a (scanl-specific) invariant that allows us to prove fusion correct for foldrW/buidW fusion of scanl (as a consumer). Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From carter.schonwald at gmail.com Sun Sep 14 20:26:03 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 14 Sep 2014 16:26:03 -0400 Subject: The list fusion lab In-Reply-To: <1410725495.2862.4.camel@joachim-breitner.de> References: <1410725495.2862.4.camel@joachim-breitner.de> Message-ID: what fails to build with head? (current head + cabal have that fix that still need merging in, so its hard to try criterion with current todays head, which is all i have handy at present) On Sun, Sep 14, 2014 at 4:11 PM, Joachim Breitner wrote: > Hi, > > > Am Donnerstag, den 11.09.2014, 09:46 -0400 schrieb David Feuer: > > Joachim Breitner wrote: > > > Together with John Wiegly at ICFP, I started to create a list > > > performance laboratory. You can find it at: > > > https://github.com/nomeata/list-fusion-lab > > > > Many thanks to you both! This sounds like an excellent idea. I do hope > > someone figures out a way around the criterion dependency shortly. > > If you run it without --criterion, it?ll use a very naive benchmarking. > Maybe someone with experience in this area can have a look at the code: > https://github.com/nomeata/list-fusion-lab/blob/master/MeasureNaive.hs > > > But anyways, the list-fusion-lab should be in shape to start putting > some benchmarks and alternative implementation in; we can polish the > rough edges as we use it. > > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Sep 14 20:41:40 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Sep 2014 22:41:40 +0200 Subject: The list fusion lab In-Reply-To: References: <1410725495.2862.4.camel@joachim-breitner.de> Message-ID: <1410727300.2862.8.camel@joachim-breitner.de> Hi, Am Sonntag, den 14.09.2014, 16:26 -0400 schrieb Carter Schonwald: > what fails to build with head? (current head + cabal have that fix > that still need merging in, so its hard to try criterion with current > todays head, which is all i have handy at present) > some weeks ago, I had problems in statistics, which I worked around with https://ghc.haskell.org/trac/ghc/attachment/ticket/9190/statistics-0.11.0.3.patch Granted, I didn?t try recently. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sophie at traumapony.org Mon Sep 15 07:30:35 2014 From: sophie at traumapony.org (Sophie Taylor) Date: Mon, 15 Sep 2014 17:30:35 +1000 Subject: Preliminary proposal: Monoidal categories in base and proc notation support Message-ID: Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Sep 15 08:24:54 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 15 Sep 2014 11:24:54 +0300 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: References: Message-ID: <1410769494.14293.0.camel@sniper.lan> On Mon, 2014-09-15 at 17:30 +1000, Sophie Taylor wrote: > Hi everyone. > > > I am working on a proposal for some additions to the base library and > some modifications to GHC in the same style as the do notation support > for Applicatives. It is still very much a work in progress, but any > input/constructive criticism would be greatly appreciated; this is the > first one of these I've written. > > > Here is the proposal in its current > form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Hi Sophie, In your proposal draft, I am missing the rationale part. Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jan.stolarek at p.lodz.pl Mon Sep 15 09:13:35 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 15 Sep 2014 11:13:35 +0200 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> Message-ID: <201409151113.35212.jan.stolarek@p.lodz.pl> I think it is best to fill in a bug report and attach a patch - I'm afraid this mail may have gone unnoticed :-) Janek Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: > Hi, > > when trying to compile a ghc HEAD on LLVM ARM, I end up getting an > exception: > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 7.9.20140911 for arm-apple-ios): > globalRegMaybe > > After some digging I found that a new call to globalRegMaybe was introduced > here: > http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on > 2014-04-29 in commit: > http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534 >12b9877 > > In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was > changed: > http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a >8308e..HEAD:/includes/CodeGen.Platform.hs > > introducing a set of new ifdef/elif/endif pairs. Especially for > MACHREGS_NO_REGS, namely: > > -#endif > globalRegMaybe _ = Nothing > +#elif MACHREGS_NO_REGS > +globalRegMaybe _ = Nothing > +#else > +globalRegMaybe = panic "globalRegMaybe not defined for this platform" > +#endif > > ARM.hs > (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169 >ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: > > #define MACHREGS_NO_REGS 0 > #define MACHREGS_arm 1 > > where MACHREGS_arm 1 has no effect on the subsequently imported > CodeGen.Platform.hs. > > Therefore I propose that a change to ARM.hs is made to set > MACHREGS_NO_REGS to 1. > > Cheers, > Moritz > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Mon Sep 15 09:19:13 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Mon, 15 Sep 2014 11:19:13 +0200 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <201409151113.35212.jan.stolarek@p.lodz.pl> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> <201409151113.35212.jan.stolarek@p.lodz.pl> Message-ID: <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> Hi Janek, yea :) I think it went by unnoticed. Patch is already in Phab, https://phabricator.haskell.org/D208 Not sure how to speed up the review process, though ;-) Cheers, Moritz On Sep 15, 2014, at 11:13 AM, Jan Stolarek wrote: > I think it is best to fill in a bug report and attach a patch - I'm afraid this mail may have gone > unnoticed :-) > > Janek > > Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: >> Hi, >> >> when trying to compile a ghc HEAD on LLVM ARM, I end up getting an >> exception: >> >> ghc-stage1: panic! (the 'impossible' happened) >> (GHC version 7.9.20140911 for arm-apple-ios): >> globalRegMaybe >> >> After some digging I found that a new call to globalRegMaybe was introduced >> here: >> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 on >> 2014-04-29 in commit: >> http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf33534 >> 12b9877 >> >> In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs was >> changed: >> http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd6a >> 8308e..HEAD:/includes/CodeGen.Platform.hs >> >> introducing a set of new ifdef/elif/endif pairs. Especially for >> MACHREGS_NO_REGS, namely: >> >> -#endif >> globalRegMaybe _ = Nothing >> +#elif MACHREGS_NO_REGS >> +globalRegMaybe _ = Nothing >> +#else >> +globalRegMaybe = panic "globalRegMaybe not defined for this platform" >> +#endif >> >> ARM.hs >> (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d506857674169 >> ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: >> >> #define MACHREGS_NO_REGS 0 >> #define MACHREGS_arm 1 >> >> where MACHREGS_arm 1 has no effect on the subsequently imported >> CodeGen.Platform.hs. >> >> Therefore I propose that a change to ARM.hs is made to set >> MACHREGS_NO_REGS to 1. >> >> Cheers, >> Moritz >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > From sophie at traumapony.org Mon Sep 15 09:32:44 2014 From: sophie at traumapony.org (Sophie Taylor) Date: Mon, 15 Sep 2014 19:32:44 +1000 Subject: Preliminary proposal: Monoidal categories in base and proc notation support Message-ID: >Hi Sophie, >In your proposal draft, I am missing the rationale part. Yeah, I'm still writing it - I definitely need to expand that a bit mor. >Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 12:05:27 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 12:05:27 +0000 Subject: cminusminus.org does not have a link to the spec In-Reply-To: <20140914191604.199a3f50@sf> References: <20140914191604.199a3f50@sf> Message-ID: <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich at gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit "import" statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei From simonpj at microsoft.com Mon Sep 15 12:13:55 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 12:13:55 +0000 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF22215A82@DB3PRD3001MB020.064d.mgd.msft.net> Sophie I?m guessing that the primary audience for your proposal is the Core Libraries Committee, rather than GHC itself. I?m cc?ing them. So far as GHC is concerned, there is a long-running ticket #7828 that your proposal may bear on. I am not satisfied with GHC?s treatment of arrows; it is complex and I do not fully understand it myself. If you were able to join in the effort to simplify and modularise the story, that would be great. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sophie Taylor Sent: 15 September 2014 08:31 To: ghc-devs at haskell.org Subject: Preliminary proposal: Monoidal categories in base and proc notation support Hi everyone. I am working on a proposal for some additions to the base library and some modifications to GHC in the same style as the do notation support for Applicatives. It is still very much a work in progress, but any input/constructive criticism would be greatly appreciated; this is the first one of these I've written. Here is the proposal in its current form: http://blog.spacekitteh.moe/posts/new-monoidal-cats.html Thanks, Sophie Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 12:17:53 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 12:17:53 +0000 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> <201409151113.35212.jan.stolarek@p.lodz.pl> <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22215ACC@DB3PRD3001MB020.064d.mgd.msft.net> Is there a Trac ticket too? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Moritz | Angermann | Sent: 15 September 2014 10:19 | To: ghc-devs at haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Hi Janek, | | yea :) I think it went by unnoticed. Patch is already in Phab, | | https://phabricator.haskell.org/D208 | | Not sure how to speed up the review process, though ;-) | | Cheers, | Moritz | | On Sep 15, 2014, at 11:13 AM, Jan Stolarek | wrote: | | > I think it is best to fill in a bug report and attach a patch - I'm | afraid this mail may have gone | > unnoticed :-) | > | > Janek | > | > Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: | >> Hi, | >> | >> when trying to compile a ghc HEAD on LLVM ARM, I end up getting an | >> exception: | >> | >> ghc-stage1: panic! (the 'impossible' happened) | >> (GHC version 7.9.20140911 for arm-apple-ios): | >> globalRegMaybe | >> | >> After some digging I found that a new call to globalRegMaybe was | introduced | >> here: | >> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 | on | >> 2014-04-29 in commit: | >> | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 | 34 | >> 12b9877 | >> | >> In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs | was | >> changed: | >> | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd | 6a | >> 8308e..HEAD:/includes/CodeGen.Platform.hs | >> | >> introducing a set of new ifdef/elif/endif pairs. Especially for | >> MACHREGS_NO_REGS, namely: | >> | >> -#endif | >> globalRegMaybe _ = Nothing | >> +#elif MACHREGS_NO_REGS | >> +globalRegMaybe _ = Nothing | >> +#else | >> +globalRegMaybe = panic "globalRegMaybe not defined for this | platform" | >> +#endif | >> | >> ARM.hs | >> | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 | 69 | >> ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: | >> | >> #define MACHREGS_NO_REGS 0 | >> #define MACHREGS_arm 1 | >> | >> where MACHREGS_arm 1 has no effect on the subsequently imported | >> CodeGen.Platform.hs. | >> | >> Therefore I propose that a change to ARM.hs is made to set | >> MACHREGS_NO_REGS to 1. | >> | >> Cheers, | >> Moritz | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://www.haskell.org/mailman/listinfo/ghc-devs | > | > | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Mon Sep 15 12:26:30 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Sep 2014 07:26:30 -0500 Subject: It's that time again (for the HCAR) Message-ID: Hi *, It is that time again where once every 6 months, we write our entry for the Haskell Communities and Activities Report (HCAR), summarizing what exactly we're all doing. I say 'we' write this of course because I need everyone to write some stuff on what they're doing. :) I'll editorialize it before sending it in, but please feel free to add things. I've drafted a very basic page, based on the last one: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 I sort of selectively cherry-picked some things from the prior 7.10 updates. Again, please feel free to add things as you see fit. I eagerly await your edits! Let's try to get this one done on time. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From pali.gabor at gmail.com Mon Sep 15 12:30:50 2014 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Mon, 15 Sep 2014 14:30:50 +0200 Subject: The build is broken on {32,64}-bit Windows Message-ID: Hello there, For your information, the build has been failing for a few days now on both my Windows builders [1][2], basically in the same way. [...] librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Could somebody do something with this, or does anybody have hints on how to fix this? Looks like the culprit is the haskeline library. [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html From austin at well-typed.com Mon Sep 15 12:33:16 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Sep 2014 07:33:16 -0500 Subject: The build is broken on {32,64}-bit Windows In-Reply-To: References: Message-ID: Grrr, this is my fault (AMP fallout). Fix incoming. On Mon, Sep 15, 2014 at 7:30 AM, P?li G?bor J?nos wrote: > Hello there, > > For your information, the build has been failing for a few days now on > both my Windows builders [1][2], basically in the same way. > > [...] > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (Monad (Draw m)) > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadIO (Draw m)) > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadException (Draw m)) > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadReader Handles (Draw m)) > libraries/haskeline/ghc.mk:4: recipe for target > 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' > failed > make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] > Error 1 > Makefile:71: recipe for target 'all' failed > make: *** [all] Error 2 > > Could somebody do something with this, or does anybody have hints on > how to fix this? Looks like the culprit is the haskeline library. > > > [1] http://haskell.inf.elte.hu/builders/windows-x86-head/34/10.html > [2] http://haskell.inf.elte.hu/builders/windows-x86_64-head/29/10.html > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From moritz at lichtzwerge.de Mon Sep 15 12:51:00 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Mon, 15 Sep 2014 14:51:00 +0200 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22215ACC@DB3PRD3001MB020.064d.mgd.msft.net> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> <201409151113.35212.jan.stolarek@p.lodz.pl> <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF22215ACC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <32F83D1F-8FFD-48DF-8ED2-ADA9BA9FCDB5@lichtzwerge.de> Dear Simon, No, there is not. Should every patch in Phab, have an associated ticket as well? Cheers, Moritz On Sep 15, 2014, at 2:17 PM, Simon Peyton Jones wrote: > Is there a Trac ticket too? > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Moritz > | Angermann > | Sent: 15 September 2014 10:19 > | To: ghc-devs at haskell.org > | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe > | > | Hi Janek, > | > | yea :) I think it went by unnoticed. Patch is already in Phab, > | > | https://phabricator.haskell.org/D208 > | > | Not sure how to speed up the review process, though ;-) > | > | Cheers, > | Moritz > | > | On Sep 15, 2014, at 11:13 AM, Jan Stolarek > | wrote: > | > | > I think it is best to fill in a bug report and attach a patch - I'm > | afraid this mail may have gone > | > unnoticed :-) > | > > | > Janek > | > > | > Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: > | >> Hi, > | >> > | >> when trying to compile a ghc HEAD on LLVM ARM, I end up getting an > | >> exception: > | >> > | >> ghc-stage1: panic! (the 'impossible' happened) > | >> (GHC version 7.9.20140911 for arm-apple-ios): > | >> globalRegMaybe > | >> > | >> After some digging I found that a new call to globalRegMaybe was > | introduced > | >> here: > | >> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 > | on > | >> 2014-04-29 in commit: > | >> > | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 > | 34 > | >> 12b9877 > | >> > | >> In a similar timeframe (since 2014-05-02) /include/CodeGen.Platform.hs > | was > | >> changed: > | >> > | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd > | 6a > | >> 8308e..HEAD:/includes/CodeGen.Platform.hs > | >> > | >> introducing a set of new ifdef/elif/endif pairs. Especially for > | >> MACHREGS_NO_REGS, namely: > | >> > | >> -#endif > | >> globalRegMaybe _ = Nothing > | >> +#elif MACHREGS_NO_REGS > | >> +globalRegMaybe _ = Nothing > | >> +#else > | >> +globalRegMaybe = panic "globalRegMaybe not defined for this > | platform" > | >> +#endif > | >> > | >> ARM.hs > | >> > | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 > | 69 > | >> ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: > | >> > | >> #define MACHREGS_NO_REGS 0 > | >> #define MACHREGS_arm 1 > | >> > | >> where MACHREGS_arm 1 has no effect on the subsequently imported > | >> CodeGen.Platform.hs. > | >> > | >> Therefore I propose that a change to ARM.hs is made to set > | >> MACHREGS_NO_REGS to 1. > | >> > | >> Cheers, > | >> Moritz > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs at haskell.org > | >> http://www.haskell.org/mailman/listinfo/ghc-devs > | > > | > > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Mon Sep 15 13:22:11 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Sep 2014 08:22:11 -0500 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: <201409101332.26593.jan.stolarek@p.lodz.pl> References: <201409101332.26593.jan.stolarek@p.lodz.pl> Message-ID: OK, so we discussed this a bit on IRC this morning, so I'm going to continue the discussion here for people to raise some inputs, particularly for #1: 1. I think this would be OK, but I'm rather neutral. Herbert is concerned I think about the proliferation of fields for our tickets, but I think this is reasonable. Would anyone else want this? It's easy to add, at least. 2. I don't think we actually came to a conclusion on whether this is doable. 3. No, there aren't tooltips I'm afraid. I'm afraid navigating the UI is a bit trial and error sometimes, but I'd like to know what problems you had. 4. I think this is a minor bug we can solve by just rescanning the repository information from ghc.git. 5. Long term, I think Phabricator has some goals to try and do this with its Charting/Facts application, but there isn't really anything today I'm afraid that would be easy. We could have Phabricator submit information to Joachim's ghcspeed instance, but I'm not sure if it's really designed to handle that kind of workflow. Maybe we should write a custom tool after all, but right now I think this is going to take some more thinking first. On Wed, Sep 10, 2014 at 6:32 AM, Jan Stolarek wrote: > Herbert, Austin, all, > > I have some questions and suggestions regarding our infrastructure: > > 1. Would it be possible to add a new custom field to Trac called "Wiki page"? Tickets that are > about implementing a larger feature have an accompanying wiki page that summarizes the design. It > would help my workflow if I could just get to that wiki page from the top of a Trac ticket. > > 2. I often want to get from the ticket view to index of all wiki pages. Sadly, ticket view only > has links to previous ticket/next ticket in the top right of the page. So to get to the index of > wiki pages I need to go to any of the wiki pages in the left panel and only then the link to wiki > index appears in the top right of the page. Would it be possible to have link to wiki index also > in the ticket view? > > 3. Is it possible to enable tooltips in Phabricator? I'm not yet all that familiar with the > interface and having icons that have no text and no tooltip is problematic. I need to actually > click on it to see what it does (or figure it out from the link target). > > 4. When browsing the code in diffusion I see that my name is not linked to my phabricator account, > for example here: > > https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/cmm/ > > Why is that happening? > > 5. I was thinking that perhaps harbormaster could also measure performance changes resulting from > a patch, eg. by running nofib. I'm not sure if that's easy to implement or not and whether we > have enough computing power to do that but I thought it's worth sharing that idea. > > Janek > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Mon Sep 15 13:28:45 2014 From: austin at well-typed.com (Austin Seipp) Date: Mon, 15 Sep 2014 08:28:45 -0500 Subject: GHC Weekly News (was: Status updates) Message-ID: Hi *, Note the title change. After some discussion with Simon last week, we decided to change up the name a bit, since we want the discussion on - As Gabor mentioned on the list earlier, I accidentally broke the Windows build. I'm sorry. :( We really need to get Phab building Windows too ASAP... I'm working on a fix this morning. (There are still a lot of upstream changes waiting to go into the Phabricator code base.) - I sent out the HCAR draft this morning. Please edit it! I think we have a few weeks of lead time however, so we're not in a rush like last time. But I will remind you. :) - The server migration for ghc.haskell.org seems to have gone pretty smoothly in the past week. It's had plenty of traffic so far. The full migration is still ongoing and I want to complete it this week. - I've finished reorganizing some of the Git and Repository pages after some discussion. We now have the Repositories[1] page, linked to on the left side, which details some notes on the repositories we use, and links to other various pages. I'm thinking of replacing this side-bar "root" with a link to the main Git[2] page, perhaps. - Miscellaneous: ghc.haskell.org and phabricator.haskell.org now sets the "Strict-Transport-Security" header. This just means you always use SSL now when you visit those pages (so you can't be connection-hijacked via a 503 redirect). - I'm merging some patches at the moment, although the windows fix is currently what I'll push first: D205, D204, D203, D199, D194, D179, D174. Do let me know if there's anything you want me to look at. - GHC works on Wine apparently for all you Linux users - thanks Mikolaj![3] - Jan had some questions about infrastructure which I just followed up on this morning. In particular: does anyone feel strongly about his first question?[4] - Herbert committed the first part of the Traversable/Foldable changes, by moving the typeclasses to Prelude. This is part of an ongoing series of patches. Things like adding Bifunctor will finally come after this.[5] Also, added bonus: we'll start including some of the tickets we closed this week. Closed tickets for the past week include: #9585, #9545, #9581, #6086, #9558, and #3658. Please let me know if you have any questions. [1] https://ghc.haskell.org/trac/ghc/wiki/Repositories [2] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git [3] https://www.haskell.org/pipermail/ghc-devs/2014-September/006283.html [4] https://www.haskell.org/pipermail/ghc-devs/2014-September/006275.html [5] https://phabricator.haskell.org/D209 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Mon Sep 15 13:41:49 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 15 Sep 2014 09:41:49 -0400 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: References: <201409101332.26593.jan.stolarek@p.lodz.pl> Message-ID: <36B75EB8-F2A8-47E8-B568-F6238DA87E20@cis.upenn.edu> On Sep 15, 2014, at 9:22 AM, Austin Seipp wrote: > > On Wed, Sep 10, 2014 at 6:32 AM, Jan Stolarek wrote: >> 1. Would it be possible to add a new custom field to Trac called "Wiki page"? Tickets that are >> about implementing a larger feature have an accompanying wiki page that summarizes the design. It >> would help my workflow if I could just get to that wiki page from the top of a Trac ticket. > > 1. I think this would be OK, but I'm rather neutral. Herbert is > concerned I think about the proliferation of fields for our tickets, > but I think this is reasonable. Would anyone else want this? It's easy > to add, at least. +1 from me From ekmett at gmail.com Mon Sep 15 13:44:01 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 15 Sep 2014 15:44:01 +0200 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: References: Message-ID: <8422F1D4-5F28-408E-9E9F-AFFFBB801B2F@gmail.com> I find PFunctor/QFunctor finer grained than is tasteful. Alas, they are necessary for inference for first/second in practice unless you require the Bifunctor to determine the category of both of its arguments. The hask package is exploring other ways to maintain inference. If you try to actually use the current categories package without them, well, nothing infers. Sent from my iPad > On Sep 15, 2014, at 11:32 AM, Sophie Taylor wrote: > > >Hi Sophie, > > >In your proposal draft, I am missing the rationale part. > Yeah, I'm still writing it - I definitely need to expand that a bit mor. > >Do we need *all* of these classes in base in order to desugar proc? Can > you demonstrate why they are needed? Or will something simpler suffice? > > I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. > With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Sep 15 13:54:07 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 15 Sep 2014 15:54:07 +0200 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: References: Message-ID: <58CF84FB-E7A8-4A72-A783-B5D75CC9374E@gmail.com> I'm currently working towards a new release of 'categories', which gets you closer to your goal here, if not yet integrated into base. Said release is currently blocked on GHC #9200, and in many ways the current work on hask is as well. I'd frankly consider that base isn't really in a good place to consider adopting either treatment at this point. Doing them right requires poly kinds, constraint kinds, etc. This steps pretty far outside of the scope of what we've been willing to bake into base to date, and it isn't clear how to do such a design tastefully. One option might be to define a number of combinators in an internal module in base with the SMC vocabulary and modify the arrow sugar to desugar in terms of those combinators rather than general use of arr, with RebindableSyntax turned on local definitions of the combinators would get selected, and then rules would have something to fire against. This would permit experimentation along these lines, without baking in assumptions about which of the points in the design space is best. Sent from my iPad > On Sep 15, 2014, at 11:32 AM, Sophie Taylor wrote: > > >Hi Sophie, > > >In your proposal draft, I am missing the rationale part. > Yeah, I'm still writing it - I definitely need to expand that a bit mor. > >Do we need *all* of these classes in base in order to desugar proc? Can > you demonstrate why they are needed? Or will something simpler suffice? > > I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. > With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Sep 15 14:07:47 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 15 Sep 2014 16:07:47 +0200 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: References: <201409101332.26593.jan.stolarek@p.lodz.pl> Message-ID: <1410790067.3023.3.camel@joachim-breitner.de> Hi, Am Montag, den 15.09.2014, 08:22 -0500 schrieb Austin Seipp: > 5. Long term, I think Phabricator has some goals to try and do this > with its Charting/Facts application, but there isn't really anything > today I'm afraid that would be easy. We could have Phabricator submit > information to Joachim's ghcspeed instance, but I'm not sure if it's > really designed to handle that kind of workflow. Maybe we should write > a custom tool after all, but right now I think this is going to take > some more thinking first. A Phab-integrated, better solution that what ghcspeed uses would be nice. Maybe a quick hack would be to link to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=004c5f4fec78414943d788c2a8b42a4500272949 from appropriate places. But it would only work for revisions that have reached master, and even then only after a little while. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ekmett at gmail.com Mon Sep 15 14:09:56 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 15 Sep 2014 16:09:56 +0200 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: References: <8422F1D4-5F28-408E-9E9F-AFFFBB801B2F@gmail.com> Message-ID: <49F98984-603D-4CE8-8DF1-DED96DD6C608@gmail.com> The current categories package tries to let you reuse bifunctors of the form c * d -> e across base categories, so that e.g. Kleisli m can use (,) for its product, etc. (in general it isn't a real product for Kleisli m, but let's pretend) this means we have to adopt a 3 for 2 policy wrt the categories involved. c e -> d, c d -> e, d e -> c, but when inferring from first or second you usually only know one, but also only need one other, but can't know the third from context, since no arrow is supplied. It is underdetermined. Hask avoids this by presupposing a single set of categories for every Bifunctor, but it is a conceit of the package that this is enough in practice, not something I know, and we pay a measurable price for this. A lot of stuff is more complex there! The current hask design, as opposed to the one I gave a talk on and the design of categories loses a lot of what powers lens and the like in exchange for this simpler story. I don't make that change lightly and I'd hesitate to make that change across the entire ecosystem. It hasn't proved it is worth the burden yet. In exchange for this complexity it is able to find simplicity elsewhere, e.g. Bifunctor in hask is a derived concept from a Functor to a Functor category, which models the curried nature of the arguments to a Bifunctor. My main point is there are a lot of points in the design space, and I don't think we're equipped to find a clear winner right now. Sent from my iPad > On Sep 15, 2014, at 3:53 PM, Sophie Taylor wrote: > > Oh darn, really? That is so disappointing. Why can't it maintain inference? :\ > >> On 15 September 2014 23:44, Edward Kmett wrote: >> I find PFunctor/QFunctor finer grained than is tasteful. Alas, they are necessary for inference for first/second in practice unless you require the Bifunctor to determine the category of both of its arguments. The hask package is exploring other ways to maintain inference. >> >> If you try to actually use the current categories package without them, well, nothing infers. >> >> Sent from my iPad >> >>> On Sep 15, 2014, at 11:32 AM, Sophie Taylor wrote: >>> >>> >Hi Sophie, >>> >>> >In your proposal draft, I am missing the rationale part. >>> Yeah, I'm still writing it - I definitely need to expand that a bit mor. >>> >Do we need *all* of these classes in base in order to desugar proc? Can >>> you demonstrate why they are needed? Or will something simpler suffice? >>> >>> I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. >>> With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Sep 15 15:29:05 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 15 Sep 2014 17:29:05 +0200 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: References: <201409101332.26593.jan.stolarek@p.lodz.pl> Message-ID: <201409151729.06031.jan.stolarek@p.lodz.pl> To Austin: > 2. I don't think we actually came to a conclusion on whether this is > doable. After some more thinking I believe that doing 1) will deal with about 90% of my uses cases for 2). However, we could add link to the wiki index in the sidebar - that certainly is doable. > 3. No, there aren't tooltips I'm afraid. I'm afraid navigating the UI > is a bit trial and error sometimes, but I'd like to know what problems > you had. I had no larger issues, more like wondering what are two icons in the top toolbar next to "Phabricator" logo. Or what is the difference between the icon with my avatar and the icon with tools (top toolbar on the left). Both icons suggest some sort of profile settings, but it's hard to figure out the difference between the two without actually clicking on them. Of course these problems will disappear over time. To Joachim: > Maybe a quick hack would be to link to > http://ghcspeed-nomeata.rhcloud.com/changes/?rev=004c5f4fec78414943d788c2a8b42a4500272949 > from appropriate places. But it would only work for revisions that have > reached master, and even then only after a little while. My intention is to have performance tests for patches under review. Since the whole idea of having Phab is to review and improve code before it makes into master it would make a lot of sense to see what performance impact the patches have *before* we merge them. A side note: I just noticed that "The GHC Team" link on GHC homepage points to non-existing wiki page (Contributors). GHC homepage says that it is maintained by Simon Marlow. Is this still true? Becuase I'm not sure where to complain about this :-) Janek From thomasmiedema at gmail.com Mon Sep 15 15:44:30 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 15 Sep 2014 17:44:30 +0200 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: <201409151729.06031.jan.stolarek@p.lodz.pl> References: <201409101332.26593.jan.stolarek@p.lodz.pl> <201409151729.06031.jan.stolarek@p.lodz.pl> Message-ID: > > I just noticed that "The GHC Team" link on GHC homepage points to > non-existing wiki page > (Contributors). > For whoever can fix this: please redirect [wiki:Contributors] to [wiki:TeamGHC], since there are other links to the old Contributors page around as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Sep 15 16:05:33 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 15 Sep 2014 12:05:33 -0400 Subject: cminusminus.org does not have a link to the spec In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140914191604.199a3f50@sf> <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: the historical c-- page still lives where norman moved it www.cs.tufts.edu/~nr/c--/index.html (and has all the content still) On Mon, Sep 15, 2014 at 8:05 AM, Simon Peyton Jones wrote: > Sergei > > C-- was originally envisaged as a target language for a variety of > compilers. But in fact LLVM, which was developed at a similar time, "won" > that race and has built a far larger ecosystem. That's fine with us -- > it's great how successful LLVM has been -- but it means that C-- is now > used essentially only in GHC. > > I'm not sure where the original C-- documents now are; Norman can you say? > (I do know that the cminusminus.org has lapsed.) > > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's > source code. It does have a concrete syntax, because some bits of GHC's > runtime system are written in Cmm. But I fear that this concrete language > is not well documented. (Simon Marlow may know more here.) > > Because GHC's Cmm is part of GHC, we are free to change it. Would you > like to say more about the change you want to make, and why you want to > make it? Is this relating directly to GHC or to some other project? > > Simon > > > | -----Original Message----- > | From: Sergei Trofimovich [mailto:slyich at gmail.com] > | Sent: 14 September 2014 17:16 > | To: Simon Peyton Jones > | Subject: cminusminus.org does not have a link to the spec > | > | Hello Simon! > | > | I had a plan to tweak a bit "import" statement > | syntax of Cmm in GHC. > | > | Namely, to distinct between > | import some_c_function; > | import some_c_global_variable; > | > | To try it I first attempted to find latest c-- spec > | (to find some design sketches if available) at > | > | http://www.cminusminus.org/c-downloads/ > | > | But seems the links (and images?) have gone away > | as well as rsync server described at: > | > | http://www.cminusminus.org/the-c-rsync-server/ > | > | Maybe you could forward it to site admins so they would > | tweak links or point me to working copy. > | > | Apologies for bothering you on such minor > | > | Thank you! > | > | -- > | > | Sergei > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 16:06:49 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 16:06:49 +0000 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: <58CF84FB-E7A8-4A72-A783-B5D75CC9374E@gmail.com> References: <58CF84FB-E7A8-4A72-A783-B5D75CC9374E@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22217B3E@DB3PRD3001MB020.064d.mgd.msft.net> #9200 is fixed in HEAD, which may unblock you? Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett Sent: 15 September 2014 14:54 To: Sophie Taylor Cc: ghc-devs at haskell.org Subject: Re: Preliminary proposal: Monoidal categories in base and proc notation support I'm currently working towards a new release of 'categories', which gets you closer to your goal here, if not yet integrated into base. Said release is currently blocked on GHC #9200, and in many ways the current work on hask is as well. I'd frankly consider that base isn't really in a good place to consider adopting either treatment at this point. Doing them right requires poly kinds, constraint kinds, etc. This steps pretty far outside of the scope of what we've been willing to bake into base to date, and it isn't clear how to do such a design tastefully. One option might be to define a number of combinators in an internal module in base with the SMC vocabulary and modify the arrow sugar to desugar in terms of those combinators rather than general use of arr, with RebindableSyntax turned on local definitions of the combinators would get selected, and then rules would have something to fire against. This would permit experimentation along these lines, without baking in assumptions about which of the points in the design space is best. Sent from my iPad On Sep 15, 2014, at 11:32 AM, Sophie Taylor > wrote: >Hi Sophie, >In your proposal draft, I am missing the rationale part. Yeah, I'm still writing it - I definitely need to expand that a bit mor. >Do we need *all* of these classes in base in order to desugar proc? Can you demonstrate why they are needed? Or will something simpler suffice? I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Sep 15 16:12:12 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 15 Sep 2014 12:12:12 -0400 Subject: Preliminary proposal: Monoidal categories in base and proc notation support In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22217B3E@DB3PRD3001MB020.064d.mgd.msft.net> References: <58CF84FB-E7A8-4A72-A783-B5D75CC9374E@gmail.com> <618BE556AADD624C9C918AA5D5911BEF22217B3E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <44B896A6-2822-43AF-B77F-2E81F1322DF1@gmail.com> The categories package itself has a number of current users who still use it on older versions of GHC, so it doesn't really unblock me there for the foreseeable future, but this will definitely help hask along. The hask package is already tied pretty close to the bleeding edge of GHC development, as compiling it with versions of GHC prior to 7.8.3 yields illegal .hi files. -Edward Sent from my iPad > On Sep 15, 2014, at 12:06 PM, Simon Peyton Jones wrote: > > #9200 is fixed in HEAD, which may unblock you? > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett > Sent: 15 September 2014 14:54 > To: Sophie Taylor > Cc: ghc-devs at haskell.org > Subject: Re: Preliminary proposal: Monoidal categories in base and proc notation support > > I'm currently working towards a new release of 'categories', which gets you closer to your goal here, if not yet integrated into base. Said release is currently blocked on GHC #9200, and in many ways the current work on hask is as well. I'd frankly consider that base isn't really in a good place to consider adopting either treatment at this point. Doing them right requires poly kinds, constraint kinds, etc. This steps pretty far outside of the scope of what we've been willing to bake into base to date, and it isn't clear how to do such a design tastefully. > > One option might be to define a number of combinators in an internal module in base with the SMC vocabulary and modify the arrow sugar to desugar in terms of those combinators rather than general use of arr, with RebindableSyntax turned on local definitions of the combinators would get selected, and then rules would have something to fire against. This would permit experimentation along these lines, without baking in assumptions about which of the points in the design space is best. > > Sent from my iPad > > On Sep 15, 2014, at 11:32 AM, Sophie Taylor wrote: > > >Hi Sophie, > > >In your proposal draft, I am missing the rationale part. > Yeah, I'm still writing it - I definitely need to expand that a bit mor. > >Do we need *all* of these classes in base in order to desugar proc? Can > you demonstrate why they are needed? Or will something simpler suffice? > > I think I might remove the binoidal class, and remove the PFunctor/QFunctor classes - I included them because I usually find finer grained class hierarchies to be more tasteful; but it probably would make it more frustrating to implement an arrow, for example. > With SMC classes, proc notation can be desugared to remove a LOT of calls to arr, which allows more fine-grained RULES optimisations to take place, and additional work such as the ModalTypes extension in Adam Megacz Joseph's thesis to be much more straightforward. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 16:12:03 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 16:12:03 +0000 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <32F83D1F-8FFD-48DF-8ED2-ADA9BA9FCDB5@lichtzwerge.de> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> <201409151113.35212.jan.stolarek@p.lodz.pl> <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF22215ACC@DB3PRD3001MB020.064d.mgd.msft.net> <32F83D1F-8FFD-48DF-8ED2-ADA9BA9FCDB5@lichtzwerge.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22217B5A@DB3PRD3001MB020.064d.mgd.msft.net> We don't yet have a firm policy, but my instinct is that. If they have a ticket, a milestone, a priority, they are less likely to get "lost". It's also easier for people to say on a ticket "is the design right?" than it is on Phab which is optimised for *code* review. Simon | -----Original Message----- | From: Moritz Angermann [mailto:moritz at lichtzwerge.de] | Sent: 15 September 2014 13:51 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe | | Dear Simon, | | No, there is not. Should every patch in Phab, have an associated ticket | as well? | | Cheers, | Moritz | | On Sep 15, 2014, at 2:17 PM, Simon Peyton Jones | wrote: | | > Is there a Trac ticket too? | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Moritz | > | Angermann | > | Sent: 15 September 2014 10:19 | > | To: ghc-devs at haskell.org | > | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to | globalRegMaybe | > | | > | Hi Janek, | > | | > | yea :) I think it went by unnoticed. Patch is already in Phab, | > | | > | https://phabricator.haskell.org/D208 | > | | > | Not sure how to speed up the review process, though ;-) | > | | > | Cheers, | > | Moritz | > | | > | On Sep 15, 2014, at 11:13 AM, Jan Stolarek | > | wrote: | > | | > | > I think it is best to fill in a bug report and attach a patch - I'm | > | afraid this mail may have gone | > | > unnoticed :-) | > | > | > | > Janek | > | > | > | > Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: | > | >> Hi, | > | >> | > | >> when trying to compile a ghc HEAD on LLVM ARM, I end up getting an | > | >> exception: | > | >> | > | >> ghc-stage1: panic! (the 'impossible' happened) | > | >> (GHC version 7.9.20140911 for arm-apple-ios): | > | >> globalRegMaybe | > | >> | > | >> After some digging I found that a new call to globalRegMaybe was | > | introduced | > | >> here: | > | >> | http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 | > | on | > | >> 2014-04-29 in commit: | > | >> | > | | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 | > | 34 | > | >> 12b9877 | > | >> | > | >> In a similar timeframe (since 2014-05-02) | /include/CodeGen.Platform.hs | > | was | > | >> changed: | > | >> | > | | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd | > | 6a | > | >> 8308e..HEAD:/includes/CodeGen.Platform.hs | > | >> | > | >> introducing a set of new ifdef/elif/endif pairs. Especially for | > | >> MACHREGS_NO_REGS, namely: | > | >> | > | >> -#endif | > | >> globalRegMaybe _ = Nothing | > | >> +#elif MACHREGS_NO_REGS | > | >> +globalRegMaybe _ = Nothing | > | >> +#else | > | >> +globalRegMaybe = panic "globalRegMaybe not defined for this | > | platform" | > | >> +#endif | > | >> | > | >> ARM.hs | > | >> | > | | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 | > | 69 | > | >> ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: | > | >> | > | >> #define MACHREGS_NO_REGS 0 | > | >> #define MACHREGS_arm 1 | > | >> | > | >> where MACHREGS_arm 1 has no effect on the subsequently imported | > | >> CodeGen.Platform.hs. | > | >> | > | >> Therefore I propose that a change to ARM.hs is made to set | > | >> MACHREGS_NO_REGS to 1. | > | >> | > | >> Cheers, | > | >> Moritz | > | >> _______________________________________________ | > | >> ghc-devs mailing list | > | >> ghc-devs at haskell.org | > | >> http://www.haskell.org/mailman/listinfo/ghc-devs | > | > | > | > | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs From moritz at lichtzwerge.de Mon Sep 15 16:28:04 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Mon, 15 Sep 2014 18:28:04 +0200 Subject: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22217B5A@DB3PRD3001MB020.064d.mgd.msft.net> References: <7BE3BE8C-9E4D-4EB6-8703-E1890195D3A9@lichtzwerge.de> <201409151113.35212.jan.stolarek@p.lodz.pl> <6C74D1A7-4C4C-4EF3-9FB3-89AC759BD672@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF22215ACC@DB3PRD3001MB020.064d.mgd.msft.net> <32F83D1F-8FFD-48DF-8ED2-ADA9BA9FCDB5@lichtzwerge.de> <618BE556AADD624C9C918AA5D5911BEF22217B5A@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <321C9D19-DDC4-47A4-8172-675EDF45BD42@lichtzwerge.de> Alright! Ticket is here, for everyone interested: https://ghc.haskell.org/trac/ghc/ticket/9593 Cheers, Moritz On Sep 15, 2014, at 6:12 PM, Simon Peyton Jones wrote: > We don't yet have a firm policy, but my instinct is that. If they have a ticket, a milestone, a priority, they are less likely to get "lost". It's also easier for people to say on a ticket "is the design right?" than it is on Phab which is optimised for *code* review. > > Simon > > | -----Original Message----- > | From: Moritz Angermann [mailto:moritz at lichtzwerge.de] > | Sent: 15 September 2014 13:51 > | To: Simon Peyton Jones > | Cc: ghc-devs at haskell.org > | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to globalRegMaybe > | > | Dear Simon, > | > | No, there is not. Should every patch in Phab, have an associated ticket > | as well? > | > | Cheers, > | Moritz > | > | On Sep 15, 2014, at 2:17 PM, Simon Peyton Jones > | wrote: > | > | > Is there a Trac ticket too? > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Moritz > | > | Angermann > | > | Sent: 15 September 2014 10:19 > | > | To: ghc-devs at haskell.org > | > | Subject: Re: Cannot build ghc HEAD with LLVM ARM due to > | globalRegMaybe > | > | > | > | Hi Janek, > | > | > | > | yea :) I think it went by unnoticed. Patch is already in Phab, > | > | > | > | https://phabricator.haskell.org/D208 > | > | > | > | Not sure how to speed up the review process, though ;-) > | > | > | > | Cheers, > | > | Moritz > | > | > | > | On Sep 15, 2014, at 11:13 AM, Jan Stolarek > | > | wrote: > | > | > | > | > I think it is best to fill in a bug report and attach a patch - I'm > | > | afraid this mail may have gone > | > | > unnoticed :-) > | > | > > | > | > Janek > | > | > > | > | > Dnia pi?tek, 12 wrze?nia 2014, Moritz Angermann napisa?: > | > | >> Hi, > | > | >> > | > | >> when trying to compile a ghc HEAD on LLVM ARM, I end up getting an > | > | >> exception: > | > | >> > | > | >> ghc-stage1: panic! (the 'impossible' happened) > | > | >> (GHC version 7.9.20140911 for arm-apple-ios): > | > | >> globalRegMaybe > | > | >> > | > | >> After some digging I found that a new call to globalRegMaybe was > | > | introduced > | > | >> here: > | > | >> > | http://git.haskell.org/ghc.git/blob/HEAD:/compiler/cmm/CmmSink.hs#l231 > | > | on > | > | >> 2014-04-29 in commit: > | > | >> > | > | > | http://git.haskell.org/ghc.git/commitdiff/83a003fcaec93dbfd5b46837f2bf335 > | > | 34 > | > | >> 12b9877 > | > | >> > | > | >> In a similar timeframe (since 2014-05-02) > | /include/CodeGen.Platform.hs > | > | was > | > | >> changed: > | > | >> > | > | > | http://git.haskell.org/ghc.git/blobdiff/b0534f78a73f972e279eed4447a5687bd > | > | 6a > | > | >> 8308e..HEAD:/includes/CodeGen.Platform.hs > | > | >> > | > | >> introducing a set of new ifdef/elif/endif pairs. Especially for > | > | >> MACHREGS_NO_REGS, namely: > | > | >> > | > | >> -#endif > | > | >> globalRegMaybe _ = Nothing > | > | >> +#elif MACHREGS_NO_REGS > | > | >> +globalRegMaybe _ = Nothing > | > | >> +#else > | > | >> +globalRegMaybe = panic "globalRegMaybe not defined for this > | > | platform" > | > | >> +#endif > | > | >> > | > | >> ARM.hs > | > | >> > | > | > | (http://git.haskell.org/ghc.git/blob/23892440032fcab8a6a753916d5068576741 > | > | 69 > | > | >> ec:/compiler/codeGen/CodeGen/Platform/ARM.hs) however, has: > | > | >> > | > | >> #define MACHREGS_NO_REGS 0 > | > | >> #define MACHREGS_arm 1 > | > | >> > | > | >> where MACHREGS_arm 1 has no effect on the subsequently imported > | > | >> CodeGen.Platform.hs. > | > | >> > | > | >> Therefore I propose that a change to ARM.hs is made to set > | > | >> MACHREGS_NO_REGS to 1. > | > | >> > | > | >> Cheers, > | > | >> Moritz > | > | >> _______________________________________________ > | > | >> ghc-devs mailing list > | > | >> ghc-devs at haskell.org > | > | >> http://www.haskell.org/mailman/listinfo/ghc-devs > | > | > > | > | > > | > | > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > ????????????????? Moritz Angermann +49 170 54 33 0 74 moritz at lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. M?nchen Amtsgericht M?nchen HRB 207882 Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From fryguybob at gmail.com Mon Sep 15 16:50:06 2014 From: fryguybob at gmail.com (Ryan Yates) Date: Mon, 15 Sep 2014 12:50:06 -0400 Subject: STM and GC write barrier Message-ID: Hi All, I'm starting to get to the bottom of something that has been puzzling me for a while. Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497 [1] introduced the GC write barrier for TVars. Not fully understanding things and reading the commit message to be saying that this was an optimization, I implemented my hardware transactional memory support without the write barrier (avoiding the extra work inside a transaction). This resulted in occasional crashes where a TVar which was point to a valid heap object when it was committed, pointed to garbage later. My understanding was that the TVar ended up in a later generation then the value that it came to point to and without getting added to the mut list, the value was collected. Adding the write barrier to all TVars written in my hardware transaction made the problem go away. While this all makes sense to me, what doesn't make as much sense is how STM prior to the commit above was not susceptible to the same problem. Is there some machinery to avoid this issue that I'm still missing? Ryan [1]: https://github.com/ghc/ghc/commit/6d784c43592290ec16db8b7f0f2a012dff3ed497 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Sep 15 19:28:56 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 15 Sep 2014 21:28:56 +0200 Subject: Random infrastructure requests, questions and suggestions In-Reply-To: References: <201409101332.26593.jan.stolarek@p.lodz.pl> <201409151729.06031.jan.stolarek@p.lodz.pl> Message-ID: <201409152128.56997.jan.stolarek@p.lodz.pl> > For whoever can fix this: please redirect [wiki:Contributors] to > [wiki:TeamGHC], since there are other links to the old Contributors page > around as well. Fixed. Janek From ndmitchell at gmail.com Mon Sep 15 20:13:23 2014 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon, 15 Sep 2014 21:13:23 +0100 Subject: Compiling on Windows Message-ID: Hi, At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I did so in the past about 5 years ago, and it was a painful experience. To help improve the path for those who come after me, I kept a log (which I'll share after I get a working build). My current state is that I get an error while running make while building stage2: "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o on the commandline: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadException (Draw m)) librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadReader Handles (Draw m)) libraries/haskeline/ghc.mk:4: recipe for target 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' failed make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 Any idea how to overcome that? I note from the weekly update email that there was an email on Windows last night, but a "./sync-all pull" doesn't make it go away. Thanks, Neil From ezyang at mit.edu Mon Sep 15 20:20:24 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 15 Sep 2014 16:20:24 -0400 Subject: Compiling on Windows In-Reply-To: References: Message-ID: <1410812395-sup-5591@sabre> Austin Seipp has taken responsibility for this failure (it's AMP related); he's working on a fix. Edward Excerpts from Neil Mitchell's message of 2014-09-15 16:13:23 -0400: > Hi, > > At ICFP Simon Peyton Jones encouraged me to compile GHC on Windows. I > did so in the past about 5 years ago, and it was a painful experience. > To help improve the path for those who come after me, I kept a log > (which I'll share after I get a working build). My current state is > that I get an error while running make while building stage2: > > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static > -H32m -O -this-package-key haske_9y30zKcKDr9BxdhpktYrNk > -hide-all-packages -i -ilibraries/haskeline/. > -ilibraries/haskeline/dist-install/build > -ilibraries/haskeline/dist-install/build/autogen > -Ilibraries/haskeline/dist-install/build > -Ilibraries/haskeline/dist-install/build/autogen > -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW > -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h > -package-key Win32_43THQMouBnk2wpnouztX1X -package-key > base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key > direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ > -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 > -XForeignFunctionInterface -XRank2Types -XFlexibleInstances > -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification > -XScopedTypeVariables -XGeneralizedNewtypeDeriving > -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances > -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db > -rtsopts -odir libraries/haskeline/dist-install/build -hidir > libraries/haskeline/dist-install/build -stubdir > libraries/haskeline/dist-install/build -split-objs -c > libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs > -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o > > on the commandline: Warning: > -XOverlappingInstances is deprecated: instead use per-instance > pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS > > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (Monad (Draw m)) > > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:21: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadIO (Draw m)) > > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:29: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadException (Draw m)) > > librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:45: > No instance for (Applicative (Draw m)) > arising from the 'deriving' clause of a data type declaration > Possible fix: > use a standalone 'deriving instance' declaration, > so you can specify the instance context yourself > When deriving the instance for (MonadReader Handles (Draw m)) > libraries/haskeline/ghc.mk:4: recipe for target > 'libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o' > failed > make[1]: *** [libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o] > Error 1 > Makefile:71: recipe for target 'all' failed > make: *** [all] Error 2 > > Any idea how to overcome that? I note from the weekly update email > that there was an email on Windows last night, but a "./sync-all pull" > doesn't make it go away. > > Thanks, Neil From gintautas.miliauskas at gmail.com Mon Sep 15 20:57:55 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Mon, 15 Sep 2014 22:57:55 +0200 Subject: Building ghc on Windows with msys2 Message-ID: Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Sep 15 21:27:31 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 15 Sep 2014 23:27:31 +0200 Subject: Shake based build system for GHC Message-ID: Hello SPJ (cc Neil Mitchell), on IRC it was brought up that there will be someone at GHC headquarters working on a Shake based build system. Can you tell us a little bit more about these plans. I wanted to try implementing this as well, but am happy to work on something else. Kind regards, Thomas Miedema -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Sep 15 21:33:10 2014 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 15 Sep 2014 18:33:10 -0300 Subject: in ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it Message-ID: In ghc 7.8.3 on the Mac, for some packages cabal reinstalls the package instead of telling me I've already installed it. ghc-pkg check shows I have no issues, e.g.: bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 Updating documentation index /Users/gcolpitts/Library/Haskell/share/doc/index.html bash-3.2$ ghc-pkg check bash-3.2$ Other packages that have this problem include alex, and an example of a package that doesn't have this problem is vector. Should I file a bug? bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3") ,("Global Package DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d") ] bash-3.2$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d: Cabal-1.18.1.4 GLURaw-1.4.0.1 GLUT-2.5.1.1 HTTP-4000.2.10 HUnit-1.2.5.2 OpenGL-2.9.2.0 OpenGLRaw-1.5.0.0 QuickCheck-2.6 array-0.5.0.0 async-2.0.1.5 attoparsec-0.10.4.0 base-4.7.0.1 bin-package-db-0.0.0.0 binary-0.7.1.0 rts-1.0 bytestring-0.10.4.0 case-insensitive-1.1.0.3 containers-0.5.5.1 deepseq-1.3.0.2 directory-1.2.1.0 fgl-5.5.0.1 filepath-1.3.0.2 (ghc-7.8.3) ghc-prim-0.3.1.0 hashable-1.2.2.0 haskeline-0.7.1.2 haskell-src-1.0.1.6 (haskell2010-1.1.2.0) (haskell98-2.0.0.3) hoopl-3.10.0.1 hpc-0.6.0.1 hscolour-1.20.3 html-1.0.1.2 integer-gmp-0.5.1.0 mtl-2.1.3.1 network-2.4.2.3 old-locale-1.0.0.6 old-time-1.1.0.2 parallel-3.2.0.4 parsec-3.1.5 pretty-1.1.1.1 primitive-0.5.2.1 process-1.2.0.0 random-1.0.1.1 regex-base-0.93.2 regex-compat-0.95.1 regex-posix-0.95.2 split-0.2.2 stm-2.4.2 syb-0.4.1 template-haskell-2.9.0.0 terminfo-0.4.0.0 text-1.1.0.0 time-1.4.2 transformers-0.3.0.0 unix-2.7.0.1 unordered-containers-0.2.4.0 vector-0.10.9.1 xhtml-3000.2.1 zlib-0.5.4.1 /Users/gcolpitts/.ghc/x86_64-darwin-7.8.3/package.conf.d: Cabal-1.20.0.2 MonadRandom-0.3 aeson-0.6.2.1 auto-update-0.1.1.2 bifunctors-4.1.1.1 blaze-builder-0.3.3.3 cmdargs-0.10.9 comonad-4.2.2 conduit-1.2.0.2 contravariant-1.2 cpphs-1.18.5 data-ordlist-0.4.6.1 distributive-0.4.4 djinn-ghc-0.0.2.2 djinn-lib-0.0.1.2 dlist-0.7.1 either-4.3.1 exceptions-0.6.1 free-4.9 ghc-mod-5.0.1.2 ghc-paths-0.1.0.9 ghc-syb-utils-0.2.2 haskell-src-exts-1.15.0.1 hasktags-0.69.0 hlint-1.9.4 hoogle-4.2.34 http-date-0.0.4 http-types-0.8.5 io-choice-0.0.5 json-0.7 lifted-base-0.2.3.0 mmorph-1.0.4 monad-control-0.3.3.0 monad-journal-0.2.3.2 mwc-random-0.13.2.0 nats-0.2 polyparse-1.9 prelude-extras-0.4 profunctors-4.2.0.1 resourcet-1.1.2.3 safe-0.3.8 scientific-0.3.3.1 semigroupoids-4.2 semigroups-0.15.3 shake-0.13.2 simple-sendfile-0.2.17 streaming-commons-0.1.4.2 strict-0.3.2 stylish-haskell-0.5.10.2 tagged-0.7.2 tagsoup-0.13.2 text-1.2.0.0 transformers-base-0.4.3 transformers-compat-0.3.3.4 uniplate-1.6.12 unix-compat-0.4.1.3 unordered-containers-0.2.5.0 utf8-string-0.3.8 vault-0.3.0.3 vector-0.10.11.0 vector-algorithms-0.6.0.3 void-0.6.1 wai-3.0.1.1 warp-3.0.1.1 yaml-0.8.9.1 bash-3.2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 21:33:20 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 21:33:20 +0000 Subject: Building ghc on Windows with msys2 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> Thank you! Indeed Neil Mitchell is also acting as ?guinea pig? at the moment. It would be *great* if together you were able to clean up the ?how to build on Windows? page, remove out of date or misleading information, and yes I think we should focus on msys2. Great stuff Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gintautas Miliauskas Sent: 15 September 2014 21:58 To: ghc-devs at haskell.org Subject: Building ghc on Windows with msys2 Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 15 21:39:46 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 15 Sep 2014 21:39:46 +0000 Subject: Shake based build system for GHC In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF22217F1B@DB3PRD3001MB020.064d.mgd.msft.net> on IRC it was brought up that there will be someone at GHC headquarters working on a Shake based build system. Can you tell us a little bit more about these plans. Andrey Mokhov, from the University of Newcastle, will be visiting MSR during his sabbatical, starting around 1 Oct. I?ve suggested to him that working on a Shake-based build system for GHC would be a good project: useful to us, and interesting to him. Neil is happy to act as adviser, as is Simon Marlow who wrote the current build system. I?m sure Andrey would be very happy to work with others on this, if you have time and expertise to contribute. Would you be interested? GHC?s build system is pretty complicated and does a lot, so it won?t be a straightforward matter of cranking the handle! Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Thomas Miedema Sent: 15 September 2014 22:28 To: ghc-devs at haskell.org Subject: Shake based build system for GHC Hello SPJ (cc Neil Mitchell), on IRC it was brought up that there will be someone at GHC headquarters working on a Shake based build system. Can you tell us a little bit more about these plans. I wanted to try implementing this as well, but am happy to work on something else. Kind regards, Thomas Miedema -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Sep 15 21:58:54 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 15 Sep 2014 23:58:54 +0200 Subject: Shake based build system for GHC In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22217F1B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF22217F1B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hello Simon, > Andrey Mokhov , > from the University of Newcastle, will be visiting MSR during his > sabbatical, starting around 1 Oct. I?ve suggested to him that working on a > Shake-based build system for GHC would be a good project: useful to us, and > interesting to him. Neil is happy to act as adviser, as is Simon Marlow > who wrote the current build system. > > Great. > I?m sure Andrey would be very happy to work with others on this, if you > have time and expertise to contribute. Would you be interested? > I have plenty of time, and no expertise, so that is a yes :) Kind regards, Thomas Miedema -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Sep 16 02:03:27 2014 From: david.feuer at gmail.com (David Feuer) Date: Mon, 15 Sep 2014 22:03:27 -0400 Subject: Cleaning up rather silly static arguments Message-ID: Aside from anything having to do with the foldrW/buildW stuff, I decided to try a little experiment using fusing scanl and reverse (implementations at http://lpaste.net/2416758997739634688 ) When I define scanr f b = reverse . scanl (flip f) b . reverse I get this: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> letrec { go_amb go_amb = \ ds_amc eta1_Xa eta2_B2 eta3_Xc -> case ds_amc of _ { [] -> eta1_Xa eta2_B2 eta3_Xc; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) eta2_B2 eta3_Xc }; } in go_amb eta_B1 (scanr1) b_ah9 (: b_ah9 ([])) go_amb takes four arguments, two of which, eta2_B2 and eta3_Xc, are static. What makes this seem particularly silly is that we already have all the structure we need to get rid of them?all that remains is to actually delete them and replace them with the values they take: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> let { listend listend = : b_ah9 ([])} in letrec { go_amb go_amb = \ ds_amc eta1_Xa -> case ds_amc of _ { [] -> eta1_Xa b_ah9 listend; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) }; } in go_amb eta_B1 (scanr1) Now I certainly wouldn't claim this is particularly *good* code, but it seems significantly more reasonable than before. If I were to try to find a way to get rid of these things, should I try hacking on the static argument transformation, or would it fit better in the simplifier, or somewhere else? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndmitchell at gmail.com Tue Sep 16 12:54:12 2014 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 16 Sep 2014 13:54:12 +0100 Subject: Building on Windows Message-ID: Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google "build ghc on windows", which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows "The instructions are current for GHC 7.6" - so they are not current. "Other documentation for Windows includes:" - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said "MSYS2" works well, so I clicked that one. Even though it appears to be the "wrong" one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. "It should get you running in ~5 minutes, modulo download speeds." - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. "Do not install python, python2 or gcc!" - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better "check" step, e.g. run "gcc --version", "ghc --version" and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts [######################] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the && commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x250000) != child(0x7C0000) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran "autorebase.bat" from msys32, and restarted my shell, then it worked - I have no idea which fixed it. "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/. -ilibraries/haskeline/dist-install/build -ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/dist-install/build -Ilibraries/haskeline/dist-install/build/autogen -Ilibraries/haskeline/includes -optP-DUSE_GHC_ENCODINGS -optP-DMINGW -optP-include -optPlibraries/haskeline/dist-install/build/autogen/cabal_macros.h -package-key Win32_43THQMouBnk2wpnouztX1X -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv -package-key conta_ChF4XLXB9JmByIycPzerow -package-key direc_6qC0tVrFkqbBNeWAGS0s7g -package-key filep_34DFDFT9FVD9pRLLgh8IdQ -package-key trans_5jw4w9yTgmZ89ByuixDAKP -Wall -XHaskell98 -XForeignFunctionInterface -XRank2Types -XFlexibleInstances -XTypeSynonymInstances -XFlexibleContexts -XExistentialQuantification -XScopedTypeVariables -XGeneralizedNewtypeDeriving -XMultiParamTypeClasses -XOverlappingInstances -XUndecidableInstances -XCPP -XDeriveDataTypeable -XPatternGuards -O2 -no-user-package-db -rtsopts -odir libraries/haskeline/dist-install/build -hidir libraries/haskeline/dist-install/build -stubdir libraries/haskeline/dist-install/build -split-objs -c libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.hs -o libraries/haskeline/dist-install/build/System/Console/Haskeline/Backend/Win32.o librarieshaskelineSystemConsoleHaskelineBackendWin32.hsc:263:15: No instance for (Applicative (Draw m)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Monad (Draw m)) I fixed that by applying the patch from https://ghc.haskell.org/trac/ghc/ticket/9598. With that, I could build to completion. An empty build (nothing to do) takes 1m50s which is a bit sad, but it does work. After all this there are exactly two things I want to know (both of which would be useful links from the bottom of the building on Windows page): * How do I update to the next day, resync and rebuild. In particular, should i sync-all or not (a link to another page is fine) * How do I run the tests. From simonpj at microsoft.com Tue Sep 16 13:11:28 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Sep 2014 13:11:28 +0000 Subject: Cleaning up rather silly static arguments In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF2221ACD6@DB3PRD3001MB020.064d.mgd.msft.net> If I were to try to find a way to get rid of these things, should I try hacking on the static argument transformation, or would it fit better in the simplifier, or somewhere else? Yes, this is just what the static argument transformation is for. I?ve added your example to https://ghc.haskell.org/trac/ghc/ticket/9374 Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David Feuer Sent: 16 September 2014 03:03 To: ghc-devs Subject: Cleaning up rather silly static arguments Aside from anything having to do with the foldrW/buildW stuff, I decided to try a little experiment using fusing scanl and reverse (implementations at http://lpaste.net/2416758997739634688 ) When I define scanr f b = reverse . scanl (flip f) b . reverse I get this: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> letrec { go_amb go_amb = \ ds_amc eta1_Xa eta2_B2 eta3_Xc -> case ds_amc of _ { [] -> eta1_Xa eta2_B2 eta3_Xc; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) eta2_B2 eta3_Xc }; } in go_amb eta_B1 (scanr1) b_ah9 (: b_ah9 ([])) go_amb takes four arguments, two of which, eta2_B2 and eta3_Xc, are static. What makes this seem particularly silly is that we already have all the structure we need to get rid of them?all that remains is to actually delete them and replace them with the values they take: scanr1 scanr1 = \ @ a_akP _ eta_Xb -> eta_Xb scanr scanr = \ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -> let { listend listend = : b_ah9 ([])} in letrec { go_amb go_amb = \ ds_amc eta1_Xa -> case ds_amc of _ { [] -> eta1_Xa b_ah9 listend; : y_amh ys_ami -> go_amb ys_ami (\ x_an9 eta4_Xj -> let { b'_ana b'_ana = f_ah8 y_amh x_an9 } in eta1_Xa b'_ana (: b'_ana eta4_Xj)) }; } in go_amb eta_B1 (scanr1) Now I certainly wouldn't claim this is particularly *good* code, but it seems significantly more reasonable than before. If I were to try to find a way to get rid of these things, should I try hacking on the static argument transformation, or would it fit better in the simplifier, or somewhere else? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From slyich at gmail.com Tue Sep 16 18:03:18 2014 From: slyich at gmail.com (Sergei Trofimovich) Date: Tue, 16 Sep 2014 21:03:18 +0300 Subject: cminusminus.org does not have a link to the spec In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140914191604.199a3f50@sf> <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140916210318.5d7b5fff@sf> On Mon, 15 Sep 2014 12:05:27 +0000 Simon Peyton Jones wrote: My planned change is for GHC's .cmm files syntax/codegen. The idea came out after having stumbled upon a rare ia64 bug in GHC's C codegen: http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc074cac721 The fundamental bug here is the following: Suppose we have two bits of rts: one .c file and one .cmm file // rts.c defines and exports a function and a variable void some_rts_fun (void); int some_rts_var; // rts.cmm uses rts.c's function and variable import some_rts_fun; /* this forces C codegen to emit function-like 'StgFunPtr some_rts_fun ();' prototype, it's fine */ import some_rts_var; /* also forces C codegen to emit function-like 'StgFunPtr some_rts_var ();' prototype, it's broken */ // ... W whatever = &some_rts_var; /* will pick address not to a real variable, but to a so called function stub, a separate structure pointing to real 'some_rts_var' */ I plan to tweak syntax to teach Cmm to distinct between imported C global variables/constants, imported Cmm info tables(closures), maybe other cases. I thought of adding haskell-like syntax for imports: foreign ccall import some_rts_fun; foreign cdata import some_rts_var; or maybe import some_rts_fun; import "&some_rts_fun" as some_rts_fun; This sort of bugs can be easily spotted by whole-program C compiler. gcc can do it with -flto option. I basically added to the mk/build.mk: SRC_CC_OPTS += -flto SRC_LD_OPTS += -flto -fuse-linker-plugin SRC_HC_OPTS += -optc-flto SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin and started with './configure --enable-unregisterised' It immediately shown some of current offenders: error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as function error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as function I hope this fuzzy explanation makes some sense. Thanks! > Sergei > > C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. > > I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) > > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) > > Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? > > Simon > > > | -----Original Message----- > | From: Sergei Trofimovich [mailto:slyich at gmail.com] > | Sent: 14 September 2014 17:16 > | To: Simon Peyton Jones > | Subject: cminusminus.org does not have a link to the spec > | > | Hello Simon! > | > | I had a plan to tweak a bit "import" statement > | syntax of Cmm in GHC. > | > | Namely, to distinct between > | import some_c_function; > | import some_c_global_variable; > | > | To try it I first attempted to find latest c-- spec > | (to find some design sketches if available) at > | > | http://www.cminusminus.org/c-downloads/ > | > | But seems the links (and images?) have gone away > | as well as rsync server described at: > | > | http://www.cminusminus.org/the-c-rsync-server/ > | > | Maybe you could forward it to site admins so they would > | tweak links or point me to working copy. > | > | Apologies for bothering you on such minor > | > | Thank you! > | > | -- > | > | Sergei -- Sergei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From simonpj at microsoft.com Tue Sep 16 20:23:10 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 16 Sep 2014 20:23:10 +0000 Subject: cminusminus.org does not have a link to the spec In-Reply-To: <20140916210318.5d7b5fff@sf> References: <20140914191604.199a3f50@sf> <618BE556AADD624C9C918AA5D5911BEF222159D1@DB3PRD3001MB020.064d.mgd.msft.net> <20140916210318.5d7b5fff@sf> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2221CE98@DB3PRD3001MB020.064d.mgd.msft.net> Thanks. This is beyond my competence, and I'm totally submerged anyway. I suggest you make a Trac ticket about it anyway. Simon Marlow will probably have an opinion. Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich at gmail.com] | Sent: 16 September 2014 19:03 | To: Simon Peyton Jones | Cc: Norman Ramsey; ghc-devs; Simon Marlow | Subject: Re: cminusminus.org does not have a link to the spec | | On Mon, 15 Sep 2014 12:05:27 +0000 | Simon Peyton Jones wrote: | | My planned change is for GHC's .cmm files syntax/codegen. | The idea came out after having stumbled upon a rare ia64 | bug in GHC's C codegen: | | | http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc | 074cac721 | | The fundamental bug here is the following: | Suppose we have two bits of rts: one .c file and one .cmm file | | // rts.c defines and exports a function and a variable | void some_rts_fun (void); | int some_rts_var; | | // rts.cmm uses rts.c's function and variable | import some_rts_fun; /* this forces C codegen to emit function-like | 'StgFunPtr some_rts_fun ();' | prototype, it's fine */ | | import some_rts_var; /* also forces C codegen to emit function-like | 'StgFunPtr some_rts_var ();' | prototype, it's broken */ | // ... | W whatever = &some_rts_var; /* will pick address not to a real | variable, but to a | so called | function stub, a separate structure | pointing to real | 'some_rts_var' */ | | I plan to tweak syntax to teach Cmm to distinct between | imported C global variables/constants, imported Cmm info | tables(closures), maybe other cases. | | I thought of adding haskell-like syntax for imports: | foreign ccall import some_rts_fun; | foreign cdata import some_rts_var; | | or maybe | import some_rts_fun; | import "&some_rts_fun" as some_rts_fun; | | This sort of bugs can be easily spotted by whole-program C compiler. | gcc can do it with -flto option. I basically added to the mk/build.mk: | SRC_CC_OPTS += -flto | SRC_LD_OPTS += -flto -fuse-linker-plugin | SRC_HC_OPTS += -optc-flto | SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin | and started with './configure --enable-unregisterised' | | It immediately shown some of current offenders: | error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as | function | error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as | function | | I hope this fuzzy explanation makes some sense. | | Thanks! | | > Sergei | > | > C-- was originally envisaged as a target language for a variety of | compilers. But in fact LLVM, which was developed at a similar time, | "won" that race and has built a far larger ecosystem. That's fine with | us -- it's great how successful LLVM has been -- but it means that C-- is | now used essentially only in GHC. | > | > I'm not sure where the original C-- documents now are; Norman can you | say? (I do know that the cminusminus.org has lapsed.) | > | > The GHC variant of C-- is defined mainly by the Cmm data type in GHC's | source code. It does have a concrete syntax, because some bits of GHC's | runtime system are written in Cmm. But I fear that this concrete language | is not well documented. (Simon Marlow may know more here.) | > | > Because GHC's Cmm is part of GHC, we are free to change it. Would you | like to say more about the change you want to make, and why you want to | make it? Is this relating directly to GHC or to some other project? | > | > Simon | > | > | > | -----Original Message----- | > | From: Sergei Trofimovich [mailto:slyich at gmail.com] | > | Sent: 14 September 2014 17:16 | > | To: Simon Peyton Jones | > | Subject: cminusminus.org does not have a link to the spec | > | | > | Hello Simon! | > | | > | I had a plan to tweak a bit "import" statement | > | syntax of Cmm in GHC. | > | | > | Namely, to distinct between | > | import some_c_function; | > | import some_c_global_variable; | > | | > | To try it I first attempted to find latest c-- spec | > | (to find some design sketches if available) at | > | | > | http://www.cminusminus.org/c-downloads/ | > | | > | But seems the links (and images?) have gone away | > | as well as rsync server described at: | > | | > | http://www.cminusminus.org/the-c-rsync-server/ | > | | > | Maybe you could forward it to site admins so they would | > | tweak links or point me to working copy. | > | | > | Apologies for bothering you on such minor | > | | > | Thank you! | > | | > | -- | > | | > | Sergei | | | -- | | Sergei From mail at joachim-breitner.de Wed Sep 17 18:56:43 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 17 Sep 2014 20:56:43 +0200 Subject: Remove special casing of singleton strings, split all strings, Re: Implement `decodeDouble_Int64#` primop In-Reply-To: <20140916125934.B614B3A35B@ghc.haskell.org> References: <20140916125934.B614B3A35B@ghc.haskell.org> Message-ID: <1410980203.14197.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 16.09.2014, 12:59 +0000 schrieb git at git.haskell.org: > commit fe9f7e40844802443315ef2238c4cdefda756b62 > Author: Thijs Alkemade > Date: Tue Sep 16 07:55:34 2014 -0500 > > Remove special casing of singleton strings, split all strings. > > Summary: > exprIsConApp_maybe now detects string literals and correctly > splits them. This means case-statemnts on string literals can > now push the literal into the cases. if you are curious: This improves the runtime of the binary-trees nofib benchmark by 6% and reduces the size of the parstof nofib benchmark by 4.6%, although on average, binary sizes are increased by a very small amount (0.12%). There is a notable increase in allocations in bspt, cacheprof and gg (>3%). Details: http://ghcspeed-nomeata.rhcloud.com/changes/?rev=fe9f7e4084&exe=2&env=1 Am Mittwoch, den 17.09.2014, 15:58 +0000 schrieb git at git.haskell.org: > commit b62bd5ecf3be421778e4835010b6b334e95c5a56 > Author: Herbert Valerio Riedel > Date: Wed Sep 17 17:54:20 2014 +0200 > > Implement `decodeDouble_Int64#` primop > > The existing `decodeDouble_2Int#` primop is rather inconvenient to use > (and in fact is not even used by `integer-gmp`) as the mantissa is split > into 3 components which would actually fit in an `Int64#` value. > > However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2` > re-implementation (see #9281). > > Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the > IEEE representation which can be replaced by a combination of the > portable standard C99 `scalbn(3)` and `frexp(3)` functions. This commit undoes the improvement of binary-trees?s runtime (4.6% regression), but no other notable changes. Again, I leave it to the respective commiters to decide if any of this is worth investigating. See http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Ftime%2Fbinary-trees&env=1&revs=50&equid=on# for the history of that particular benchmark. Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From abela at chalmers.se Wed Sep 17 21:58:17 2014 From: abela at chalmers.se (Andreas Abel) Date: Wed, 17 Sep 2014 23:58:17 +0200 Subject: Equality check for types that respects type families? (#9582) Message-ID: <541A03F9.4060501@chalmers.se> Looking at bug #9582 Associated Type Synonyms do not unfold in InstanceSigs https://ghc.haskell.org/trac/ghc/ticket/9582 I found that the given type in an instance signature is compared to the expected type using Type.eqType, which does not seem to know about type families. https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs -- Check that any type signatures have exactly the right type check_inst_sig hs_ty@(L loc _) = setSrcSpan loc $ do { sig_ty <- tcHsSigType (FunSigCtxt sel_name) hs_ty ; inst_sigs <- xoptM Opt_InstanceSigs ; if inst_sigs then unless (sig_ty `eqType` local_meth_ty) (badInstSigErr sel_name local_meth_ty) ... https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs eqType :: Type -> Type -> Bool -- ^ Type equality on source types. Does not look through @newtypes@ or -- 'PredType's, but it does look through type synonyms. -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] Question: Is there a (monadic) function for checking type equality which knows about the current type family rules in scope and honors them? Maybe the better question is where to find it, since there should be such a beast (used in the type checker somewhere to compare expected with inferred types). Cheers, Andreas (new to the GHC source code) -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From abela at chalmers.se Thu Sep 18 08:17:15 2014 From: abela at chalmers.se (Andreas Abel) Date: Thu, 18 Sep 2014 10:17:15 +0200 Subject: Equality check for types that respects type families? (#9582) In-Reply-To: <541A03F9.4060501@chalmers.se> References: <541A03F9.4060501@chalmers.se> Message-ID: <541A950B.6080403@chalmers.se> Thanks, Simon, for the quick answer (see ticket #9582). --Andreas On 17.09.2014 23:58, Andreas Abel wrote: > Looking at bug #9582 > > Associated Type Synonyms do not unfold in InstanceSigs > https://ghc.haskell.org/trac/ghc/ticket/9582 > > I found that the given type in an instance signature is compared to the > expected type using Type.eqType, which does not seem to know about type > families. > > https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs > > -- Check that any type signatures have exactly the right type > check_inst_sig hs_ty@(L loc _) > = setSrcSpan loc $ > do { sig_ty <- tcHsSigType (FunSigCtxt sel_name) hs_ty > ; inst_sigs <- xoptM Opt_InstanceSigs > ; if inst_sigs then > unless (sig_ty `eqType` local_meth_ty) > (badInstSigErr sel_name local_meth_ty) > ... > > https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs > > eqType :: Type -> Type -> Bool > -- ^ Type equality on source types. Does not look through @newtypes@ or > -- 'PredType's, but it does look through type synonyms. > -- Watch out for horrible hack: See Note [Comparison with OpenTypeKind] > > Question: Is there a (monadic) function for checking type equality > which knows about the current type family rules in scope and honors them? > Maybe the better question is where to find it, since there should be > such a beast (used in the type checker somewhere to compare expected > with inferred types). > > Cheers, > Andreas (new to the GHC source code) > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From simonpj at microsoft.com Thu Sep 18 08:38:19 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Sep 2014 08:38:19 +0000 Subject: D202: Injective type families In-Reply-To: <20140918083449.40068.65572@phabricator.haskell.org> References: <20140918083449.40068.65572@phabricator.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2221FA32@DB3PRD3001MB020.064d.mgd.msft.net> Dear GHC devs I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? If Phabs were branches in the GHC repo I could say Git checkout phab/D202 That would be cool. I know how to do that. But I don't think they are. So what do I do? Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 18 September 2014 09:35 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | I made two important adjustments: | | - first of all I removed the `result` from the parser and lexer. | Instead of `result` I'm planning to use type variable introduced by | the user for the result (as described in [[ | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 | | Proposal 7 ]] on the wiki. | | - following Richard's suggestion I changed `InjectivityInfo` to | contain `[Located name]` instead of `[LHsType name]`. But I keep | getting "Not in scope" errors. When I try to compile: | ``` | type family F a :: r | r -> a where | F a = a | ``` | I get errors that `r` and `a` are not in scope. According to my | tracing line 1149 of RnSource.lhs is responsible for this. I looked at | other code in this module and it seems to me that `bindHsTyVars` | should bring these variables into scope when renaming `r -> a`. I have | no idea why this does not happen. Simon, help? | | Also, build error reported by Harbormaster is nonsense. | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, simonpj, austin | Cc: goldfire, simonmar, ezyang, carter From afarmer at ittc.ku.edu Thu Sep 18 08:48:24 2014 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Thu, 18 Sep 2014 09:48:24 +0100 Subject: D202: Injective type families In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2221FA32@DB3PRD3001MB020.064d.mgd.msft.net> References: <20140918083449.40068.65572@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF2221FA32@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I believe you do this with: arc patch D123456 The arcanist docs are handy: https://secure.phabricator.com/book/phabricator/article/arcanist/ On Thu, Sep 18, 2014 at 9:38 AM, Simon Peyton Jones wrote: > Dear GHC devs > > I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? > > If Phabs were branches in the GHC repo I could say > Git checkout phab/D202 > > That would be cool. I know how to do that. > > But I don't think they are. So what do I do? > > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 18 September 2014 09:35 > | To: Simon Peyton Jones > | Subject: [Differential] [Commented On] D202: Injective type families > | > | jstolarek added a comment. > | > | I made two important adjustments: > | > | - first of all I removed the `result` from the parser and lexer. > | Instead of `result` I'm planning to use type variable introduced by > | the user for the result (as described in [[ > | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 > | | Proposal 7 ]] on the wiki. > | > | - following Richard's suggestion I changed `InjectivityInfo` to > | contain `[Located name]` instead of `[LHsType name]`. But I keep > | getting "Not in scope" errors. When I try to compile: > | ``` > | type family F a :: r | r -> a where > | F a = a > | ``` > | I get errors that `r` and `a` are not in scope. According to my > | tracing line 1149 of RnSource.lhs is responsible for this. I looked at > | other code in this module and it seems to me that `bindHsTyVars` > | should bring these variables into scope when renaming `r -> a`. I have > | no idea why this does not happen. Simon, help? > | > | Also, build error reported by Harbormaster is nonsense. > | > | REPOSITORY > | rGHC Glasgow Haskell Compiler > | > | REVISION DETAIL > | https://phabricator.haskell.org/D202 > | > | REPLY HANDLER ACTIONS > | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, > | !unsubscribe. > | > | To: jstolarek, simonpj, austin > | Cc: goldfire, simonmar, ezyang, carter > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > From ezyang at mit.edu Thu Sep 18 21:30:02 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 18 Sep 2014 14:30:02 -0700 Subject: Should we occasionally merge haddock master into ghc-head? Message-ID: <1411075572-sup-5025@sabre> Hello Mateusz and all, With ghc-head and master being developed concurrently, I am wondering if GHC developers should be allowed to occasionally merge in changes from master. Seems like a good service which would help Mateusz out a bit when it comes time to update master for the next version GHC. Or is there some reason we shouldn't do this? Cheers, Edward From fuuzetsu at fuuzetsu.co.uk Fri Sep 19 04:21:59 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 19 Sep 2014 05:21:59 +0100 Subject: Should we occasionally merge haddock master into ghc-head? In-Reply-To: <1411075572-sup-5025@sabre> References: <1411075572-sup-5025@sabre> Message-ID: <541BAF67.4050803@fuuzetsu.co.uk> On 09/18/2014 10:30 PM, Edward Z. Yang wrote: > Hello Mateusz and all, > > With ghc-head and master being developed concurrently, I am wondering if > GHC developers should be allowed to occasionally merge in changes from > master. Seems like a good service which would help Mateusz out a bit > when it comes time to update master for the next version GHC. Or is > there some reason we shouldn't do this? > > Cheers, > Edward > Hi, tl;dr: Far too much effort on the GHC side for very little gain on Haddock side makes the master/ghc-head split lose part of its function. Longer version: As I mentioned on IRC, my plan at GHC release time is not to just merge from ghc-head. Changes by GHC team tend to be small, fixes due to API changes. Ideally what would happen is that I sit down near release date and cherry-pick it all out, maybe even squashing it first into a ?update for next GHC? commit as that makes looking at the actual diff between branches much easier ? we do not care what changed between day 1 of 7.9 until last day of 7.9, we only care about what changed between 7.8.3 and 7.10.x-justbeforerc1. One of the large reasons why I wanted to move out Haddock from GHC tree is that we (Haddock) do not have to go through these API changes at all, we're only there for the final release. I think this makes cherry-picking more suited to merging ghc-head ? master. But your question is master ? ghc-head. I think it is not necessary for you to do so. We have already taken steps for compatibility with 7.8.2 and even split Haddock up further into more packages. This means that not only would this merge be very unpleasant to do, it'd also be unpleasant to maintain thereafter. As I don't plan merging ghc-head back in, it does not greatly reduce labour for me when it comes to it but it makes it painful for GHC folk. The only reason you might have to merge master ? ghc-head would therefore be if GHC needed features from master at which point cherry-picking those features is easier than merging the whole thing. I think it makes sense to think of it as Haddock now being disjoint software that GHC happens to use, needs to patch sometimes, and simply contributes those (finalised) patches to Haddock at GHC release time. Once these merges are done, you can restart ghc-head for 7.11 from master at that point, rather than trying to go through merges and try to keep in sync throughout the process. Basically ?master? is the upstream and ?ghc-head? is your private fork that you maintain and contribute back when the time comes. I can develop quickly and test against 7.8.3 because I don't have to worry about impacting HEAD and you can develop and test against HEAD because you don't have to worry about impacting the versions in the wild. -- Mateusz K. From ggreif at gmail.com Fri Sep 19 04:48:10 2014 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 19 Sep 2014 06:48:10 +0200 Subject: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44) In-Reply-To: <20140919042710.1E3043A002@ghc.haskell.org> References: <20140919042710.1E3043A002@ghc.haskell.org> Message-ID: Dear devs, I must admit I screwed this up again, I wanted to push on my branch git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative but muscle memory betrayed me and I pushed like this: git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master Sorry for the messup. How can I repair this? I did not intend to "merge" my work yet. It is not totally wrong though. It has three failures, but they are okay. I have a commit in my tree for that, but my firewall won't let them out (they are more than a kilobyte :-( The changes should be reviewed on the branch, and some changes are still expected. Second thought, how could this happen? Was this just a fast-forward of "master" ? Git seems to be a dangerous tool. Cheers and all help welcome, (also review comments regarding this WIP), remorsefully, Gabor On 9/19/14, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > Branch 'master' now includes: > > e12a6a8 Propositional equality for Datatype meta-information > 0a8e6fc Make constructor metadata parametrized (with intended parameter > <- datatype) > f097b77 Implement sameConstructor > cc618e6 get roles right and fix a FIXME > 79c7125 Actually parametrize the Constructor with the Datatype > 7bd4bab Supply a reasonable name (should be derived from d_name tho) > 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) > 4d90e44 Add default case (fixes -Werror) > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > From rarash at student.chalmers.se Fri Sep 19 06:15:44 2014 From: rarash at student.chalmers.se (Arash Rouhani) Date: Fri, 19 Sep 2014 08:15:44 +0200 Subject: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44) In-Reply-To: References: <20140919042710.1E3043A002@ghc.haskell.org> Message-ID: <541BCA10.9060009@student.chalmers.se> On 2014-09-19 06:48, Gabor Greif wrote: > Dear devs, > > I must admit I screwed this up again, I wanted to push on my branch > > git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative > > but muscle memory betrayed me and I pushed like this: > > git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master > > Sorry for the messup. How can I repair this? I did not intend to > "merge" my work yet. > > It is not totally wrong though. It has three failures, but they are > okay. I have a commit in my tree for that, but my firewall won't let > them out (they are more than a kilobyte :-( > > The changes should be reviewed on the branch, and some changes are > still expected. > > Second thought, how could this happen? Was this just a fast-forward of > "master" ? > Git seems to be a dangerous tool. I'm also surprised by this. How can your old commits be a fast-forward of master? Are you sure you didn't rebase your work first? :) Anyhow, the workflow that won't cause mistakes like this is to work *on* branches and not use the refspec:branch syntax and just specify the branch. git push darcs wip/generics-propeq-conservative When I make mistakes like this though I just quickly undo it with a force push. ^^ Cheers, Arash > > Cheers and all help welcome, (also review comments regarding this WIP), > > remorsefully, > > Gabor > > On 9/19/14, git at git.haskell.org wrote: >> Repository : ssh://git at git.haskell.org/ghc >> >> Branch 'master' now includes: >> >> e12a6a8 Propositional equality for Datatype meta-information >> 0a8e6fc Make constructor metadata parametrized (with intended parameter >> <- datatype) >> f097b77 Implement sameConstructor >> cc618e6 get roles right and fix a FIXME >> 79c7125 Actually parametrize the Constructor with the Datatype >> 7bd4bab Supply a reasonable name (should be derived from d_name tho) >> 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) >> 4d90e44 Add default case (fixes -Werror) >> _______________________________________________ >> ghc-commits mailing list >> ghc-commits at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-commits >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Sep 19 06:33:53 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 18 Sep 2014 23:33:53 -0700 Subject: Should we occasionally merge haddock master into ghc-head? In-Reply-To: <541BAF67.4050803@fuuzetsu.co.uk> References: <1411075572-sup-5025@sabre> <541BAF67.4050803@fuuzetsu.co.uk> Message-ID: <1411108407-sup-3661@sabre> OK, thanks for the detailed response! Here's to hoping that the eventual cherry-picking is not too terrible. Cheers, Edward Excerpts from Mateusz Kowalczyk's message of 2014-09-18 21:21:59 -0700: > On 09/18/2014 10:30 PM, Edward Z. Yang wrote: > > Hello Mateusz and all, > > > > With ghc-head and master being developed concurrently, I am wondering if > > GHC developers should be allowed to occasionally merge in changes from > > master. Seems like a good service which would help Mateusz out a bit > > when it comes time to update master for the next version GHC. Or is > > there some reason we shouldn't do this? > > > > Cheers, > > Edward > > > > Hi, > > tl;dr: Far too much effort on the GHC side for very little gain on > Haddock side makes the master/ghc-head split lose part of its function. > > Longer version: > > As I mentioned on IRC, my plan at GHC release time is not to just merge > from ghc-head. Changes by GHC team tend to be small, fixes due to API > changes. Ideally what would happen is that I sit down near release date > and cherry-pick it all out, maybe even squashing it first into a ?update > for next GHC? commit as that makes looking at the actual diff between > branches much easier ? we do not care what changed between day 1 of 7.9 > until last day of 7.9, we only care about what changed between 7.8.3 and > 7.10.x-justbeforerc1. > > One of the large reasons why I wanted to move out Haddock from GHC tree > is that we (Haddock) do not have to go through these API changes at all, > we're only there for the final release. I think this makes > cherry-picking more suited to merging ghc-head ? master. > > But your question is master ? ghc-head. I think it is not necessary for > you to do so. We have already taken steps for compatibility with 7.8.2 > and even split Haddock up further into more packages. This means that > not only would this merge be very unpleasant to do, it'd also be > unpleasant to maintain thereafter. As I don't plan merging ghc-head back > in, it does not greatly reduce labour for me when it comes to it but it > makes it painful for GHC folk. The only reason you might have to merge > master ? ghc-head would therefore be if GHC needed features from master > at which point cherry-picking those features is easier than merging the > whole thing. > > I think it makes sense to think of it as Haddock now being disjoint > software that GHC happens to use, needs to patch sometimes, and simply > contributes those (finalised) patches to Haddock at GHC release time. > Once these merges are done, you can restart ghc-head for 7.11 from > master at that point, rather than trying to go through merges and try to > keep in sync throughout the process. Basically ?master? is the upstream > and ?ghc-head? is your private fork that you maintain and contribute > back when the time comes. I can develop quickly and test against 7.8.3 > because I don't have to worry about impacting HEAD and you can develop > and test against HEAD because you don't have to worry about impacting > the versions in the wild. > From jan.stolarek at p.lodz.pl Fri Sep 19 07:56:10 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 19 Sep 2014 09:56:10 +0200 Subject: Problems with updating Phab revision using arcanist Message-ID: <201409190956.10085.jan.stolarek@p.lodz.pl> Hi all, I have a question to Phab gurus about using arcanist. I created a git branch, hacked a bit and then submitted a review using `arc diff`. Then I make a few more commits and want to update my revision. Running `arc diff` opens up an editor where I can create a new revision. Obviously, that's not what I want so I follow the suggestion from the comment in the editor to use `--update`: # arc diff --update D202 Exception Can't parse an empty diff! (Run with --trace for a full exception trace.) That's not what I want either. I'm left with manually specifying the base commit: arc diff 1719c42 and that works. But that's not really convenient. Any ideas why neither `arc diff` nor `arc diff --update ` don't work (I believe they should)? Janek From ggreif at gmail.com Fri Sep 19 08:18:33 2014 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 19 Sep 2014 10:18:33 +0200 Subject: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44) In-Reply-To: <541BCA10.9060009@student.chalmers.se> References: <20140919042710.1E3043A002@ghc.haskell.org> <541BCA10.9060009@student.chalmers.se> Message-ID: H Arash! On 9/19/14, Arash Rouhani wrote: > > On 2014-09-19 06:48, Gabor Greif wrote: >> Dear devs, >> >> I must admit I screwed this up again, I wanted to push on my branch >> >> git push darcs >> 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative >> >> but muscle memory betrayed me and I pushed like this: >> >> git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master >> >> Sorry for the messup. How can I repair this? I did not intend to >> "merge" my work yet. >> >> It is not totally wrong though. It has three failures, but they are >> okay. I have a commit in my tree for that, but my firewall won't let >> them out (they are more than a kilobyte :-( >> >> The changes should be reviewed on the branch, and some changes are >> still expected. >> >> Second thought, how could this happen? Was this just a fast-forward of >> "master" ? >> Git seems to be a dangerous tool. > I'm also surprised by this. How can your old commits be a fast-forward > of master? Are you sure you didn't rebase your work first? :) Yes I did earlier the day. Before I started pushing on my branch. > > Anyhow, the workflow that won't cause mistakes like this is to work *on* > branches and not use the refspec:branch syntax and just specify the branch. > > git push darcs wip/generics-propeq-conservative I imagine, but I had a small and a bigger commit on the branch and latter did not fit through he FW loophole. > > > When I make mistakes like this though I just quickly undo it with a > force push. ^^ Haha, the haskell.org server blocks this. Cheers, Gabor > > Cheers, > Arash > From alexander at plaimi.net Fri Sep 19 08:18:46 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 19 Sep 2014 10:18:46 +0200 Subject: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44) In-Reply-To: <541BCA10.9060009@student.chalmers.se> References: <20140919042710.1E3043A002@ghc.haskell.org> <541BCA10.9060009@student.chalmers.se> Message-ID: <541BE6E6.8000707@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/09/14 08:15, Arash Rouhani wrote: > When I make mistakes like this though I just quickly undo it with a > force push. ^^ Please don't ever force push to a public repository. On 19/09/14 06:48, Gabor Greif wrote: > Sorry for the messup. How can I repair this? I did not intend to > "merge" my work yet. Just revert? Patch attached. Pushing this patch will revert your commits in a clean way. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQb5uUACgkQRtClrXBQc7W3AAD/d8bh9VvkgZzr6Y8JMPodPcwg +uKct2eapooVjZiaimEBAKo/4MJJBamfPRYOO07GZUUYvXxybtZNaS3nFwPNfY9d =Y8Ka -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Revert-Gabor-s-accidental-merge.patch Type: text/x-patch Size: 10860 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Revert-Gabor-s-accidental-merge.patch.sig Type: application/pgp-signature Size: 96 bytes Desc: not available URL: From ggreif at gmail.com Fri Sep 19 08:21:11 2014 From: ggreif at gmail.com (Gabor Greif) Date: Fri, 19 Sep 2014 10:21:11 +0200 Subject: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44) In-Reply-To: <541BE6E6.8000707@plaimi.net> References: <20140919042710.1E3043A002@ghc.haskell.org> <541BCA10.9060009@student.chalmers.se> <541BE6E6.8000707@plaimi.net> Message-ID: Thanks, I would have done that too, but my ssh won't let big chunks pass. Herbert volunteered to clean this up. Cheers, Gabor On 9/19/14, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 19/09/14 08:15, Arash Rouhani wrote: >> When I make mistakes like this though I just quickly undo it with a >> force push. ^^ > Please don't ever force push to a public repository. > > On 19/09/14 06:48, Gabor Greif wrote: >> Sorry for the messup. How can I repair this? I did not intend to >> "merge" my work yet. > Just revert? Patch attached. Pushing this patch will revert your commits > in a clean way. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQb5uUACgkQRtClrXBQc7W3AAD/d8bh9VvkgZzr6Y8JMPodPcwg > +uKct2eapooVjZiaimEBAKo/4MJJBamfPRYOO07GZUUYvXxybtZNaS3nFwPNfY9d > =Y8Ka > -----END PGP SIGNATURE----- > From simonpj at microsoft.com Fri Sep 19 16:45:58 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 19 Sep 2014 16:45:58 +0000 Subject: Volatile T4801 test In-Reply-To: <87vbojvelb.fsf@gmail.com> References: <87vbojvelb.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22223579@DB3PRD3001MB020.064d.mgd.msft.net> Agreed. Let's remove the max_bytes_used threshold from the test. Simn | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 19 September 2014 16:02 | To: Simon Peyton Jones; Austin Seipp | Subject: Volatile T4801 test | | Hello! | | If you look at | | https://phabricator.haskell.org/diffusion/GHC/history/ | | the four of the recent commits failed mostly due to the volatilness of | T4801; I've seen it fail myself in Phab code-revisions as well... | | What shall we do about T4801, it seems to create unnecessary noise, as | any build-failure raises alarm flags for no good reason (imho)... | | Cheers, | hvr From david.feuer at gmail.com Fri Sep 19 23:33:55 2014 From: david.feuer at gmail.com (David Feuer) Date: Fri, 19 Sep 2014 19:33:55 -0400 Subject: Where can I stick a dead code elimination rule for quotRemInt#? In-Reply-To: References: Message-ID: As I describe in #9617, GHC's CSE in 7.9 seems to be good enough to let Int and Integer use quot x y = fst (x `quotRem` y) rem x y = snd (x `quotRem` y) And actually get good results in code that uses both the quotient and the remainder. I believe the only thing left to be able to actually implement this is a simple rule to turn a match on quotRemInt# into one on quotInt# or remInt# if only the quotient or only the remainder is used. My question is where I could stick such a rule. Can anyone advise me? All I know is that it has to happen after CSE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Sep 20 06:13:30 2014 From: david.feuer at gmail.com (David Feuer) Date: Sat, 20 Sep 2014 02:13:30 -0400 Subject: FFI library error building GHC Message-ID: I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not. Suggest removing libffi/stamp.ffi.static-shared.install. make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Sat Sep 20 10:15:39 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Sat, 20 Sep 2014 12:15:39 +0200 Subject: FFI library error building GHC In-Reply-To: References: Message-ID: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> Could you check if you had any other libffi.a or (any other .a) file for that matter in the libffi folder? I have the suspicion that the new libffi builds the archives for some platforms into different target folders, as someone on irc mentioned that for nix, there was a lib64 folder or so, and hence the libffi.a was in libffi/build/inst/lib64/libffi.a iirc. On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not. > Suggest removing libffi/stamp.ffi.static-shared.install. > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs ????????????????? Moritz Angermann +49 170 54 33 0 74 moritz at lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. M?nchen Amtsgericht M?nchen HRB 207882 Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From mp2e at archlinux.us Sat Sep 20 10:32:01 2014 From: mp2e at archlinux.us (member MP2E) Date: Sat, 20 Sep 2014 03:32:01 -0700 Subject: Fwd: FFI library error building GHC In-Reply-To: References: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> Message-ID: Yep, I reported this same build error for NixOS on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann wrote: > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as > suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build -static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ????????????????? > Moritz Angermann > +49 170 54 33 0 74 > moritz at lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. M?nchen > > Amtsgericht M?nchen HRB 207882 > Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz at lichtzwerge.de Sat Sep 20 11:18:42 2014 From: moritz at lichtzwerge.de (Moritz Angermann) Date: Sat, 20 Sep 2014 13:18:42 +0200 Subject: FFI library error building GHC In-Reply-To: References: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> Message-ID: <0024A70B-AC0E-4A6A-BC33-D72CAFCA07BC@lichtzwerge.de> While this is not a proper fix. Assuming there is no no lib folder, and the proper lib is in lib64, does: symlinking lib64 to lib and continuing with make solve the issue? On Sep 20, 2014, at 12:32 PM, member MP2E wrote: > Yep, I reported this same build error for NixOS on x86_64, unfortunately I haven't found any way to solve it. Reverting the commit that upgrades to libffi-3.1 still showed this issue. I'd love to see this fixed, as I am unable to do any development on GHC until it's fixed :( > > On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann wrote: > Could you check if you had any other libffi.a or (any other .a) file for that matter in the > libffi folder? I have the suspicion that the new libffi builds the archives for some platforms into different target folders, as someone on irc mentioned that for nix, there was a lib64 folder or so, and hence the libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ????????????????? > Moritz Angermann > +49 170 54 33 0 74 > moritz at lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. M?nchen > > Amtsgericht M?nchen HRB 207882 > Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mp2e at archlinux.us Sat Sep 20 12:25:56 2014 From: mp2e at archlinux.us (member MP2E) Date: Sat, 20 Sep 2014 05:25:56 -0700 Subject: FFI library error building GHC In-Reply-To: <0024A70B-AC0E-4A6A-BC33-D72CAFCA07BC@lichtzwerge.de> References: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> <0024A70B-AC0E-4A6A-BC33-D72CAFCA07BC@lichtzwerge.de> Message-ID: Symlinking lib64 to lib didn't seem to work, I think the directory is getting cleared before build. But if I copy the contents of lib64 to lib after the build fails and then type make again, ghc compiles! Thanks for the workaround, hopefully a real fix will be found soon enough :) On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann wrote: > While this is not a proper fix. Assuming there is no no lib folder, and > the proper lib is in lib64, does: symlinking lib64 to lib and continuing > with make solve the issue? > > On Sep 20, 2014, at 12:32 PM, member MP2E wrote: > > > Yep, I reported this same build error for NixOS on x86_64, unfortunately > I haven't found any way to solve it. Reverting the commit that upgrades to > libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > unable to do any development on GHC until it's fixed :( > > > > On Sat, Sep 20, 2014 at 3:15 AM, Moritz Angermann > wrote: > > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > > > I keep getting this error. Can anyone help? I tried removing the file > as suggested, but it made no difference. > > > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build -static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > > Suggest removing libffi/stamp.ffi.static-shared.install. > > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > > make[1]: *** Waiting for unfinished jobs.... > > > make: *** [all] Error 2 > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > ????????????????? > > Moritz Angermann > > +49 170 54 33 0 74 > > moritz at lichtzwerge.de > > > > lichtzwerge GmbH > > Freisinger Landstr. 25 > > 85748 Garching b. M?nchen > > > > Amtsgericht M?nchen HRB 207882 > > Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl > > USt-Id: DE291948767 > > > > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > > E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > > Absender und vernichten Sie diese Mail. > > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > > ist nicht gestattet. > > This e-mail may contain confidential and/or privileged information. > > If you are not the intended recipient (or have received this e-mail in > > error) please notify the sender immediately and destroy this e-mail. > > Any unauthorized copying, disclosure or distribution of the material in > > this e-mail is strictly forbidden. > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mp2e at archlinux.us Sat Sep 20 15:12:20 2014 From: mp2e at archlinux.us (member MP2E) Date: Sat, 20 Sep 2014 08:12:20 -0700 Subject: FFI library error building GHC In-Reply-To: <87sijmnzdz.fsf@gmail.com> References: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> <0024A70B-AC0E-4A6A-BC33-D72CAFCA07BC@lichtzwerge.de> <87sijmnzdz.fsf@gmail.com> Message-ID: Filed a bug under GHC Trac, #9620 On Sat, Sep 20, 2014 at 7:24 AM, Herbert Valerio Riedel wrote: > Hello! > > Is there a ticket for that already on GHC Trac? If not, please create > one, and try to document everything we already know about this issue > > On 2014-09-20 at 14:25:56 +0200, member MP2E wrote: > > Symlinking lib64 to lib didn't seem to work, I think the directory is > > getting cleared before build. But if I copy the contents of lib64 to lib > > after the build fails and then type make again, ghc compiles! > > > > Thanks for the workaround, hopefully a real fix will be found soon > enough :) > > > > On Sat, Sep 20, 2014 at 4:18 AM, Moritz Angermann > > > wrote: > > > >> While this is not a proper fix. Assuming there is no no lib folder, and > >> the proper lib is in lib64, does: symlinking lib64 to lib and continuing > >> with make solve the issue? > >> > >> On Sep 20, 2014, at 12:32 PM, member MP2E wrote: > >> > >> > Yep, I reported this same build error for NixOS on x86_64, > unfortunately > >> I haven't found any way to solve it. Reverting the commit that upgrades > to > >> libffi-3.1 still showed this issue. I'd love to see this fixed, as I am > >> unable to do any development on GHC until it's fixed :( > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Sep 20 16:45:29 2014 From: david.feuer at gmail.com (David Feuer) Date: Sat, 20 Sep 2014 12:45:29 -0400 Subject: FFI library error building GHC In-Reply-To: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> References: <2DCB7E93-20D5-4BD6-ABF6-101C7A7D0B36@lichtzwerge.de> Message-ID: Here's what I could find: [dfeuer at lemur libffi]$ find . -name "*\.a" ./build/inst/lib64/libffi.a ./build/x86_64-unknown-linux-gnu/.libs/libffi.a ./build/x86_64-unknown-linux-gnu/.libs/libffi_convenience.a On Sat, Sep 20, 2014 at 6:15 AM, Moritz Angermann wrote: > Could you check if you had any other libffi.a or (any other .a) file for > that matter in the > libffi folder? I have the suspicion that the new libffi builds the > archives for some platforms into different target folders, as someone on > irc mentioned that for nix, there was a lib64 folder or so, and hence the > libffi.a was in libffi/build/inst/lib64/libffi.a iirc. > > On Sep 20, 2014, at 8:13 AM, David Feuer wrote: > > > I keep getting this error. Can anyone help? I tried removing the file as > suggested, but it made no difference. > > > > "/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o > utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc > -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf > -i -iutils/genapply/. -iutils/genapply/dist/build > -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build > -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts > -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir > utils/genapply/dist/build -static -O -H64m -package pretty -package-db > libraries/bootstrapping.conf -i -iutils/genapply/. > -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen > -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen > -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o > > libffi/stamp.ffi.static-shared.install exists, but > libffi/build/inst/lib/libffi.a does not. > > Suggest removing libffi/stamp.ffi.static-shared.install. > > make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [all] Error 2 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > ????????????????? > Moritz Angermann > +49 170 54 33 0 74 > moritz at lichtzwerge.de > > lichtzwerge GmbH > Freisinger Landstr. 25 > 85748 Garching b. M?nchen > > Amtsgericht M?nchen HRB 207882 > Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl > USt-Id: DE291948767 > > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese > E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den > Absender und vernichten Sie diese Mail. > Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail > ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Mon Sep 22 12:18:01 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 22 Sep 2014 14:18:01 +0200 Subject: Permitting trailing commas for record syntax ADT declarations Message-ID: <54201379.7050307@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 - From a lead-developer-who-merges-a-lot point of view, trailing commas in import lists are a godsend. import Foo ( fu, baz, quux, ) is brilliant. It lets me add a line, + foobar, and remove a line, - - fu, in a very neat manner. Annoying 3-way merges be gone! It would be *very* useful if the same behaviour existed for record syntax. I wish this existed on an almost daily basis, data Foo a b = MkFoo { fu :: a, ba :: b, } If there's not too much opposition to the idea, I would like to take a stab at implementing this. Any pointers on *how* to implement it, would be very useful as I'm not familiar with the codebase outside of libraries/base at all. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgE3kACgkQRtClrXBQc7WHLQD/V9bHhC9ekobxxB5j7ZwAVj8e G3pQr4jmLAOFHkdSs/EBAIybHdSVXQlQ1fFTpLUzB/EIDLpiHlKKlU4tG01hYUhp =A1Ky -----END PGP SIGNATURE----- From alexander at plaimi.net Mon Sep 22 12:31:10 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 22 Sep 2014 14:31:10 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54201596.6020205@gmail.com> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> Message-ID: <5420168E.5020503@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forwarding this & my reply to the ML as well, On 22/09/14 14:27, David Luposchainsky wrote: > +1. While you're at it, you may also want to consider allowing > leading commas for the folks that write their exports/records "the > other way round" Sure. Both styles are common in the wild, so that makes sense. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgFo4ACgkQRtClrXBQc7Xz1QEAn5rLEoUuHPGRkJIEy/ZKHuiM xxIF+i/E8X1Y5cdd5HQA/jski9JOlu7LdY1ieucpSMe2KgF3v0VHO+aO+q7QZ93x =v9Ba -----END PGP SIGNATURE----- From johan.tibell at gmail.com Mon Sep 22 13:28:10 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 22 Sep 2014 15:28:10 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <5420168E.5020503@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> Message-ID: +1 I think this makes sense and we should allow trailing commas wherever the syntax allows it without adding ambiguity (e.g. tuple sections prevent trailing commas for tuple declarations.) P.S. Last time we tried to discuss something like this (on libraries@ I believe) the whole discussion devolved into a "lets rewrite all of Haskell". Lets not do that here. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Mon Sep 22 13:43:45 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 22 Sep 2014 15:43:45 +0200 Subject: How to catch errors/unsolved constraints from GHC type checker? Message-ID: <54202791.3080404@chalmers.se> Hi, I am stuck fixing issue #9582 https://ghc.haskell.org/trac/ghc/ticket/9582 I need to test whether one type is a subtype of another and throw a custom error if this is not the case. I tried (errMsgs, result) <- tryTcErrs $ tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty case result of Just _coercion -> return () Nothing -> badInstSigErr sel_name local_meth_ty However, it does not seem to do what I expect. It acts as if I had not tried to catch the error, it acts as just tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty My hypothetical explanations: 1. 'tryTcErrs' is not the correct function to catch errors in the type checker. Or, 2. 'tcSubType' does not generate errors, just postponed constraints, which are checked later in a clean-up phase. Thus, I do not get an error now I could handle, but the error is generated later during the constraint solving phase, where I do not have a handler in place. In this case, I would need something like Agda's noConstraints, tryTcErrs $ noConstraints $ tcSubType... which forces 'tcSubType' to check without generating new unification constraints. Any advice how to do is or where to continue searching? Thanks, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From hvriedel at gmail.com Mon Sep 22 13:57:44 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 22 Sep 2014 15:57:44 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <5420168E.5020503@plaimi.net> (Alexander Berntsen's message of "Mon, 22 Sep 2014 14:31:10 +0200") References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> Message-ID: <87r3z3wyef.fsf@gmail.com> On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote: > Forwarding this & my reply to the ML as well, > > > On 22/09/14 14:27, David Luposchainsky wrote: >> +1. While you're at it, you may also want to consider allowing >> leading commas for the folks that write their exports/records "the >> other way round" > Sure. Both styles are common in the wild, so that makes sense. +1 (I'd even say that leading-comma style is the predominant one these days thanks to [1] et al.) Let's be a bit more conrete. Where everywhere shall leading+trailing commas be supported, here's a few places OTTOMH, where comma-separated entities occur which may or may not benefit from this treatment: - list-syntax (+ even in pattern position?) - module import/export list - record syntax (+ patterns?) - pattern-guards - language pragmas - ...? [1]: https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md From johan.tibell at gmail.com Mon Sep 22 14:01:36 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 22 Sep 2014 16:01:36 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <87r3z3wyef.fsf@gmail.com> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <87r3z3wyef.fsf@gmail.com> Message-ID: On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel wrote: > On 2014-09-22 at 14:31:10 +0200, Alexander Berntsen wrote: > > Forwarding this & my reply to the ML as well, > > > > > > On 22/09/14 14:27, David Luposchainsky wrote: > >> +1. While you're at it, you may also want to consider allowing > >> leading commas for the folks that write their exports/records "the > >> other way round" > > Sure. Both styles are common in the wild, so that makes sense. > > +1 (I'd even say that leading-comma style is the predominant one these > days thanks to [1] et al.) > > [snip] > > > [1]: > https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md And to complete the circle. I designed [1] to work with the lack of support for a trailing comma. If we supported a trailing comma my style guide would probably be different. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Mon Sep 22 14:47:56 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 22 Sep 2014 16:47:56 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <87r3z3wyef.fsf@gmail.com> Message-ID: <5420369C.6080503@chalmers.se> +1 to leading and trailing separators. On 22.09.2014 16:01, Johan Tibell wrote: > On Mon, Sep 22, 2014 at 3:57 PM, Herbert Valerio Riedel > > https://github.com/tibbe/haskell-style-guide/blob/master/haskell-style.md Nice, style guide. I'll probably fork it for the Agda project... -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From abela at chalmers.se Mon Sep 22 14:49:42 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 22 Sep 2014 16:49:42 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <87r3z3wyef.fsf@gmail.com> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <87r3z3wyef.fsf@gmail.com> Message-ID: <54203706.5050209@chalmers.se> To add to your list: - data declarations, ex data Bla = | First | Second | Third On 22.09.2014 15:57, Herbert Valerio Riedel wrote: > Let's be a bit more conrete. Where everywhere shall leading+trailing > commas be supported, here's a few places OTTOMH, where comma-separated > entities occur which may or may not benefit from this treatment: > > - list-syntax (+ even in pattern position?) > > - module import/export list > > - record syntax (+ patterns?) > > - pattern-guards > > - language pragmas > > - ...? -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From alexander at plaimi.net Mon Sep 22 16:13:34 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 22 Sep 2014 18:13:34 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54201379.7050307@plaimi.net> References: <54201379.7050307@plaimi.net> Message-ID: <54204AAE.6010002@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Friends, I have a commit that allows for trailing and leading commas in record updates, and it works fine. I think I now have gotten the hang of how the parser is structured and generally works. GHCi output with my patch: ? data Foo a b = MkFoo {foo :: a, bar :: b} deriving (Show) ? (MkFoo {,foo = 2, bar = 3,}) {,foo=3,} MkFoo {foo = 3, bar = 3} I am happy to have a stab at all the other requests in this thread. I will make small commits so that we can cherry-pick the ones we want. We need to decide if we're going to sneak this into HEAD, or introduce a language pragma (or one per structure that permits it). My vote goes for the first-mentioned route, as this should be non-breaking changes (if I do them correctly). Please cast your vote on the matter. :-] - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQgSq4ACgkQRtClrXBQc7WtfgD+I/K/Cy+aiaGZeGUUQC8yQthW +wFf7+9sKX0dz0PktxgBAIVamPo/UhDLTgkFJOM03ro6OOC5i3Kb4/0YhsnTH/BP =SPjR -----END PGP SIGNATURE----- From simonpj at microsoft.com Mon Sep 22 19:07:16 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Sep 2014 19:07:16 +0000 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> I?m all for it. To progress it you need to ? open a Trac ticket, ? start a wiki page to describe the design specifically (e.g give all the changed syntax rules) ? have a language extension TrailingCommas (or something) to enable the extension ? perhaps suggest switching on the extension if the program parses with it, but fails without ? develop a patch Easy really! I doubt it?s controversial. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 22 September 2014 14:28 To: Alexander Berntsen Cc: ghc-devs at haskell.org Subject: Re: Permitting trailing commas for record syntax ADT declarations +1 I think this makes sense and we should allow trailing commas wherever the syntax allows it without adding ambiguity (e.g. tuple sections prevent trailing commas for tuple declarations.) P.S. Last time we tried to discuss something like this (on libraries@ I believe) the whole discussion devolved into a "lets rewrite all of Haskell". Lets not do that here. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Sep 22 19:07:34 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 22 Sep 2014 19:07:34 +0000 Subject: How to catch errors/unsolved constraints from GHC type checker? In-Reply-To: <54202791.3080404@chalmers.se> References: <54202791.3080404@chalmers.se> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2222850C@DB3PRD3001MB020.064d.mgd.msft.net> I'm sorry about being slow to reply -- utterly swamped. | 2. 'tcSubType' does not generate errors, just postponed constraints, | which are checked later in a clean-up phase. Thus, I do not get an | error now I could handle, but the error is generated later during the | constraint solving phase, where I do not have a handler in place. This is dead right, and I think it's a huge strength of GHC's current type inference mechanism. Essentially all type error messages are generated in TcErrors, not in places scattered over the compiler. This is not a "clean-up phase". It is *the* place that type errors are generated. For tcSubType, the way to control your error messages is through the "CtOrigin" and "UserTypeCtxt" passed to tcSubType. The UserTypeCtxt is attached (via the ic_info field of Implication) to the implication constraint generated by the tcSubType. If you want, you can add an extra constructor to UserTypeCtxt. The CtOrigin is attached to the instantiated constraints generated by the sub-type check. Both are accessible to the error-message generation in TcErrors. In short, instead of catching the error(s) *now*, GHC just attaches enough information to the constraints that you can generate a good error message later. I hope that is of some help. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Andreas | Abel | Sent: 22 September 2014 14:44 | To: ghc-devs at haskell.org | Subject: How to catch errors/unsolved constraints from GHC type checker? | | Hi, I am stuck fixing issue #9582 | | https://ghc.haskell.org/trac/ghc/ticket/9582 | | I need to test whether one type is a subtype of another and throw a | custom error if this is not the case. I tried | | (errMsgs, result) <- tryTcErrs $ | tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty | | case result of | Just _coercion -> return () | Nothing -> badInstSigErr sel_name local_meth_ty | | However, it does not seem to do what I expect. It acts as if I had not | tried to catch the error, it acts as just | | tcSubType ctOrigin userTypeCtxt local_meth_ty sig_ty | | My hypothetical explanations: | | 1. 'tryTcErrs' is not the correct function to catch errors in the | type checker. Or, | | 2. 'tcSubType' does not generate errors, just postponed constraints, | which are checked later in a clean-up phase. Thus, I do not get an | error now I could handle, but the error is generated later during the | constraint solving phase, where I do not have a handler in place. In | this case, I would need something like Agda's noConstraints, | | tryTcErrs $ noConstraints $ tcSubType... | | which forces 'tcSubType' to check without generating new unification | constraints. | | Any advice how to do is or where to continue searching? | | Thanks, | Andreas | | | -- | Andreas Abel <>< Du bist der geliebte Mensch. | | Department of Computer Science and Engineering | Chalmers and Gothenburg University, Sweden | | andreas.abel at gu.se | http://www2.tcs.ifi.lmu.de/~abel/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From johan.tibell at gmail.com Mon Sep 22 20:02:16 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 22 Sep 2014 22:02:16 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Don't worry about supporting trailing/leading commas everywhere for now. Have it work for records first. We can always add support in more places later. On Mon, Sep 22, 2014 at 9:07 PM, Simon Peyton Jones wrote: > I?m all for it. To progress it you need to > > ? open a Trac ticket, > > ? start a wiki page to describe the design specifically (e.g give > all the changed syntax rules) > > ? have a language extension TrailingCommas (or something) to > enable the extension > > ? perhaps suggest switching on the extension if the program parses > with it, but fails without > > ? develop a patch > > > > Easy really! I doubt it?s controversial. > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Johan > Tibell > *Sent:* 22 September 2014 14:28 > *To:* Alexander Berntsen > *Cc:* ghc-devs at haskell.org > *Subject:* Re: Permitting trailing commas for record syntax ADT > declarations > > > > +1 > > > > I think this makes sense and we should allow trailing commas wherever the > syntax allows it without adding ambiguity (e.g. tuple sections prevent > trailing commas for tuple declarations.) > > > > P.S. Last time we tried to discuss something like this (on libraries@ I > believe) the whole discussion devolved into a "lets rewrite all of > Haskell". Lets not do that here. Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Tue Sep 23 07:05:30 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 09:05:30 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54211BBA.40708@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22/09/14 22:02, Johan Tibell wrote: > Don't worry about supporting trailing/leading commas everywhere for > now. Have it work for records first. We can always add support in > more places later. I already have it for records. It seems to be working fine. I thought I'd spend the day adding it for some of the other suggestions as well. It seems to be quite easy, and it's a neat learning experience for getting intimate with the parser. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhG7oACgkQRtClrXBQc7WDFQD+IuS5t+jeiZzNY57QIzbN9g0Q iSvtDST3dMX1X3Ielq4A/idQ7NdyBewJGMG2DKrxu7ZFqhxeP/kQmjpeVUnRszzL =7w7H -----END PGP SIGNATURE----- From alexander at plaimi.net Tue Sep 23 07:11:22 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 09:11:22 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54211D1A.5050400@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22/09/14 21:07, Simon Peyton Jones wrote: > have a language extension TrailingCommas (or something) to enable > the extension For clarification: are you overruling the "do we sneak it in HEAD or use pragma(s)"-vote and telling me to do the latter? If we can sneak it into HEAD (this is @ you Johan, too), I suggest that someone applies my patches to make import and export lists support leading commas (presently they only support trailing commas, per the report) -- and following this I can just send a bunch of "Permit leading/trailing ',' in Foo" patches to Phabricator, and you guys can bikeshed over there about which ones you actually want to commit. ;-) If I am to go down the pragma route, I guess I can make a RudundantCommas pragma or something like that, that implements trailing commas for imports/exports, and leading/trailing commas for the suggestions in this thread. I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to the pragma route either. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 =FfHX -----END PGP SIGNATURE----- From alexander at plaimi.net Tue Sep 23 07:30:28 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 09:30:28 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54211D1A.5050400@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> Message-ID: <54212194.3070300@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 A piece of information which might be relevant: if we play the pragma game, be prepared for patches that are much more involved. Sneaking into HEAD means applying a few 2-5 line patches (from what I can tell presently), whilst requiring a pragma means either making the parser code really messy "everywhere" there's a comma, or having lots of duplication there. And giving it some thought, I'd argue for going more or less the same route with regards to patches for a pragma. I.e. add an initial patch that adds the pragma itself & leading commas for imports/exports, and then submit a bunch of small commits to augment the pragma to phabricator, and update the Wiki accordingly. In any event, I'll have to get everything working, so you'll have plenty of time meanwhile to decide on this issue. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhIZQACgkQRtClrXBQc7V2AwD/SkAHL0fIXhP3DDmI0i7IipeJ 8Z1JT0k8YqyssJtq6YgBAIB4betQXTHMDt0IGu+OLty6A6iGp2WZQ4kRNlx1lVWa =1xbA -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Sep 23 07:31:58 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Sep 2014 07:31:58 +0000 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54211D1A.5050400@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> | > have a language extension TrailingCommas (or something) to enable | > the extension | For clarification: are you overruling the "do we sneak it in HEAD or | use pragma(s)"-vote and telling me to do the latter? Well, it *is* a language extension, exactly like lots of other language extensions, isn't it? (E.g. UnicodeSyntax.) What alternative action, exactly, are you proposing? Why do you propose to treat it differently to other language extensions? I would be reluctant to simply add it without any indication; then GHC would accept non-Haskell 2010 programs. And we have not done that with other extensions. Simon | | If we can sneak it into HEAD (this is @ you Johan, too), I suggest | that someone applies my patches to make import and export lists | support leading commas (presently they only support trailing commas, | per the report) -- and following this I can just send a bunch of | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you | guys can bikeshed over there about which ones you actually want to | commit. ;-) | | If I am to go down the pragma route, I guess I can make a | RudundantCommas pragma or something like that, that implements | trailing commas for imports/exports, and leading/trailing commas for | the suggestions in this thread. | | I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to | the pragma route either. | - -- | Alexander | alexander at plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 | =FfHX | -----END PGP SIGNATURE----- From abela at chalmers.se Tue Sep 23 07:39:29 2014 From: abela at chalmers.se (Andreas Abel) Date: Tue, 23 Sep 2014 09:39:29 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <542123B1.1060903@chalmers.se> To account for all forms of leading/trailing separators, I suggest to call the pragma SpuriousSeparators or ExtraSeparators If you want to do it only for commas, I suggest ExtraCommas (not the proper latin plural, which would be ExtraCommata, but certainly preferable :-)). On 23.09.2014 09:31, Simon Peyton Jones wrote: > | > have a language extension TrailingCommas (or something) to enable > | > the extension > | For clarification: are you overruling the "do we sneak it in HEAD or > | use pragma(s)"-vote and telling me to do the latter? > > Well, it *is* a language extension, exactly like lots of other language extensions, isn't it? (E.g. UnicodeSyntax.) What alternative action, exactly, are you proposing? Why do you propose to treat it differently to other language extensions? I would be reluctant to simply add it without any indication; then GHC would accept non-Haskell 2010 programs. And we have not done that with other extensions. > > Simon > > | > | If we can sneak it into HEAD (this is @ you Johan, too), I suggest > | that someone applies my patches to make import and export lists > | support leading commas (presently they only support trailing commas, > | per the report) -- and following this I can just send a bunch of > | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > | guys can bikeshed over there about which ones you actually want to > | commit. ;-) > | > | If I am to go down the pragma route, I guess I can make a > | RudundantCommas pragma or something like that, that implements > | trailing commas for imports/exports, and leading/trailing commas for > | the suggestions in this thread. > | > | I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to > | the pragma route either. > | - -- > | Alexander > | alexander at plaimi.net > | https://secure.plaimi.net/~alexander > | -----BEGIN PGP SIGNATURE----- > | Version: GnuPG v2 > | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > | > | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR > | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 > | =FfHX > | -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From alexander at plaimi.net Tue Sep 23 07:40:08 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 09:40:08 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <542123D8.2080709@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/09/14 09:31, Simon Peyton Jones wrote: > Well, it *is* a language extension, exactly like lots of other > language extensions, isn't it? (E.g. UnicodeSyntax.) What > alternative action, exactly, are you proposing? Why do you propose > to treat it differently to other language extensions? I would be > reluctant to simply add it without any indication; then GHC would > accept non-Haskell 2010 programs. And we have not done that with > other extensions. If this policy has been followed that firmly then I too am reluctant to go against it. A pragma it is then. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhI9gACgkQRtClrXBQc7X4kAEAn5XrGTFZa0AR372xPEKS2ddE vt5DYJ+wU+xjYW6HYSYBAKMqdL3bO7Q8GNNQmX4OQhcrwvpQcSov17F2E5FyFrI/ =BGZA -----END PGP SIGNATURE----- From alexander at plaimi.net Tue Sep 23 07:40:54 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 09:40:54 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <542123B1.1060903@chalmers.se> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF222299C8@DB3PRD3001MB020.064d.mgd.msft.net> <542123B1.1060903@chalmers.se> Message-ID: <54212406.9030202@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/09/14 09:39, Andreas Abel wrote: > If you want to do it only for commas, I suggest ExtraCommas It's only going to be commas, I think. I don't care about the name. ExtraCommas is fine by me. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhJAYACgkQRtClrXBQc7XeIAD/em/K42ZxittTiDT5vU+p607I RJAhM5ZIHZDXbzKkV14BALQLxhuVX17Tsa4mWSQZ9vqTllwu0DMe+Atea6MxbGcj =vRVV -----END PGP SIGNATURE----- From roma at ro-che.info Tue Sep 23 07:41:20 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 23 Sep 2014 10:41:20 +0300 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54211D1A.5050400@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> Message-ID: <54212420.9020104@ro-che.info> On 23/09/14 10:11, Alexander Berntsen wrote: > On 22/09/14 21:07, Simon Peyton Jones wrote: >> have a language extension TrailingCommas (or something) to enable >> the extension > For clarification: are you overruling the "do we sneak it in HEAD or > use pragma(s)"-vote and telling me to do the latter? > > If we can sneak it into HEAD (this is @ you Johan, too), I suggest > that someone applies my patches to make import and export lists > support leading commas (presently they only support trailing commas, > per the report) -- and following this I can just send a bunch of > "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > guys can bikeshed over there about which ones you actually want to > commit. ;-) > > If I am to go down the pragma route, I guess I can make a > RudundantCommas pragma or something like that, that implements > trailing commas for imports/exports, and leading/trailing commas for > the suggestions in this thread. > > I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to > the pragma route either. Here's my reasoning: If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be accepted, because they do not belong to Haskell 2010. Which means that you do need an extension to identify this difference in behavior. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From johan.tibell at gmail.com Tue Sep 23 08:03:11 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 23 Sep 2014 10:03:11 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54212420.9020104@ro-che.info> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212420.9020104@ro-che.info> Message-ID: I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones. One could argue that perhaps the HaskellXX standard might pick up this new pragma and thus making it unnecessary eventually, but the standardization process is dead (and even when it was alive, it was lagging actual practice enough that it was largely ignored.) On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka wrote: > On 23/09/14 10:11, Alexander Berntsen wrote: > > On 22/09/14 21:07, Simon Peyton Jones wrote: > >> have a language extension TrailingCommas (or something) to enable > >> the extension > > For clarification: are you overruling the "do we sneak it in HEAD or > > use pragma(s)"-vote and telling me to do the latter? > > > > If we can sneak it into HEAD (this is @ you Johan, too), I suggest > > that someone applies my patches to make import and export lists > > support leading commas (presently they only support trailing commas, > > per the report) -- and following this I can just send a bunch of > > "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > > guys can bikeshed over there about which ones you actually want to > > commit. ;-) > > > > If I am to go down the pragma route, I guess I can make a > > RudundantCommas pragma or something like that, that implements > > trailing commas for imports/exports, and leading/trailing commas for > > the suggestions in this thread. > > > > I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to > > the pragma route either. > > Here's my reasoning: > > If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be > accepted, because they do not belong to Haskell 2010. > > Which means that you do need an extension to identify this difference in > behavior. > > Roman > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Tue Sep 23 08:05:58 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 10:05:58 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212420.9020104@ro-che.info> Message-ID: <542129E6.4010805@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/09/14 10:03, Johan Tibell wrote: > I must say that requiring a language pragma makes the feature quite > a bit more heavy weight. We're not changing the meaning of any > existing programs, just allowing some new ones. One could argue > that perhaps the HaskellXX standard might pick up this new pragma > and thus making it unnecessary eventually, but the standardization > process is dead (and even when it was alive, it was lagging actual > practice enough that it was largely ignored.) It makes it a *lot* more involved. And your reasoning of "hey, it doesn't break anything" was that of my own. Staring at the parser code this morning I've decided that if there's a pragma, I will add a Wiki page and Trac ticket and have everyone vote on what they want to go in, and then make *one* commit, "Add ExtraCommas" that does it all. It will be a gigantic mess to do it in small commits. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhKeYACgkQRtClrXBQc7U4twD8D/Z1Ae0AeBlmALwCj/UMbeJH Oa8d535Ce3qzyrU68xgBAJnjJJOYT2IScsfMiUDv7cwRGQisPBujHIedohmFUjT3 =WtsL -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Sep 23 08:23:22 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Sep 2014 08:23:22 +0000 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212420.9020104@ro-che.info> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22229A7B@DB3PRD3001MB020.064d.mgd.msft.net> We're not changing the meaning of any existing programs, just allowing some new ones. Yes, that?s true of quite a few other extensions too, notably UnicodeSyntax. Even GADTs!! It?s hard to know where to draw the line. There is, in theory at least, the point that the language extension signals that this module might not work with some other Haskell compiler. My instinct is to treat it uniformly, like other language extensions. But strong sentiment to the contrary from GHC users would persuade me. It?s not that big a deal. Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 23 September 2014 09:03 To: Roman Cheplyaka Cc: Alexander Berntsen; Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: Permitting trailing commas for record syntax ADT declarations I must say that requiring a language pragma makes the feature quite a bit more heavy weight. We're not changing the meaning of any existing programs, just allowing some new ones. One could argue that perhaps the HaskellXX standard might pick up this new pragma and thus making it unnecessary eventually, but the standardization process is dead (and even when it was alive, it was lagging actual practice enough that it was largely ignored.) On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka > wrote: On 23/09/14 10:11, Alexander Berntsen wrote: > On 22/09/14 21:07, Simon Peyton Jones wrote: >> have a language extension TrailingCommas (or something) to enable >> the extension > For clarification: are you overruling the "do we sneak it in HEAD or > use pragma(s)"-vote and telling me to do the latter? > > If we can sneak it into HEAD (this is @ you Johan, too), I suggest > that someone applies my patches to make import and export lists > support leading commas (presently they only support trailing commas, > per the report) -- and following this I can just send a bunch of > "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > guys can bikeshed over there about which ones you actually want to > commit. ;-) > > If I am to go down the pragma route, I guess I can make a > RudundantCommas pragma or something like that, that implements > trailing commas for imports/exports, and leading/trailing commas for > the suggestions in this thread. > > I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to > the pragma route either. Here's my reasoning: If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be accepted, because they do not belong to Haskell 2010. Which means that you do need an extension to identify this difference in behavior. Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Sep 23 08:26:35 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 23 Sep 2014 11:26:35 +0300 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212420.9020104@ro-che.info> Message-ID: <54212EBB.8080703@ro-che.info> Note that there's another dimension to this question: whether this pragma is switched on by default. We already have precedents like NondecreasingIndentation. So, if you mean heavy-weigth to use, not to implement, then this may address your concern. Now, with my haskell-src-exts maintainer hat on, things like this tend to be problematic for us, because users assume that if ghc compiles a program without any pragmas, so should HSE, which it currently doesn't. Perhaps we should try to replicate GHC's default behavior in terms of the default accepted language, too. But as a GHC user, I agree that this extension is innocent enough to be turned on by default. Still, Haskell 98 and Haskell 2010 should remain immutable, in my opinion. PS I just remembered that newer Cabals ask you to specify either Haskell98 or Haskell2010, so that might make a turned-on-by-default extension less useful and more confusing. On 23/09/14 11:03, Johan Tibell wrote: > I must say that requiring a language pragma makes the feature quite a bit > more heavy weight. We're not changing the meaning of any existing programs, > just allowing some new ones. One could argue that perhaps the HaskellXX > standard might pick up this new pragma and thus making it unnecessary > eventually, but the standardization process is dead (and even when it was > alive, it was lagging actual practice enough that it was largely ignored.) > > > On Tue, Sep 23, 2014 at 9:41 AM, Roman Cheplyaka wrote: > >> On 23/09/14 10:11, Alexander Berntsen wrote: >>> On 22/09/14 21:07, Simon Peyton Jones wrote: >>>> have a language extension TrailingCommas (or something) to enable >>>> the extension >>> For clarification: are you overruling the "do we sneak it in HEAD or >>> use pragma(s)"-vote and telling me to do the latter? >>> >>> If we can sneak it into HEAD (this is @ you Johan, too), I suggest >>> that someone applies my patches to make import and export lists >>> support leading commas (presently they only support trailing commas, >>> per the report) -- and following this I can just send a bunch of >>> "Permit leading/trailing ',' in Foo" patches to Phabricator, and you >>> guys can bikeshed over there about which ones you actually want to >>> commit. ;-) >>> >>> If I am to go down the pragma route, I guess I can make a >>> RudundantCommas pragma or something like that, that implements >>> trailing commas for imports/exports, and leading/trailing commas for >>> the suggestions in this thread. >>> >>> I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to >>> the pragma route either. >> >> Here's my reasoning: >> >> If you invoke ghc with -XHaskell2010, then trailing commas shouldn't be >> accepted, because they do not belong to Haskell 2010. >> >> Which means that you do need an extension to identify this difference in >> behavior. >> >> Roman >> >> > From daniel.trstenjak at gmail.com Tue Sep 23 08:30:15 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 23 Sep 2014 10:30:15 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212420.9020104@ro-che.info> Message-ID: <20140923083015.GA3052@machine> On Tue, Sep 23, 2014 at 10:03:11AM +0200, Johan Tibell wrote: > I must say that requiring a language pragma makes the feature quite a bit more > heavy weight. We're not changing the meaning of any existing programs, just > allowing some new ones. Without using a new language pragma you will get more or less telling error messages if you're trying to compile code using this new syntax with older ghcs. Using a new language pragma will give you quite telling error messages. Greetings, Daniel From simonpj at microsoft.com Tue Sep 23 08:55:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Sep 2014 08:55:18 +0000 Subject: Permitting trailing commas for record syntax ADT declarations References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> PS I have to admit that GHC already fails to adhere to H-2010 by accepting trailing commas in module import lists, *without* a language extension. That is naughty, but I suppose it is a foot in the door. What to others think? Incidentally, trailing commas in tuples have quite a different meaning. With TupleSections, (a,,b,) means \x y -> (a,x,b,y). Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 23 September 2014 08:32 | To: 'Alexander Berntsen'; Johan Tibell | Cc: ghc-devs at haskell.org | Subject: RE: Permitting trailing commas for record syntax ADT | declarations | | | > have a language extension TrailingCommas (or something) to enable | | > the extension | | For clarification: are you overruling the "do we sneak it in HEAD or | | use pragma(s)"-vote and telling me to do the latter? | | Well, it *is* a language extension, exactly like lots of other language | extensions, isn't it? (E.g. UnicodeSyntax.) What alternative action, | exactly, are you proposing? Why do you propose to treat it differently | to other language extensions? I would be reluctant to simply add it | without any indication; then GHC would accept non-Haskell 2010 programs. | And we have not done that with other extensions. | | Simon | | | | | If we can sneak it into HEAD (this is @ you Johan, too), I suggest | | that someone applies my patches to make import and export lists | | support leading commas (presently they only support trailing commas, | | per the report) -- and following this I can just send a bunch of | | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you | | guys can bikeshed over there about which ones you actually want to | | commit. ;-) | | | | If I am to go down the pragma route, I guess I can make a | | RudundantCommas pragma or something like that, that implements | | trailing commas for imports/exports, and leading/trailing commas for | | the suggestions in this thread. | | | | I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to | | the pragma route either. | | - -- | | Alexander | | alexander at plaimi.net | | https://secure.plaimi.net/~alexander | | -----BEGIN PGP SIGNATURE----- | | Version: GnuPG v2 | | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | | | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR | | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 | | =FfHX | | -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Sep 23 08:55:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Sep 2014 08:55:18 +0000 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54212194.3070300@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212194.3070300@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22229BCB@DB3PRD3001MB020.064d.mgd.msft.net> | presently), whilst requiring a pragma means either making the parser | code really messy "everywhere" there's a comma, or having lots of | duplication there. I don't understand this at all. The standard way is simply to parse the comma(s) always, record the presence of trailing comma(s) in the syntax tree, and then complain/reject in the renamer if the extension is not enabled. That does not make the parser really messy anywhere, I think. You might want a new HsSyn data type for "list with possible leading or trailing commas": data HsCommadList a = HCL Int -- Number of leading commas [a] Int -- Number of trailing commas Simon | | And giving it some thought, I'd argue for going more or less the same | route with regards to patches for a pragma. I.e. add an initial patch | that adds the pragma itself & leading commas for imports/exports, and | then submit a bunch of small commits to augment the pragma to | phabricator, and update the Wiki accordingly. | | | In any event, I'll have to get everything working, so you'll have | plenty of time meanwhile to decide on this issue. | - -- | Alexander | alexander at plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhIZQACgkQRtClrXBQc7V2AwD/SkAHL0fIXhP3DDmI0i7IipeJ | 8Z1JT0k8YqyssJtq6YgBAIB4betQXTHMDt0IGu+OLty6A6iGp2WZQ4kRNlx1lVWa | =1xbA | -----END PGP SIGNATURE----- From alexander at plaimi.net Tue Sep 23 09:00:36 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 23 Sep 2014 11:00:36 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22229BCB@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212194.3070300@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BCB@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <542136B4.2000903@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 See the diff/excerpt below. If it were a pragma, I think this might get ugly quick (consider that this patch only adds leading/trailing commas for record declarations). If you think I should be changing things elsewhere/employing a different approach, please let me know. This was just the place that seemed most relevant to me. diff --git a/compiler/parser/Parser.y.pp b/compiler/parser/Parser.y.pp index fcc21e1..a9267bb 100644 - --- a/compiler/parser/Parser.y.pp +++ b/compiler/parser/Parser.y.pp @@ -1370,7 +1370,7 @@ constr_stuff :: { Located (Located RdrName, HsConDeclDetails RdrName) } | btype conop btype { LL ($2, InfixCon $1 $3) } fielddecls :: { [ConDeclField RdrName] } - - : {- empty -} { [] } + : ',' fielddecls1 { $2 } | fielddecls1 { $1 } fielddecls1 :: { [ConDeclField RdrName] } @@ -1378,6 +1378,7 @@ fielddecls1 :: { [ConDeclField RdrName] } { [ addFieldDoc f $4 | f <- $1 ] ++ addFieldDocs $5 $2 } -- This adds the doc $4 to each field separately | fielddecl { $1 } + | {- empty -} { [] } fielddecl :: { [ConDeclField RdrName] } -- A list because of f,g :: Int : maybe_docnext sig_vars '::' ctype maybe_docprev { [ ConDeclField fld $4 ($1 `mplus` $5) - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQhNrQACgkQRtClrXBQc7UfPQD/ThiruhidjdSHLBHz/cryR30V l6SOdJ1ToExAE0Uv1JcA/RmkMOgi69JnfGrM0Fo6JLyXOIekjyuKLnA4Nm6ASQFk =P5W7 -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Sep 23 10:29:56 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 23 Sep 2014 10:29:56 +0000 Subject: user001 failure Message-ID: <618BE556AADD624C9C918AA5D5911BEF22229D9C@DB3PRD3001MB020.064d.mgd.msft.net> I'm getting a testsuite failure on Linux ../../libraries/unix/tests user001 [bad stdout] (normal) The error message is below. Does anyone have any ideas? Simon Actual stdout output differs from expected: --- ../../libraries/unix/tests/user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ../../libraries/unix/tests/user001.run.stdout 2014-09-23 11:06:06.300082329 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Sep 23 10:57:20 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 23 Sep 2014 12:57:20 +0200 Subject: user001 failure In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22229D9C@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF22229D9C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: > > I?m getting a testsuite failure on Linux > > ../../libraries/unix/tests user001 [bad stdout] (normal) > > > > The error message is below. Does anyone have any ideas? > ezyang reported the same problem, see: https://ghc.haskell.org/trac/ghc/ticket/1487 Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Sep 23 16:47:01 2014 From: david.feuer at gmail.com (David Feuer) Date: Tue, 23 Sep 2014 12:47:01 -0400 Subject: ghc-devs Digest, Vol 133, Issue 40 In-Reply-To: References: Message-ID: Simon Peyton Jones wrote: > anywhere, I think. You might want a new HsSyn data type for "list with > possible leading or trailing commas": > > data HsCommadList a > = HCL > Int -- Number of leading commas > [a] > Int -- Number of trailing commas > If we're going to go to the trouble of supporting extra leading and trailing commas, why not also support extra commas in the middle? That way, #include "theseexports" , #include "thoseexports" doesn't have to worry about how these and those exports are listed. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Sep 23 18:57:10 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Sep 2014 20:57:10 +0200 Subject: GHC AST Annotations In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221F4F10@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I have created https://ghc.haskell.org/trac/ghc/ticket/9628 for this, and have decided to first tackle adding a type parameter to the entire AST, so that tool writers can add custom information as required. My first stab at this is to do is as follows ``` data HsModule r name = HsModule { ann :: r, -- ^ Annotation for external tool writers hsmodName :: Maybe (Located ModuleName), -- ^ @Nothing@: \"module X where\" is omitted (in which case the next -- field is Nothing too) hsmodExports :: Maybe [LIE name], .... ``` Salient points 1. It comes as the first type parameter, and is called r 2. It gets added as the first field of the syntax element 3. It is always called ann Before undertaking this particular change, I would appreciate some feedback. Regards Alan On Thu, Aug 28, 2014 at 8:34 PM, Alan & Kim Zimmerman wrote: > This does have the advantage of being explicit. I modelled the initial > proposal on HSE as a proven solution, and I think that they were trying to > keep it non-invasive, to allow both an annotated and non-annoted AST. > > I thiink the key question is whether it is acceptable to sprinkle this > kind of information throughout the AST. For someone interested in > source-to-source conversions (like me) this is great, others may find it > intrusive. > > The other question, which is probably orthogonal to this, is whether we > want the annotation to be a parameter to the AST, which allows it to be > overridden by various tools for various purposes, or fixed as in Richard's > suggestion. > > A parameterised annotation allows the annotations to be manipulated via > something like for HSE: > > -- |AST nodes are annotated, and this class allows manipulation of the > annotations. > class Functor ast => Annotated ast where > > -- |Retrieve the annotation of an AST node. > ann :: ast l -> l > > -- |Change the annotation of an AST node. Note that only the annotation > of the node itself is affected, and not > -- the annotations of any child nodes. if all nodes in the AST tree are > to be affected, use fmap. > amap :: (l -> l) -> ast l -> ast l > > Alan > > > On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg > wrote: > >> For what it's worth, my thought is not to use SrcSpanInfo (which, to me, >> is the wrong way to slice the abstraction) but instead to add SrcSpan >> fields to the relevant nodes. For example: >> >> | HsDo SrcSpan -- of the word "do" >> BlockSrcSpans >> (HsStmtContext Name) -- The parameterisation is >> unimportant >> -- because in this context we never >> use >> -- the PatGuard or ParStmt variant >> [ExprLStmt id] -- "do":one or more stmts >> PostTcType -- Type of the whole expression >> >> ... >> >> data BlockSrcSpans = LayoutBlock Int -- the parameter is the indentation >> level >> ... -- stuff to track the appearance of >> any semicolons >> | BracesBlock ... -- stuff to track the braces and >> semicolons >> >> >> The way I understand it, the SrcSpanInfo proposal means that we would >> have lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I >> think. >> >> Popping up a level, I do support the idea of including this info in the >> AST. >> >> Richard >> >> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones >> wrote: >> >> > In general I?m fine with this direction of travel. Some specifics: >> > >> > ? You?d have to be careful to document, for every data >> constructor in HsSyn, what the association between the [SrcSpan] in the >> SrcSpanInfo and the ?sub-entities? >> > ? Many of the sub-entities will have their own SrcSpanInfo >> wrapped around them, so there?s some unhelpful duplication. Maybe you only >> want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities (like the >> syntactic keywords) that do not show up as children in the syntax tree? >> > Anyway do by all means create a GHC Trac wiki page to describe your >> proposed design, concretely. >> > >> > Simon >> > >> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan >> & Kim Zimmerman >> > Sent: 28 August 2014 15:00 >> > To: ghc-devs at haskell.org >> > Subject: GHC AST Annotations >> > >> > Now that the landmines have hopefully been cleared from the AST via [1] >> I would like to propose changing the location information in the AST. >> > >> > Right now the locations of syntactic markers such as do/let/where/in/of >> in the source are discarded from the AST, although they are retained in the >> rich token stream. >> > >> > The haskell-src-exts package deals with this by means of using the >> SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC >> Located type but also has a list of SrcSpan s for the syntactic markers, >> depending on the particular AST fragment being annotated. >> > >> > In addition, the annotation type is provided as a parameter to the AST, >> so that it can be changed as required, see [3]. >> > >> > The motivation for this change is then >> > >> > 1. Simplify the roundtripping and modification of source by explicitly >> capturing the missing location information for the syntactic markers. >> > >> > 2. Allow the annotation to be a parameter so that it can be replaced >> with a different one in tools, for example HaRe would include the tokens >> for the AST fragment leaves. >> > >> > 3. Aim for some level compatibility with haskell-src-exts so that tools >> developed for it could be easily ported to GHC, for example exactprint [4]. >> > >> > >> > >> > I would like feedback as to whether this would be acceptable, or if the >> same goals should be achieved a different way. >> > >> > >> > >> > Regards >> > >> > Alan >> > >> > >> > >> > >> > [1] https://phabricator.haskell.org/D157 >> > >> > [2] >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-SrcLoc.html#t:SrcSpanInfo >> > >> > [3] >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-Syntax.html#t:Annotated >> > >> > [4] >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-ExactPrint.html#v:exactPrint >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Sep 24 05:35:13 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 24 Sep 2014 01:35:13 -0400 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <542136B4.2000903@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <54212194.3070300@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BCB@DB3PRD3001MB020.064d.mgd.msft.net> <542136B4.2000903@plaimi.net> Message-ID: i think this should be behind a pragma, On Tue, Sep 23, 2014 at 5:00 AM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > See the diff/excerpt below. If it were a pragma, I think this might get > ugly quick (consider that this patch only adds leading/trailing commas > for record declarations). > > If you think I should be changing things elsewhere/employing a different > approach, please let me know. This was just the place that seemed most > relevant to me. > > > diff --git a/compiler/parser/Parser.y.pp b/compiler/parser/Parser.y.pp > index fcc21e1..a9267bb 100644 > - --- a/compiler/parser/Parser.y.pp > +++ b/compiler/parser/Parser.y.pp > @@ -1370,7 +1370,7 @@ constr_stuff :: { Located (Located RdrName, > HsConDeclDetails RdrName) } > | btype conop btype { LL ($2, InfixCon $1 $3) } > > fielddecls :: { [ConDeclField RdrName] } > - - : {- empty -} { [] } > + : ',' fielddecls1 { $2 } > | fielddecls1 { $1 } > > fielddecls1 :: { [ConDeclField RdrName] } > @@ -1378,6 +1378,7 @@ fielddecls1 :: { [ConDeclField RdrName] } > { [ addFieldDoc f $4 | f <- $1 ] ++ addFieldDocs $5 > $2 } > -- This adds the doc $4 to each field > separately > | fielddecl { $1 } > + | {- empty -} { [] } > > fielddecl :: { [ConDeclField RdrName] } -- A list because of f,g :: > Int > : maybe_docnext sig_vars '::' ctype maybe_docprev { [ > ConDeclField fld $4 ($1 `mplus` $5) > > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQhNrQACgkQRtClrXBQc7UfPQD/ThiruhidjdSHLBHz/cryR30V > l6SOdJ1ToExAE0Uv1JcA/RmkMOgi69JnfGrM0Fo6JLyXOIekjyuKLnA4Nm6ASQFk > =P5W7 > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Sep 24 06:50:22 2014 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 24 Sep 2014 02:50:22 -0400 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'm personally of the "it should be a language extension like everything else" mindset. Sure, it is a pain, but then so is working with EmptyCase, TupleSections, DoRec, EmptyDataDecls, ImplicitParams, KindSignatures, MultiWayIf, TypeOperators, UnicodeSyntax, etc. All of which just make a few more programs compile in the same sense, and fit into the gaps in the existing grammar. The conflict with TupleSections came up the last time this was proposed. If we limit it to record-like notions, and import/export lists, then we don't have to deal with conflicts with TupleSections and while it is inconsistent to have tuples behave differently, than other comma-separated lists, I'd really rather retain tuple sections, which I use somewhat heavily, than lose them to mindless uniformity over how we handle comma-separated lists. I use TupleSections a fair bit, whereas I've adopted prefixed comma-lists in Haskell to avoid the need for an extension like this one, so it'd be quite a shift in my programming style to get to where this helps me. The one place I'd really want something like this proposal is for the first line of my export list, where adopting the prefixed ',' convention + haddock sections makes for an annoying visual asymmetry. -Edward On Tue, Sep 23, 2014 at 4:55 AM, Simon Peyton Jones wrote: > PS I have to admit that GHC already fails to adhere to H-2010 by accepting > trailing commas in module import lists, *without* a language extension. > That is naughty, but I suppose it is a foot in the door. What to others > think? > > Incidentally, trailing commas in tuples have quite a different meaning. > With TupleSections, (a,,b,) means \x y -> (a,x,b,y). > > Simon > > | -----Original Message----- > | From: Simon Peyton Jones > | Sent: 23 September 2014 08:32 > | To: 'Alexander Berntsen'; Johan Tibell > | Cc: ghc-devs at haskell.org > | Subject: RE: Permitting trailing commas for record syntax ADT > | declarations > | > | | > have a language extension TrailingCommas (or something) to enable > | | > the extension > | | For clarification: are you overruling the "do we sneak it in HEAD or > | | use pragma(s)"-vote and telling me to do the latter? > | > | Well, it *is* a language extension, exactly like lots of other language > | extensions, isn't it? (E.g. UnicodeSyntax.) What alternative action, > | exactly, are you proposing? Why do you propose to treat it differently > | to other language extensions? I would be reluctant to simply add it > | without any indication; then GHC would accept non-Haskell 2010 programs. > | And we have not done that with other extensions. > | > | Simon > | > | | > | | If we can sneak it into HEAD (this is @ you Johan, too), I suggest > | | that someone applies my patches to make import and export lists > | | support leading commas (presently they only support trailing commas, > | | per the report) -- and following this I can just send a bunch of > | | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > | | guys can bikeshed over there about which ones you actually want to > | | commit. ;-) > | | > | | If I am to go down the pragma route, I guess I can make a > | | RudundantCommas pragma or something like that, that implements > | | trailing commas for imports/exports, and leading/trailing commas for > | | the suggestions in this thread. > | | > | | I'm +1 on the GHC HEAD route, but I'm not exactly violently opposed to > | | the pragma route either. > | | - -- > | | Alexander > | | alexander at plaimi.net > | | https://secure.plaimi.net/~alexander > | | -----BEGIN PGP SIGNATURE----- > | | Version: GnuPG v2 > | | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > | | > | | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR > | | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 > | | =FfHX > | | -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Wed Sep 24 07:13:11 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 24 Sep 2014 09:13:11 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20140924071311.GA2213@machine> On Wed, Sep 24, 2014 at 02:50:22AM -0400, Edward Kmett wrote: > .. whereas I've adopted prefixed comma-lists in Haskell to avoid the > need for an extension like this one, so it'd be quite a shift in my > programming style to get to where this helps me. That also lets me somehow question the whole proposal if you can get rid of most problems by just changing your coding style: module A ( a , b , c ) where ... data A = A { a :: Int , b :: Int , c :: Int } abc = [ a , b , c ] Every such change in ghc has a cost for the whole haskell tool chain, and if such change isn't even indicated by an extension, then it will be even more "fun" for all the haskell tool developers handling this. Greetings, Daniel From jan.stolarek at p.lodz.pl Wed Sep 24 07:40:21 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 24 Sep 2014 09:40:21 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <20140924071311.GA2213@machine> References: <54201379.7050307@plaimi.net> <20140924071311.GA2213@machine> Message-ID: <201409240940.21244.jan.stolarek@p.lodz.pl> > That also lets me somehow question the whole proposal if you can get > rid of most problems by just changing your coding style: > > module A > ( a > , b > , c > ) where ... > > data A = A > { a :: Int > , b :: Int > , c :: Int > } > > abc = [ a > , b > , c > ] During hacking sessions I often find myself in the need of commenting out the first import /record field/list element. With the proposed change I can just: ? ?module A ? ? ? ( --a ? ? ? , b ? ? ? , c ? ? ? ) where ... ? ?data A = A ? ? ? { --a :: Int ? ? ? , b :: Int ? ? ? , c :: Int ? ? ? } ? ?abc = [ --a ? ? ? ? ?, b ? ? ? ? ?, c ? ? ? ? ?] As things are now I am forced to edit the second line as well. (And when I'm uncommenting things I need to edit the second line again). This is mostly irritating and that's why I think implementing this proposal will be a Good Thing. Janek From hvriedel at gmail.com Wed Sep 24 07:41:54 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 24 Sep 2014 09:41:54 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: (Edward Kmett's message of "Wed, 24 Sep 2014 02:50:22 -0400") References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87mw9po471.fsf@gmail.com> On 2014-09-24 at 08:50:22 +0200, Edward Kmett wrote: > I'm personally of the "it should be a language extension like everything > else" mindset. Me too. Mostly for being able to have more useful error messages with older GHCs and other Haskell parsers. Because if it's a lang-ext pragma, you have to specify it somewhere explicitly ({-# LANGUAGE .. #-} and/or {other,default}-extenions in the cabal file), and if the parser used doesn't know that extension you get a more useful hint pointing you directly at your problem if you throw spurious-commas at a Haskell parser which doesn't support that extension (yet), or with Cabal involved, you'd even get a error message that the current compiler doesn't support that extension. From abela at chalmers.se Wed Sep 24 08:48:40 2014 From: abela at chalmers.se (Andreas Abel) Date: Wed, 24 Sep 2014 10:48:40 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54228568.9060901@chalmers.se> I agree with Edward that TupleSections are too useful to trade for more convenience to write large tuples on the *expression* level. (If you habitually write write large tuple expressions instead of using records, you should revisit your coding style, seriously!) However, I see no problem to allow extra commas in *administrative* tuples like in import/export lists. Thus, I see no problem if these two kinds of tuples adhere to different syntax rules. In previous discussions, there was a caveat raised that extra commata in lists and tuples mean something else. [,a,b,] is [a,b] (,a,b,) is a tuple section However, I never felt like having list sections would see abundant usage. Thus, this discrepancy is ok, imho. Cheers, Andreas On 24.09.2014 08:50, Edward Kmett wrote: > I'm personally of the "it should be a language extension like everything > else" mindset. Sure, it is a pain, but then so is working with > EmptyCase, TupleSections, DoRec, EmptyDataDecls, ImplicitParams, > KindSignatures, MultiWayIf, TypeOperators, UnicodeSyntax, etc. All of > which just make a few more programs compile in the same sense, and fit > into the gaps in the existing grammar. > > The conflict with TupleSections came up the last time this was proposed. > > If we limit it to record-like notions, and import/export lists, then we > don't have to deal with conflicts with TupleSections and while it is > inconsistent to have tuples behave differently, than other > comma-separated lists, I'd really rather retain tuple sections, which I > use somewhat heavily, than lose them to mindless uniformity over how we > handle comma-separated lists. > > I use TupleSections a fair bit, whereas I've adopted prefixed > comma-lists in Haskell to avoid the need for an extension like this one, > so it'd be quite a shift in my programming style to get to where this > helps me. The one place I'd really want something like this proposal is > for the first line of my export list, where adopting the prefixed ',' > convention + haddock sections makes for an annoying visual asymmetry. > > -Edward > > On Tue, Sep 23, 2014 at 4:55 AM, Simon Peyton Jones > > wrote: > > PS I have to admit that GHC already fails to adhere to H-2010 by > accepting trailing commas in module import lists, *without* a > language extension. That is naughty, but I suppose it is a foot in > the door. What to others think? > > Incidentally, trailing commas in tuples have quite a different > meaning. With TupleSections, (a,,b,) means \x y -> (a,x,b,y). > > Simon > > | -----Original Message----- > | From: Simon Peyton Jones > | Sent: 23 September 2014 08:32 > | To: 'Alexander Berntsen'; Johan Tibell > | Cc: ghc-devs at haskell.org > | Subject: RE: Permitting trailing commas for record syntax ADT > | declarations > | > | | > have a language extension TrailingCommas (or something) to enable > | | > the extension > | | For clarification: are you overruling the "do we sneak it in HEAD or > | | use pragma(s)"-vote and telling me to do the latter? > | > | Well, it *is* a language extension, exactly like lots of other > language > | extensions, isn't it? (E.g. UnicodeSyntax.) What alternative action, > | exactly, are you proposing? Why do you propose to treat it > differently > | to other language extensions? I would be reluctant to simply add it > | without any indication; then GHC would accept non-Haskell 2010 > programs. > | And we have not done that with other extensions. > | > | Simon > | > | | > | | If we can sneak it into HEAD (this is @ you Johan, too), I suggest > | | that someone applies my patches to make import and export lists > | | support leading commas (presently they only support trailing commas, > | | per the report) -- and following this I can just send a bunch of > | | "Permit leading/trailing ',' in Foo" patches to Phabricator, and you > | | guys can bikeshed over there about which ones you actually want to > | | commit. ;-) > | | > | | If I am to go down the pragma route, I guess I can make a > | | RudundantCommas pragma or something like that, that implements > | | trailing commas for imports/exports, and leading/trailing commas for > | | the suggestions in this thread. > | | > | | I'm +1 on the GHC HEAD route, but I'm not exactly violently > opposed to > | | the pragma route either. > | | - -- > | | Alexander > | | alexander at plaimi.net > | | https://secure.plaimi.net/~alexander > | | -----BEGIN PGP SIGNATURE----- > | | Version: GnuPG v2 > | | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > | | > | | iF4EAREIAAYFAlQhHRoACgkQRtClrXBQc7U0WAD+Ixdah2pHMoeLiTGQJf0JLwDR > | | I2dxYS7yaKyOHuHcUuEBAKh6RQmmpztz82yt/KCw0n2md3pf4n8yc5tt9s9k3FW3 > | | =FfHX > | | -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From daniel.trstenjak at gmail.com Wed Sep 24 09:52:30 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 24 Sep 2014 11:52:30 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54228568.9060901@chalmers.se> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54228568.9060901@chalmers.se> Message-ID: <20140924095230.GA16128@machine> On Wed, Sep 24, 2014 at 10:48:40AM +0200, Andreas Abel wrote: > [,a,b,] is [a,b] > (,a,b,) is a tuple section > > However, I never felt like having list sections would see abundant > usage. Thus, this discrepancy is ok, imho. I've somehow to disagree, because I like Haskell especially because of its consistency and therefore beauty. I don't mind the extra commata in the import/export lists or records that much, but in a list it would bother me a bit, perhaps because tuple sections just made intuitive sense to me the first time I saw them. Greetings, Daniel From alexander at plaimi.net Wed Sep 24 10:38:06 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 24 Sep 2014 12:38:06 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54229F0E.2040009@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/09/14 08:50, Edward Kmett wrote: > I'm personally of the "it should be a language extension like > everything else" mindset Yeah, I'm going the Pragma route. > If we limit it to record-like notions, and import/export lists, > then we don't have to deal with conflicts with TupleSections and > while it is inconsistent to have tuples behave differently, than > other comma-separated lists, I'd really rather retain tuple > sections, which I use somewhat heavily, than lose them to mindless > uniformity over how we handle comma-separated lists. I'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention. When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line. I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh -----END PGP SIGNATURE----- From thomasmiedema at gmail.com Wed Sep 24 13:21:44 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 24 Sep 2014 15:21:44 +0200 Subject: Building ghc on Windows with msys2 Message-ID: Hello msys2 users, I came across ticket #8842 : "Make sure msys2 builds non emulating binaries". Maybe it is of interest to you, it mentions something about emulation functions being really slow. Please close it if it is not relevant. Cheers, Thomas On Mon, Sep 15, 2014 at 11:33 PM, Simon Peyton Jones wrote: > Thank you! Indeed Neil Mitchell is also acting as ?guinea pig? at the > moment. It would be **great** if together you were able to clean up the > ?how to build on Windows? page, remove out of date or misleading > information, and yes I think we should focus on msys2. > > > > Great stuff > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Gintautas > Miliauskas > *Sent:* 15 September 2014 21:58 > *To:* ghc-devs at haskell.org > *Subject:* Building ghc on Windows with msys2 > > > > Hello, > > > > I have been messing around a little bit with building GHC from source on > Windows, and found the msys2 wikipage > quite > useful, but somewhat outdated. Quite a few steps in those instructions are > no longer necessary and can be omitted. I am working on cleaning up that > wikipage right now and should be done in a day or two. > > > > I've found a recent email > in > the middle of updating the wikipage about other people planning to do the > same, so I thought I'd shoot an email to make sure that work is not being > duplicated. > > > > msys2 seems to be in good shape and should probably be promoted to the > primary suggested method to build ghc on Windows. Let's look into that once > the new build instructions have been proofread and verified. > > > > Best regards, > > -- > Gintautas Miliauskas > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Sep 24 20:37:59 2014 From: david.feuer at gmail.com (David Feuer) Date: Wed, 24 Sep 2014 16:37:59 -0400 Subject: FoldrW/buildW issues In-Reply-To: <1410546936.27344.2.camel@joachim-breitner.de> References: <1410546936.27344.2.camel@joachim-breitner.de> Message-ID: On Sep 12, 2014 2:35 PM, "Joachim Breitner" wrote: > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > function, semantically the identity, but tell the compiler not to share > the result of the computation. Using that in the definition of > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > more reliable. I need to investigate if that solves the sumConcatInits > problem. One nice thing about this idea (which sounds like it must be related to the "state hack", but is more explicit) is that it presumably applies also to similar situations in the State and ST monads, when a state transformer is only used once. Could you explain, perhaps, what compiler transformation this enables, and how you implemented it? It would be nice if the compiler could figure this out for itself, but I'm sure that's much too big a project for 7.10, whereas making sure foldl, scanl, mapAccumL, foldM, sum, etc., work really reliably seems important. And yes, I do think such a thing would probably work for scanl and such, assuming GHC's analysis can use the information properly?they're just state-transforming list producers. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Sep 24 20:56:30 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 24 Sep 2014 22:56:30 +0200 Subject: FoldrW/buildW issues In-Reply-To: References: <1410546936.27344.2.camel@joachim-breitner.de> Message-ID: <1411592190.2532.4.camel@joachim-breitner.de> Hi, Am Mittwoch, den 24.09.2014, 16:37 -0400 schrieb David Feuer: > On Sep 12, 2014 2:35 PM, "Joachim Breitner" > wrote: > > I once experimented with a magic "oneShot :: (a -> b) -> (a -> b)" > > function, semantically the identity, but tell the compiler not to > share > > the result of the computation. Using that in the definition of > > foldl-as-foldr, one can get the same effect as Call Arity, but a bit > > more reliable. I need to investigate if that solves the > sumConcatInits > > problem. > > One nice thing about this idea (which sounds like it must be related > to the "state hack", but is more explicit) is that it presumably > applies also to similar situations in the State and ST monads, when a > state transformer is only used once. Could you explain, perhaps, what > compiler transformation this enables, and how you implemented it? I guess it is used in various places, and I woudn?t know all of them. The one that I was aiming for was is this one case x of True -> z False -> \s(one-shot). e to \s(one-shot) . case x of True -> z s False -> e explained in Note [Combining case branches] at https://github.com/ghc/ghc/blob/master/compiler/coreSyn/CoreArity.lhs#L671 The implementation is attached to my previous mail. > It would be nice if the compiler could figure this out for itself, Well, that?s what I thought, and CallArity is what I came up with :-) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From abela at chalmers.se Wed Sep 24 21:27:39 2014 From: abela at chalmers.se (Andreas Abel) Date: Wed, 24 Sep 2014 23:27:39 +0200 Subject: Leading/trailing commata [Re: ghc-devs Digest, Vol 133, Issue 40] In-Reply-To: References: Message-ID: <5423374B.6040604@chalmers.se> Yes, I think extra commas in the middle could be useful as well... On 23.09.2014 18:47, David Feuer wrote: > Simon Peyton Jones wrote: > > anywhere, I think. You might want a new HsSyn data type for "list > with possible leading or trailing commas": > > data HsCommadList a > = HCL > Int -- Number of leading commas > [a] > Int -- Number of trailing commas > > > If we're going to go to the trouble of supporting extra leading and > trailing commas, why not also support extra commas in the middle? That way, > > #include "theseexports" > , > #include "thoseexports" > > doesn't have to worry about how these and those exports are listed. > > David > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From iavor.diatchki at gmail.com Thu Sep 25 07:13:42 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 25 Sep 2014 09:13:42 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <54229F0E.2040009@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> Message-ID: Hello, My 2c: I don't think that supporting trailing commas is worth the additional complexity to the compiler and the language. I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners. -Iavor On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 24/09/14 08:50, Edward Kmett wrote: > > I'm personally of the "it should be a language extension like > > everything else" mindset > Yeah, I'm going the Pragma route. > > > If we limit it to record-like notions, and import/export lists, > > then we don't have to deal with conflicts with TupleSections and > > while it is inconsistent to have tuples behave differently, than > > other comma-separated lists, I'd really rather retain tuple > > sections, which I use somewhat heavily, than lose them to mindless > > uniformity over how we handle comma-separated lists. > I'm implementing it for things where I 100% subjectively feel it makes > sense. This does *not* include tuples, for the reason you mention. > > When I get the time, I will make a Wiki page outlining what I'm changing > and my motivation for doing it. We can then have a discussion about > where to draw the line. > > > I need to figure out a more elegant solution than tweaking the parser > for each individual item. If someone knows their way around this code, > please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact > info. I'll be busy today with a haskell workshop, but I plan on > spending the rest of the week on this business. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 > /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe > =l/sh > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Thu Sep 25 07:38:00 2014 From: abela at chalmers.se (Andreas Abel) Date: Thu, 25 Sep 2014 09:38:00 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> Message-ID: <5423C658.3000704@chalmers.se> Ah, just look at all these brace-and-semicolon languages, and how they thrive, and how many beginners have mastered them... #include int main () { ; /* It is sunny today, so I am in the mood for a leading semi. */ ; /* Still not in the mood to start work. */ int i; ; for (i=0; i < 5; i++) { printf("%d", i); }; /* Mmh, do you need to put a semi after the closing brace? */ /* Let's put one, just to be sure. */ /* TODO: more code */; } import Data.Foldable (forM_) main = do { ; -- It is sunny today, so I am in the mood for a leading semi. ; -- Still not in the mood to start work. ; forM_ [0..4] $ \ i -> do { print i ;} ;} -- Mmh, do you need to put a semi befor the closing brace? -- Let's put one, just to be sure. On 25.09.2014 09:13, Iavor Diatchki wrote: > Hello, > > My 2c: I don't think that supporting trailing commas is worth the > additional complexity to the compiler and the language. > > I work with Haskell on a daily basis, and I honestly don't think that > this is going to simplify my job in any way. On the other hand, it > seems like it it will make it more complex to write tools that process > Haskell, and to explain the syntax of the language to beginners. > > -Iavor > > > > On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen > > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 24/09/14 08:50, Edward Kmett wrote: > > I'm personally of the "it should be a language extension like > > everything else" mindset > Yeah, I'm going the Pragma route. > > > If we limit it to record-like notions, and import/export lists, > > then we don't have to deal with conflicts with TupleSections and > > while it is inconsistent to have tuples behave differently, than > > other comma-separated lists, I'd really rather retain tuple > > sections, which I use somewhat heavily, than lose them to mindless > > uniformity over how we handle comma-separated lists. > I'm implementing it for things where I 100% subjectively feel it makes > sense. This does *not* include tuples, for the reason you mention. > > When I get the time, I will make a Wiki page outlining what I'm changing > and my motivation for doing it. We can then have a discussion about > where to draw the line. > > > I need to figure out a more elegant solution than tweaking the parser > for each individual item. If someone knows their way around this code, > please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact > info. I'll be busy today with a haskell workshop, but I plan on > spending the rest of the week on this business. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 > /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe > =l/sh > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From alexander at plaimi.net Thu Sep 25 08:10:31 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 25 Sep 2014 10:10:31 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> Message-ID: <5423CDF7.9040808@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/09/14 09:13, Iavor Diatchki wrote: > I work with Haskell on a daily basis, and I honestly don't think > that this is going to simplify my job in any way. I too work with Haskell every day, and I *know* this will make my job easier. > On the other hand, it seems like it it will make it more complex > to write tools that process Haskell, and to explain the syntax of > the language to beginners. Not sure how it will make tools more complicated as a pragma. & they can always just not support the pragma if it's that hard. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQjzfcACgkQRtClrXBQc7WO8wEAndhjRsCkVXp2mJWSW1steQYT 1C9P6pzzntViDQS9tHsA/09GSKO0lHlmU1B5PWKkGkNmiCFV8hJUzTEYAo1363E8 =0Db/ -----END PGP SIGNATURE----- From jan.stolarek at p.lodz.pl Thu Sep 25 08:26:35 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 25 Sep 2014 10:26:35 +0200 Subject: How to build the user guide? Message-ID: <201409251026.35277.jan.stolarek@p.lodz.pl> Is there a way to build the user guide without having to build everything? The wiki [1] suggests cd docs/users_guide make html stage=0 FAST=YES but that doesn't seem to work. Janek [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Docs From erkokl at gmail.com Thu Sep 25 08:28:14 2014 From: erkokl at gmail.com (Levent Erkok) Date: Thu, 25 Sep 2014 01:28:14 -0700 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <5423CDF7.9040808@plaimi.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <5423CDF7.9040808@plaimi.net> Message-ID: I agree with Iavor on this one. I use Haskell professionally as well, and I'm actually quite fond of what it leaves out in terms of both syntax and semantics, as opposed to what it adds. Whether it's pragma protected or not, I just don't see the point of complicating the language with such a seemingly minor feature. Also, as pointed out before, the tuple-sections feature interact badly with this, and the treatment of commas in lists and tuples being different is a source of concern. If it's added, however, it should definitely be pragma protected as I'm pretty sure if I ever have extra commas lying around it's because I inadvertently deleted something or made some other cut-paste error. I'd like GHC to keep telling me about those in perpetuity. -Levent. On Thu, Sep 25, 2014 at 1:10 AM, Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 25/09/14 09:13, Iavor Diatchki wrote: > > I work with Haskell on a daily basis, and I honestly don't think > > that this is going to simplify my job in any way. > I too work with Haskell every day, and I *know* this will make my job > easier. > > > On the other hand, it seems like it it will make it more complex > > to write tools that process Haskell, and to explain the syntax of > > the language to beginners. > Not sure how it will make tools more complicated as a pragma. & they > can always just not support the pragma if it's that hard. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQjzfcACgkQRtClrXBQc7WO8wEAndhjRsCkVXp2mJWSW1steQYT > 1C9P6pzzntViDQS9tHsA/09GSKO0lHlmU1B5PWKkGkNmiCFV8hJUzTEYAo1363E8 > =0Db/ > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Sep 25 08:37:37 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 25 Sep 2014 10:37:37 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <5423CDF7.9040808@plaimi.net> Message-ID: The reason to support trailing commas are entirely related to engineering and not language expressiveness. Having trailing commas means that diff tools and version control systems work better. This is why most languages support them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Sep 25 09:18:01 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 25 Sep 2014 09:18:01 +0000 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> There?s a danger of disappearing into a bikeshed here. I think it?s clear that: ? If we have it at all, ExtraCommas should be a {-# LANGUAGE ExtraCommas #-} extension, like any other. ? ExtraCommas should leave tuples alone (always) Provided there is that LANGUAGE extension, I have no objection to having it in GHC if Alexander wants to implement it. It has low impact, and some people like it a lot. People who don?t like it don?t have to switch on the extension. It?s unclear whether extra commas in literal lists [a,,b,,] should behave like TupleSections or like ExtraCommas. My instinct is the former, because the only difference is round vs square parens. That would suggest continuing to make extra commas illegal in literal lists, for now anyway. That?s a conservative choice, which is usually the side to err on when it?s a toss-up. OK? Simon From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com] Sent: 25 September 2014 08:14 To: Alexander Berntsen Cc: Edward Kmett; Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: Permitting trailing commas for record syntax ADT declarations Hello, My 2c: I don't think that supporting trailing commas is worth the additional complexity to the compiler and the language. I work with Haskell on a daily basis, and I honestly don't think that this is going to simplify my job in any way. On the other hand, it seems like it it will make it more complex to write tools that process Haskell, and to explain the syntax of the language to beginners. -Iavor On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen > wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/09/14 08:50, Edward Kmett wrote: > I'm personally of the "it should be a language extension like > everything else" mindset Yeah, I'm going the Pragma route. > If we limit it to record-like notions, and import/export lists, > then we don't have to deal with conflicts with TupleSections and > while it is inconsistent to have tuples behave differently, than > other comma-separated lists, I'd really rather retain tuple > sections, which I use somewhat heavily, than lose them to mindless > uniformity over how we handle comma-separated lists. I'm implementing it for things where I 100% subjectively feel it makes sense. This does *not* include tuples, for the reason you mention. When I get the time, I will make a Wiki page outlining what I'm changing and my motivation for doing it. We can then have a discussion about where to draw the line. I need to figure out a more elegant solution than tweaking the parser for each individual item. If someone knows their way around this code, please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact info. I'll be busy today with a haskell workshop, but I plan on spending the rest of the week on this business. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe =l/sh -----END PGP SIGNATURE----- _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Sep 25 09:23:47 2014 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 25 Sep 2014 11:23:47 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5423DF23.8070801@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/09/14 11:18, Simon Peyton Jones wrote: > ? If we have it at all, ExtraCommas should be a {-# > LANGUAGE ExtraCommas #-} extension, like any other. > > ? ExtraCommas should leave tuples alone (always) > > OK? These are the core principles of I'm working with/towards. When I have it satisfactory working, and have made up my mind about the details, I will make a Wiki article explaining it all. Thanks to everyone who's voiced their opinion and given me suggestions. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQj3yMACgkQRtClrXBQc7W0lQD9HmCg7dAbT6vP7iKOvYVY/RuQ SM2vetxcRizC+SjhCUoA/A8IaY4PNZqnGTEl42ptX2hPOdx07E2WrSE1T9Kq3TBo =YqQ2 -----END PGP SIGNATURE----- From ezyang at mit.edu Thu Sep 25 09:35:28 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 25 Sep 2014 02:35:28 -0700 Subject: How to build the user guide? In-Reply-To: <201409251026.35277.jan.stolarek@p.lodz.pl> References: <201409251026.35277.jan.stolarek@p.lodz.pl> Message-ID: <1411637659-sup-3359@sabre> Maybe try BUILD_DOCBOOK_HTML=YES Edward Excerpts from Jan Stolarek's message of 2014-09-25 01:26:35 -0700: > Is there a way to build the user guide without having to build everything? The wiki [1] suggests > > cd docs/users_guide > make html stage=0 FAST=YES > > but that doesn't seem to work. > > Janek > > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Docs From johan.tibell at gmail.com Thu Sep 25 10:00:04 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 25 Sep 2014 12:00:04 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Sounds good to me. On Thu, Sep 25, 2014 at 11:18 AM, Simon Peyton Jones wrote: > There?s a danger of disappearing into a bikeshed here. I think it?s > clear that: > > ? If we have it at all, ExtraCommas should be a {-# LANGUAGE > ExtraCommas #-} extension, like any other. > > ? ExtraCommas should leave tuples alone (always) > > > > Provided there is that LANGUAGE extension, I have no objection to having > it in GHC if Alexander wants to implement it. It has low impact, and some > people like it a lot. People who don?t like it don?t have to switch on the > extension. > > > > It?s unclear whether extra commas in literal lists [a,,b,,] should behave > like TupleSections or like ExtraCommas. My instinct is the former, because > the only difference is round vs square parens. That would suggest > continuing to make extra commas illegal in literal lists, for now anyway. > That?s a conservative choice, which is usually the side to err on when it?s > a toss-up. > > > > OK? > > > > Simon > > > > > > > > *From:* Iavor Diatchki [mailto:iavor.diatchki at gmail.com] > *Sent:* 25 September 2014 08:14 > *To:* Alexander Berntsen > *Cc:* Edward Kmett; Simon Peyton Jones; ghc-devs at haskell.org > *Subject:* Re: Permitting trailing commas for record syntax ADT > declarations > > > > Hello, > > > > My 2c: I don't think that supporting trailing commas is worth the > additional complexity to the compiler and the language. > > > > I work with Haskell on a daily basis, and I honestly don't think that this > is going to simplify my job in any way. On the other hand, it seems like > it it will make it more complex to write tools that process Haskell, and to > explain the syntax of the language to beginners. > > > > -Iavor > > > > > > > > On Wed, Sep 24, 2014 at 12:38 PM, Alexander Berntsen > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 24/09/14 08:50, Edward Kmett wrote: > > I'm personally of the "it should be a language extension like > > everything else" mindset > Yeah, I'm going the Pragma route. > > > If we limit it to record-like notions, and import/export lists, > > then we don't have to deal with conflicts with TupleSections and > > while it is inconsistent to have tuples behave differently, than > > other comma-separated lists, I'd really rather retain tuple > > sections, which I use somewhat heavily, than lose them to mindless > > uniformity over how we handle comma-separated lists. > I'm implementing it for things where I 100% subjectively feel it makes > sense. This does *not* include tuples, for the reason you mention. > > When I get the time, I will make a Wiki page outlining what I'm changing > and my motivation for doing it. We can then have a discussion about > where to draw the line. > > > I need to figure out a more elegant solution than tweaking the parser > for each individual item. If someone knows their way around this code, > please talk to me on IRC/SIP/XMPP/whatever. Just email me for contact > info. I'll be busy today with a haskell workshop, but I plan on > spending the rest of the week on this business. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iF4EAREIAAYFAlQinw4ACgkQRtClrXBQc7VL4gD6Ao12HqH1Mjl30n/1Mwlby7W6 > /2+JeUOF9ui959xh1QkBAIdTA6km9gDvgCQ1nBQ5juZFNF79C1Fezk2yEpOvF7Fe > =l/sh > > -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Sep 25 10:03:13 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 25 Sep 2014 12:03:13 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Thu, 25 Sep 2014 09:18:01 +0000") References: <54201379.7050307@plaimi.net> <54201596.6020205@gmail.com> <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87d2ak9fvi.fsf@gmail.com> On 2014-09-25 at 11:18:01 +0200, Simon Peyton Jones wrote: > That would suggest continuing to make extra commas illegal in literal > lists, for now anyway. That?s a conservative choice, which is usually > the side to err on when it?s a toss-up. I'd just like to point out, that lists are something that you may want to tweak regularily in code (while tuple are rather fixed-size entities whose size is extended less frequently) Consider the following JSON example: foo = object [ "key1" .= True, "key2" .= 123, "key3" .= (), ] This is code where I often tend to add/remove lines, and ExtraCommas would greatly reduce the diff-noise, and which I really miss from languages such as Python which allow me to use trailing commas. From daniel.trstenjak at gmail.com Thu Sep 25 11:34:16 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 25 Sep 2014 13:34:16 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <87d2ak9fvi.fsf@gmail.com> References: <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> <87d2ak9fvi.fsf@gmail.com> Message-ID: <20140925113416.GA7340@machine> On Thu, Sep 25, 2014 at 12:03:13PM +0200, Herbert Valerio Riedel wrote: > I'd just like to point out, that lists are something that you may want > to tweak regularily in code (while tuple are rather fixed-size entities whose > size is extended less frequently) > > Consider the following JSON example: > > foo = object [ > "key1" .= True, > "key2" .= 123, > "key3" .= (), > ] > > This is code where I often tend to add/remove lines, and ExtraCommas > would greatly reduce the diff-noise, and which I really miss from > languages such as Python which allow me to use trailing commas. One compromise could be, that additional commatas in literal lists are only allowed at the beginning and at the end. Then your use case would work and also something like: abc = [ -- a , a -- b , b -- c , c ] I think that are the main uses of additional commatas in literal lists and I can't see that someone really wants a list literal like '[,3,,4,]', so wrongly reading it as a list section shouldn't be an issue. Greetings, Daniel From hvriedel at gmail.com Thu Sep 25 12:06:56 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 25 Sep 2014 14:06:56 +0200 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <20140925113416.GA7340@machine> (Daniel Trstenjak's message of "Thu, 25 Sep 2014 13:34:16 +0200") References: <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> <87d2ak9fvi.fsf@gmail.com> <20140925113416.GA7340@machine> Message-ID: <877g0raopr.fsf@gmail.com> On 2014-09-25 at 13:34:16 +0200, Daniel Trstenjak wrote: [...] > One compromise could be, that additional commatas in literal lists > are only allowed at the beginning and at the end. ...another idea could be to make it a separate Pragma (e.g. ExtraCommasLists) if there's a chance of ListSections (which would conflict with this) becoming a reality. > Then your use case would work and also something like: > > abc = [ > -- a > , a > -- b > , b > -- c > , c > ] I'd probably prefer leading-comma over trailing-comma style anyway (as I've grown to like it over the years). > I think that are the main uses of additional commatas in literal lists > and I can't see that someone really wants a list literal like '[,3,,4,]', > so wrongly reading it as a list section shouldn't be an issue. Yeah, I don't care much about extra middle-commas either. Personally, I'd be already happy with just trailing & leading extra-comma support. From p.k.f.holzenspies at utwente.nl Fri Sep 26 08:07:48 2014 From: p.k.f.holzenspies at utwente.nl (p.k.f.holzenspies at utwente.nl) Date: Fri, 26 Sep 2014 08:07:48 +0000 Subject: GHC AST Annotations In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF221F4F10@DB3PRD3001MB020.064d.mgd.msft.net> , Message-ID: <07afbc8cbbc4416da4f7e4907d7eba83@EXMBX31.ad.utwente.nl> Dear Alan, Nice going and thanks for undertaking yet another useful AST transformation! A few thoughts (do with them as you see fit): - Always called "ann"; doesn't this require OverloadedRecordFields? You're in danger of delaying your modification (scheduled to land in 7.10). Other than that, as before, from a design perspective: yes please. - In terms of presentation/comments; when I first started looking at (i.e. traversing, selectively printing etc.) the AST, I was always really annoyed that every child in the tree has one extra step of indirection, due to the location annotations being "L loc thing", as opposed to a loc-field as part of the thing. I would simply call it annotation (no talk of external tool writers). In time, I hope GHC-annotations also move to that field. Regards, Phili?p ________________________________ From: Alan & Kim Zimmerman Sent: 23 September 2014 20:57 To: Richard Eisenberg Cc: ghc-devs at haskell.org Subject: Re: GHC AST Annotations I have created https://ghc.haskell.org/trac/ghc/ticket/9628 for this, and have decided to first tackle adding a type parameter to the entire AST, so that tool writers can add custom information as required. My first stab at this is to do is as follows ``` data HsModule r name = HsModule { ann :: r, -- ^ Annotation for external tool writers hsmodName :: Maybe (Located ModuleName), -- ^ @Nothing@: \"module X where\" is omitted (in which case the next -- field is Nothing too) hsmodExports :: Maybe [LIE name], .... ``` Salient points 1. It comes as the first type parameter, and is called r 2. It gets added as the first field of the syntax element 3. It is always called ann Before undertaking this particular change, I would appreciate some feedback. Regards Alan On Thu, Aug 28, 2014 at 8:34 PM, Alan & Kim Zimmerman > wrote: This does have the advantage of being explicit. I modelled the initial proposal on HSE as a proven solution, and I think that they were trying to keep it non-invasive, to allow both an annotated and non-annoted AST. I thiink the key question is whether it is acceptable to sprinkle this kind of information throughout the AST. For someone interested in source-to-source conversions (like me) this is great, others may find it intrusive. The other question, which is probably orthogonal to this, is whether we want the annotation to be a parameter to the AST, which allows it to be overridden by various tools for various purposes, or fixed as in Richard's suggestion. A parameterised annotation allows the annotations to be manipulated via something like for HSE: -- |AST nodes are annotated, and this class allows manipulation of the annotations. class Functor ast => Annotated ast where -- |Retrieve the annotation of an AST node. ann :: ast l -> l -- |Change the annotation of an AST node. Note that only the annotation of the node itself is affected, and not -- the annotations of any child nodes. if all nodes in the AST tree are to be affected, use fmap. amap :: (l -> l) -> ast l -> ast l Alan On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg > wrote: For what it's worth, my thought is not to use SrcSpanInfo (which, to me, is the wrong way to slice the abstraction) but instead to add SrcSpan fields to the relevant nodes. For example: | HsDo SrcSpan -- of the word "do" BlockSrcSpans (HsStmtContext Name) -- The parameterisation is unimportant -- because in this context we never use -- the PatGuard or ParStmt variant [ExprLStmt id] -- "do":one or more stmts PostTcType -- Type of the whole expression ... data BlockSrcSpans = LayoutBlock Int -- the parameter is the indentation level ... -- stuff to track the appearance of any semicolons | BracesBlock ... -- stuff to track the braces and semicolons The way I understand it, the SrcSpanInfo proposal means that we would have lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I think. Popping up a level, I do support the idea of including this info in the AST. Richard On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones > wrote: > In general I?m fine with this direction of travel. Some specifics: > > ? You?d have to be careful to document, for every data constructor in HsSyn, what the association between the [SrcSpan] in the SrcSpanInfo and the ?sub-entities? > ? Many of the sub-entities will have their own SrcSpanInfo wrapped around them, so there?s some unhelpful duplication. Maybe you only want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities (like the syntactic keywords) that do not show up as children in the syntax tree? > Anyway do by all means create a GHC Trac wiki page to describe your proposed design, concretely. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman > Sent: 28 August 2014 15:00 > To: ghc-devs at haskell.org > Subject: GHC AST Annotations > > Now that the landmines have hopefully been cleared from the AST via [1] I would like to propose changing the location information in the AST. > > Right now the locations of syntactic markers such as do/let/where/in/of in the source are discarded from the AST, although they are retained in the rich token stream. > > The haskell-src-exts package deals with this by means of using the SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC Located type but also has a list of SrcSpan s for the syntactic markers, depending on the particular AST fragment being annotated. > > In addition, the annotation type is provided as a parameter to the AST, so that it can be changed as required, see [3]. > > The motivation for this change is then > > 1. Simplify the roundtripping and modification of source by explicitly capturing the missing location information for the syntactic markers. > > 2. Allow the annotation to be a parameter so that it can be replaced with a different one in tools, for example HaRe would include the tokens for the AST fragment leaves. > > 3. Aim for some level compatibility with haskell-src-exts so that tools developed for it could be easily ported to GHC, for example exactprint [4]. > > > > I would like feedback as to whether this would be acceptable, or if the same goals should be achieved a different way. > > > > Regards > > Alan > > > > > [1] https://phabricator.haskell.org/D157 > > [2] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-SrcLoc.html#t:SrcSpanInfo > > [3] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-Syntax.html#t:Annotated > > [4] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-ExactPrint.html#v:exactPrint > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 26 08:30:33 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 Sep 2014 08:30:33 +0000 Subject: GHC AST Annotations In-Reply-To: <07afbc8cbbc4416da4f7e4907d7eba83@EXMBX31.ad.utwente.nl> References: <618BE556AADD624C9C918AA5D5911BEF221F4F10@DB3PRD3001MB020.064d.mgd.msft.net> , <07afbc8cbbc4416da4f7e4907d7eba83@EXMBX31.ad.utwente.nl> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22232A7B@DB3PRD3001MB020.064d.mgd.msft.net> - In terms of presentation/comments; when I first started looking at (i.e. traversing, selectively printing etc.) the AST, I was always really annoyed that every child in the tree has one extra step of indirection, due to the location annotations being "L loc thing", as opposed to a loc-field as part of the thing. I would simply call it annotation (no talk of external tool writers). In time, I hope GHC-annotations also move to that field. Replacing the (L loc thing) story by adding a location field to every single data constructor of HsSyn would be entirely possible. But it would mean adding a lot of extra fields. I don?t have a strong opinion either way, but other clients of the GHC API would be affected. What we can?t do is have both the (L loc thing) and an extra field! - Always called "ann"; doesn't this require OverloadedRecordFields? You're in danger of delaying your modification (scheduled to land in 7.10). Other than that, as before, from a design perspective: yes please. Tiresomely it is indeed the case that (for now anyway) the field would need a different name in each data type. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of p.k.f.holzenspies at utwente.nl Sent: 26 September 2014 09:08 To: alan.zimm at gmail.com; eir at cis.upenn.edu Cc: ghc-devs at haskell.org Subject: RE: GHC AST Annotations Dear Alan, Nice going and thanks for undertaking yet another useful AST transformation! A few thoughts (do with them as you see fit): - Always called "ann"; doesn't this require OverloadedRecordFields? You're in danger of delaying your modification (scheduled to land in 7.10). Other than that, as before, from a design perspective: yes please. - In terms of presentation/comments; when I first started looking at (i.e. traversing, selectively printing etc.) the AST, I was always really annoyed that every child in the tree has one extra step of indirection, due to the location annotations being "L loc thing", as opposed to a loc-field as part of the thing. I would simply call it annotation (no talk of external tool writers). In time, I hope GHC-annotations also move to that field. Regards, Phili?p ________________________________ From: Alan & Kim Zimmerman > Sent: 23 September 2014 20:57 To: Richard Eisenberg Cc: ghc-devs at haskell.org Subject: Re: GHC AST Annotations I have created https://ghc.haskell.org/trac/ghc/ticket/9628 for this, and have decided to first tackle adding a type parameter to the entire AST, so that tool writers can add custom information as required. My first stab at this is to do is as follows ``` data HsModule r name = HsModule { ann :: r, -- ^ Annotation for external tool writers hsmodName :: Maybe (Located ModuleName), -- ^ @Nothing@: \"module X where\" is omitted (in which case the next -- field is Nothing too) hsmodExports :: Maybe [LIE name], .... ``` Salient points 1. It comes as the first type parameter, and is called r 2. It gets added as the first field of the syntax element 3. It is always called ann Before undertaking this particular change, I would appreciate some feedback. Regards Alan On Thu, Aug 28, 2014 at 8:34 PM, Alan & Kim Zimmerman > wrote: This does have the advantage of being explicit. I modelled the initial proposal on HSE as a proven solution, and I think that they were trying to keep it non-invasive, to allow both an annotated and non-annoted AST. I thiink the key question is whether it is acceptable to sprinkle this kind of information throughout the AST. For someone interested in source-to-source conversions (like me) this is great, others may find it intrusive. The other question, which is probably orthogonal to this, is whether we want the annotation to be a parameter to the AST, which allows it to be overridden by various tools for various purposes, or fixed as in Richard's suggestion. A parameterised annotation allows the annotations to be manipulated via something like for HSE: -- |AST nodes are annotated, and this class allows manipulation of the annotations. class Functor ast => Annotated ast where -- |Retrieve the annotation of an AST node. ann :: ast l -> l -- |Change the annotation of an AST node. Note that only the annotation of the node itself is affected, and not -- the annotations of any child nodes. if all nodes in the AST tree are to be affected, use fmap. amap :: (l -> l) -> ast l -> ast l Alan On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg > wrote: For what it's worth, my thought is not to use SrcSpanInfo (which, to me, is the wrong way to slice the abstraction) but instead to add SrcSpan fields to the relevant nodes. For example: | HsDo SrcSpan -- of the word "do" BlockSrcSpans (HsStmtContext Name) -- The parameterisation is unimportant -- because in this context we never use -- the PatGuard or ParStmt variant [ExprLStmt id] -- "do":one or more stmts PostTcType -- Type of the whole expression ... data BlockSrcSpans = LayoutBlock Int -- the parameter is the indentation level ... -- stuff to track the appearance of any semicolons | BracesBlock ... -- stuff to track the braces and semicolons The way I understand it, the SrcSpanInfo proposal means that we would have lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I think. Popping up a level, I do support the idea of including this info in the AST. Richard On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones > wrote: > In general I?m fine with this direction of travel. Some specifics: > > ? You?d have to be careful to document, for every data constructor in HsSyn, what the association between the [SrcSpan] in the SrcSpanInfo and the ?sub-entities? > ? Many of the sub-entities will have their own SrcSpanInfo wrapped around them, so there?s some unhelpful duplication. Maybe you only want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities (like the syntactic keywords) that do not show up as children in the syntax tree? > Anyway do by all means create a GHC Trac wiki page to describe your proposed design, concretely. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman > Sent: 28 August 2014 15:00 > To: ghc-devs at haskell.org > Subject: GHC AST Annotations > > Now that the landmines have hopefully been cleared from the AST via [1] I would like to propose changing the location information in the AST. > > Right now the locations of syntactic markers such as do/let/where/in/of in the source are discarded from the AST, although they are retained in the rich token stream. > > The haskell-src-exts package deals with this by means of using the SrcSpanInfo data type [2] which contains the SrcSpan as per the current GHC Located type but also has a list of SrcSpan s for the syntactic markers, depending on the particular AST fragment being annotated. > > In addition, the annotation type is provided as a parameter to the AST, so that it can be changed as required, see [3]. > > The motivation for this change is then > > 1. Simplify the roundtripping and modification of source by explicitly capturing the missing location information for the syntactic markers. > > 2. Allow the annotation to be a parameter so that it can be replaced with a different one in tools, for example HaRe would include the tokens for the AST fragment leaves. > > 3. Aim for some level compatibility with haskell-src-exts so that tools developed for it could be easily ported to GHC, for example exactprint [4]. > > > > I would like feedback as to whether this would be acceptable, or if the same goals should be achieved a different way. > > > > Regards > > Alan > > > > > [1] https://phabricator.haskell.org/D157 > > [2] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-SrcLoc.html#t:SrcSpanInfo > > [3] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-Syntax.html#t:Annotated > > [4] http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-Haskell-Exts-Annotated-ExactPrint.html#v:exactPrint > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Sep 26 09:18:21 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 26 Sep 2014 11:18:21 +0200 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <059.3cdf03688f425c2d8dc033d75e81987d@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> <059.3cdf03688f425c2d8dc033d75e81987d@haskell.org> Message-ID: I am trying to avoid having a type parameter for DynFlags, and so far the only thing that needs it is the hooks. I am currently working it through without hooks in DynFlags, and when I have something concrete I will ask againfor suggestions. I just wanted an initial test of the waters to make sure there was no a priori reason not to do it. On Fri, Sep 26, 2014 at 10:09 AM, GHC wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.8.3 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > You'll need to be much more explicit before anyone is likely to venture an > opinion. What is the impact of "managed separately"? What is the > motivation for making a change at all? > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 26 11:37:59 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 Sep 2014 11:37:59 +0000 Subject: Linux failures Message-ID: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> I am getting one persistent failure on Linux: =====> user001(normal) 5 of 29 [0, 0, 0] cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 cd . && ./user001 >user001.run.stdout 2>user001.run.stderr Actual stdout output differs from expected: --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 @@ -3,11 +3,11 @@ getEffectiveUserID: OK getEffectiveGroupID: OK getGroups: OK -getLoginName: OK +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK getAllGroupEntries: OK getUserEntryForID: OK -getUserEntryForName: OK +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) getAllUserEntries: OK *** unexpected failure for user001(normal) This is in libraries/unix/tests. I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 @@ -0,0 +1 @@ +ghc-stage2: ioManagerWakeup: write: Bad file descriptor I don't think these can be caused by my commits, but they should be fixed.... Any offers? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 26 15:46:32 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 Sep 2014 15:46:32 +0000 Subject: ExtraCommas In-Reply-To: <54213FDB.4030204@plaimi.net> References: <542139EA.1010407@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229CDC@DB3PRD3001MB020.064d.mgd.msft.net> <54213FDB.4030204@plaimi.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22233E9F@DB3PRD3001MB020.064d.mgd.msft.net> | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where No. I'm proposing this. Insetad of data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int have this: data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a) So that HsCommaList a is very like [a] but can express precisely where the extra commas appear. Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things. The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified. Does that help? Simon | -----Original Message----- | From: Alexander Berntsen [mailto:alexander at plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | Alexander | alexander at plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE----- From alan.zimm at gmail.com Fri Sep 26 16:05:58 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 26 Sep 2014 18:05:58 +0200 Subject: ExtraCommas In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22233E9F@DB3PRD3001MB020.064d.mgd.msft.net> References: <542139EA.1010407@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229CDC@DB3PRD3001MB020.064d.mgd.msft.net> <54213FDB.4030204@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22233E9F@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Something else to throw into the mix, once the Located replacement by Genlocated is done for hsSyn I intend to capture the locations of all non-captured syntactic elements, such as commas. So this proposed mechanism would help, provided the location of each comma is also tracked. Alan On Fri, Sep 26, 2014 at 5:46 PM, Simon Peyton Jones wrote: > | What I think you are proposing is to capture commas in a different way > | altogether before this stage, and I do not understand how or where > > No. I'm proposing this. Insetad of > > data HsRecFields id > = HsRecFields { rec_flds :: [HsRecField id arg], > rec_dotdot :: Maybe Int > > have this: > > data HsRecFields id > = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), > rec_dotdot :: Maybe Int > > > data HsCommaList a > = Empty > | ExtraComma (HsCommaList a) > | Cons a (HsCommaList a) > > So that HsCommaList a is very like [a] but can express precisely where the > extra commas appear. > > Now adapt the parser to produce a (HsCommaList (HsRecField RdrName > (LHsExpr RdrName))), rather than a list of those things. > > The renamer then complains if it finds any ExtraComma constructors, unless > the -XExtraCommas is specified. > > Does that help? > > Simon > > | -----Original Message----- > | From: Alexander Berntsen [mailto:alexander at plaimi.net] > | Sent: 23 September 2014 10:40 > | To: Simon Peyton Jones > | Subject: Re: ExtraCommas > | > | -----BEGIN PGP SIGNED MESSAGE----- > | Hash: SHA256 > | > | On 23/09/14 11:28, Simon Peyton Jones wrote: > | > My advice was only: parse commas *always* as if they were part of > | the > | > language. (So the parser has no conditinoals.) Reject them later (in > | > the renamer) if the language extension is not enabled. > | I don't understand this. From my limited understanding commas are > | lexed, and then I can, in the parser, pattern match on things. Here's > | a very specific example, record field update/construction: > | > | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } > | : fbinds1 { $1 } > | | {- empty -} { ([], False) } > | > | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } > | : fbind ',' fbinds1 { case $3 of (flds, dd) -> > | ($1 : flds, dd) } > | | fbind { ([$1], False) } > | | '..' { ([], True) } > | > | What's happening here is that fbinds uses a helper fbinds1, to capture > | both fbinds1 & emptys. So to add support for leading/trailing commas, > | what I did is simply pattern match on them: > | > | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } > | : ',' fbinds1 { $2 } > | | fbinds1 { $1 } > | > | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } > | : fbind ',' fbinds1 { case $3 of > | (flds, dd) -> ($1 : flds, dd) > | } > | | fbind { ([$1], False) } > | | '..' { ([], True) } > | | {- empty -} { ([], False) } > | > | You can observe that I am now using fbinds to capture ',' fbinds1, and > | have moved the empty match to fbinds1 itself. > | > | This is the general pattern I have used for all of my patches so far. > | > | > | What I think you are proposing is to capture commas in a different way > | altogether before this stage, and I do not understand how or where > | this is meant to happen. And it also sounds like your suggestion will > | mean I need to handle the case where extra commas are *not* supposed > | to be handwaved, like tuples. So please elaborate, if you can. > | > | > Happy to talk. I'm simonpj0 on skype. > | Do you happen to use any non-proprietary tool or at least protocol? > | - -- > | Alexander > | alexander at plaimi.net > | https://secure.plaimi.net/~alexander > | -----BEGIN PGP SIGNATURE----- > | Version: GnuPG v2 > | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > | > | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 > | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P > | =saJc > | -----END PGP SIGNATURE----- > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Sep 26 16:38:04 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 26 Sep 2014 09:38:04 -0700 Subject: Linux failures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1411749407-sup-844@sabre> The user001 is tracked by this bug: https://ghc.haskell.org/trac/ghc/ticket/1487 Edward Excerpts from Simon Peyton Jones's message of 2014-09-26 04:37:59 -0700: > I am getting one persistent failure on Linux: > > > =====> user001(normal) 5 of 29 [0, 0, 0] > > cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 > > cd . && ./user001 >user001.run.stdout 2>user001.run.stderr > > Actual stdout output differs from expected: > > --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 > > +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 > > @@ -3,11 +3,11 @@ > > getEffectiveUserID: OK > > getEffectiveGroupID: OK > > getGroups: OK > > -getLoginName: OK > > +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) > > getEffectiveUserName: OK > > getGroupEntryForID: OK > > getGroupEntryForName: OK > > getAllGroupEntries: OK > > getUserEntryForID: OK > > -getUserEntryForName: OK > > +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) > > getAllUserEntries: OK > > *** unexpected failure for user001(normal) > > This is in libraries/unix/tests. > > I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: > ghci/should_run T2589 [bad stdout or stderr] (ghci) > ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) > > > +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 > > @@ -0,0 +1 @@ > > +ghc-stage2: ioManagerWakeup: write: Bad file descriptor > > I don't think these can be caused by my commits, but they should be fixed.... Any offers? > > Simon From thomasmiedema at gmail.com Fri Sep 26 16:43:20 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 26 Sep 2014 18:43:20 +0200 Subject: Linux failures In-Reply-To: <1411749407-sup-844@sabre> References: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> <1411749407-sup-844@sabre> Message-ID: Hi, The user001 is tracked by this bug: > https://ghc.haskell.org/trac/ghc/ticket/1487 This is my fault. I made a patch that reenabled that test some time ago, but it fails under certain conditions. I just proposed a proper solution to the libraries mailinglist . We could also disable the test now, if you don't want to wait at least another 2 weeks. With apologies, Thomas > > Excerpts from Simon Peyton Jones's message of 2014-09-26 04:37:59 -0700: > > I am getting one persistent failure on Linux: > > > > > > =====> user001(normal) 5 of 29 [0, 0, 0] > > > > cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp > -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts > -fno-ghci-history -o user001 user001.hs -package unix > >user001.comp.stderr 2>&1 > > > > cd . && ./user001 >user001.run.stdout 2>user001.run.stderr > > > > Actual stdout output differs from expected: > > > > --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 > > > > +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 > > > > @@ -3,11 +3,11 @@ > > > > getEffectiveUserID: OK > > > > getEffectiveGroupID: OK > > > > getGroups: OK > > > > -getLoginName: OK > > > > +getLoginName: ERROR: getLoginName: does not exist (No such file or > directory) > > > > getEffectiveUserName: OK > > > > getGroupEntryForID: OK > > > > getGroupEntryForName: OK > > > > getAllGroupEntries: OK > > > > getUserEntryForID: OK > > > > -getUserEntryForName: OK > > > > +getUserEntryForName: ERROR: getLoginName: does not exist (No such file > or directory) > > > > getAllUserEntries: OK > > > > *** unexpected failure for user001(normal) > > > > This is in libraries/unix/tests. > > > > I am also getting two failures when I say "sh validate" (runs in > parallel). But when I run them individually, they pass: > > ghci/should_run T2589 [bad stdout or stderr] (ghci) > > ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) > > > > > > +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 > 12:06:21.102269076 +0100 > > > > @@ -0,0 +1 @@ > > > > +ghc-stage2: ioManagerWakeup: write: Bad file descriptor > > > > I don't think these can be caused by my commits, but they should be > fixed.... Any offers? > > > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Sep 26 16:50:32 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 26 Sep 2014 16:50:32 +0000 Subject: Linux failures In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> <1411749407-sup-844@sabre> Message-ID: <618BE556AADD624C9C918AA5D5911BEF22233FC3@DB3PRD3001MB020.064d.mgd.msft.net> Yes, please disable it. Otherwise everyone?s ?validate? fails Simon From: Thomas Miedema [mailto:thomasmiedema at gmail.com] Sent: 26 September 2014 17:43 To: Edward Z. Yang Cc: Simon Peyton Jones; ghc-devs at haskell.org Subject: Re: Linux failures Hi, The user001 is tracked by this bug: https://ghc.haskell.org/trac/ghc/ticket/1487 This is my fault. I made a patch that reenabled that test some time ago, but it fails under certain conditions. I just proposed a proper solution to the libraries mailinglist. We could also disable the test now, if you don't want to wait at least another 2 weeks. With apologies, Thomas Excerpts from Simon Peyton Jones's message of 2014-09-26 04:37:59 -0700: > I am getting one persistent failure on Linux: > > > =====> user001(normal) 5 of 29 [0, 0, 0] > > cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr 2>&1 > > cd . && ./user001 >user001.run.stdout 2>user001.run.stderr > > Actual stdout output differs from expected: > > --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 > > +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 > > @@ -3,11 +3,11 @@ > > getEffectiveUserID: OK > > getEffectiveGroupID: OK > > getGroups: OK > > -getLoginName: OK > > +getLoginName: ERROR: getLoginName: does not exist (No such file or directory) > > getEffectiveUserName: OK > > getGroupEntryForID: OK > > getGroupEntryForName: OK > > getAllGroupEntries: OK > > getUserEntryForID: OK > > -getUserEntryForName: OK > > +getUserEntryForName: ERROR: getLoginName: does not exist (No such file or directory) > > getAllUserEntries: OK > > *** unexpected failure for user001(normal) > > This is in libraries/unix/tests. > > I am also getting two failures when I say "sh validate" (runs in parallel). But when I run them individually, they pass: > ghci/should_run T2589 [bad stdout or stderr] (ghci) > ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) > > > +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 12:06:21.102269076 +0100 > > @@ -0,0 +1 @@ > > +ghc-stage2: ioManagerWakeup: write: Bad file descriptor > > I don't think these can be caused by my commits, but they should be fixed.... Any offers? > > Simon _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Sep 26 16:51:37 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 26 Sep 2014 11:51:37 -0500 Subject: Linux failures In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22233A86@DB3PRD3001MB020.064d.mgd.msft.net> <1411749407-sup-844@sabre> Message-ID: Yes, probably the best to disable it for now. On Fri, Sep 26, 2014 at 11:43 AM, Thomas Miedema wrote: > Hi, > >> The user001 is tracked by this bug: >> https://ghc.haskell.org/trac/ghc/ticket/1487 > > > This is my fault. I made a patch that reenabled that test some time ago, but > it fails under certain conditions. I just proposed a proper solution to the > libraries mailinglist. We could also disable the test now, if you don't want > to wait at least another 2 weeks. > > With apologies, > Thomas > > >> >> >> Excerpts from Simon Peyton Jones's message of 2014-09-26 04:37:59 -0700: >> > I am getting one persistent failure on Linux: >> > >> > >> > =====> user001(normal) 5 of 29 [0, 0, 0] >> > >> > cd . && '/5playpen/simonpj/HEAD-2/inplace/bin/ghc-stage2' -fforce-recomp >> > -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts >> > -fno-ghci-history -o user001 user001.hs -package unix >user001.comp.stderr >> > 2>&1 >> > >> > cd . && ./user001 >user001.run.stdout 2>user001.run.stderr >> > >> > Actual stdout output differs from expected: >> > >> > --- ./user001.stdout 2014-09-11 08:38:41.000000000 +0100 >> > >> > +++ ./user001.run.stdout 2014-09-26 12:29:52.363884118 +0100 >> > >> > @@ -3,11 +3,11 @@ >> > >> > getEffectiveUserID: OK >> > >> > getEffectiveGroupID: OK >> > >> > getGroups: OK >> > >> > -getLoginName: OK >> > >> > +getLoginName: ERROR: getLoginName: does not exist (No such file or >> > directory) >> > >> > getEffectiveUserName: OK >> > >> > getGroupEntryForID: OK >> > >> > getGroupEntryForName: OK >> > >> > getAllGroupEntries: OK >> > >> > getUserEntryForID: OK >> > >> > -getUserEntryForName: OK >> > >> > +getUserEntryForName: ERROR: getLoginName: does not exist (No such file >> > or directory) >> > >> > getAllUserEntries: OK >> > >> > *** unexpected failure for user001(normal) >> > >> > This is in libraries/unix/tests. >> > >> > I am also getting two failures when I say "sh validate" (runs in >> > parallel). But when I run them individually, they pass: >> > ghci/should_run T2589 [bad stdout or stderr] (ghci) >> > ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) >> > >> > >> > +++ ./ghci/should_run/ghcirun004.run.stderr 2014-09-26 >> > 12:06:21.102269076 +0100 >> > >> > @@ -0,0 +1 @@ >> > >> > +ghc-stage2: ioManagerWakeup: write: Bad file descriptor >> > >> > I don't think these can be caused by my commits, but they should be >> > fixed.... Any offers? >> > >> > Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From eir at cis.upenn.edu Fri Sep 26 19:17:01 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 26 Sep 2014 15:17:01 -0400 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: <877g0raopr.fsf@gmail.com> References: <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> <87d2ak9fvi.fsf@gmail.com> <20140925113416.GA7340@machine> <877g0raopr.fsf@gmail.com> Message-ID: A modest counter-proposal to this idea: What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing. This doesn't solve other problems, but I'm not convinced every problem in this domain needs the same solution. In particular, I'm -1 on allowing a loose interpretation of commas in lists, as it seems very strange to have commas in lists and commas in tuples have a different meaning. (I'm +1 on fixing import/export lists, though.) Richard On Sep 25, 2014, at 8:06 AM, Herbert Valerio Riedel wrote: > On 2014-09-25 at 13:34:16 +0200, Daniel Trstenjak wrote: > > [...] > >> One compromise could be, that additional commatas in literal lists >> are only allowed at the beginning and at the end. > > ...another idea could be to make it a separate Pragma > (e.g. ExtraCommasLists) if there's a chance of ListSections (which would > conflict with this) becoming a reality. > >> Then your use case would work and also something like: >> >> abc = [ >> -- a >> , a >> -- b >> , b >> -- c >> , c >> ] > > I'd probably prefer leading-comma over trailing-comma style anyway (as > I've grown to like it over the years). > >> I think that are the main uses of additional commatas in literal lists >> and I can't see that someone really wants a list literal like '[,3,,4,]', >> so wrongly reading it as a list section shouldn't be an issue. > > Yeah, I don't care much about extra middle-commas either. Personally, > I'd be already happy with just trailing & leading extra-comma support. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From austin at well-typed.com Fri Sep 26 20:49:34 2014 From: austin at well-typed.com (Austin Seipp) Date: Fri, 26 Sep 2014 15:49:34 -0500 Subject: REMINDER: Please review the HCAR entry for GHC! Message-ID: Hi *, Just a regularly scheduled reminder: please double-check the latest HCAR entry so we can make sure it's great for the October edition: https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 The current page looks good, but we're missing some things like: - Backpack updates - Information on the BBP from Herbert. - We've implemented some new optimizations since last time, like Call Arity, and some other improvements. - Other things: AArch64 support, probably other stuff. I'm sure you all remember what you did. :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From roma at ro-che.info Fri Sep 26 21:26:50 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 27 Sep 2014 00:26:50 +0300 Subject: Permitting trailing commas for record syntax ADT declarations In-Reply-To: References: <5420168E.5020503@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22228446@DB3PRD3001MB020.064d.mgd.msft.net> <54211D1A.5050400@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF22229BC6@DB3PRD3001MB020.064d.mgd.msft.net> <54229F0E.2040009@plaimi.net> <618BE556AADD624C9C918AA5D5911BEF2222F36B@DB3PRD3001MB020.064d.mgd.msft.net> <87d2ak9fvi.fsf@gmail.com> <20140925113416.GA7340@machine> <877g0raopr.fsf@gmail.com> Message-ID: <5425DA1A.40006@ro-che.info> On 26/09/14 22:17, Richard Eisenberg wrote: > A modest counter-proposal to this idea: > > What if we just stopped requiring commas in import/export lists? As far as I can tell, they're not necessary for proper parsing. Things can get somewhat ambiguous: module M (module A value B type C) Granted, 'module' and 'type' are keywords and cannot be value names, but: * this introduces ambiguities for the parser, even if they are resolvable * this is hard to read for humans * it seems likely that we'll be getting even more qualifiers in the future ('kind'?) Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rwbarton at gmail.com Sat Sep 27 16:26:08 2014 From: rwbarton at gmail.com (Reid Barton) Date: Sat, 27 Sep 2014 12:26:08 -0400 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: <1407498991-sup-1278@sabre> References: <1407498991-sup-1278@sabre> Message-ID: On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang wrote: > Hey all, > > SPJ pointed out to me today that if you try to run: > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > with the latest GHC HEAD, this probably will not actually work, because > your system installed version of Cabal is probably too old to deal with > the new package key stuff in HEAD. So, how do you get a version > of cabal-install (and Cabal) which is new enough to do what you need > it to? > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > (or install it in a sandbox, if you like) and then cd'ing to > libraries/Cabal/cabal-install and cabal install'ing that. > Hi all, The new cabal-install I built last month following the instructions above started failing with recent GHC HEAD with messages like ghc: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with the correct format. I found that repeating these steps with the latest libraries/Cabal submodule gave me a cabal-install that, so far, appears to be working with GHC HEAD. So if your cabal-install has stopped working with HEAD, try building the latest version as outlined in Edward's email. Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware of? Regards, Reid Barton -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Sep 27 16:40:31 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 27 Sep 2014 12:40:31 -0400 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> Message-ID: Currently released cabal-install on hackage doesn't know how to do linkery for ghc head afaik, but I could be wrong On Sat, Sep 27, 2014 at 12:26 PM, Reid Barton wrote: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang wrote: > >> Hey all, >> >> SPJ pointed out to me today that if you try to run: >> >> cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 >> >> with the latest GHC HEAD, this probably will not actually work, because >> your system installed version of Cabal is probably too old to deal with >> the new package key stuff in HEAD. So, how do you get a version >> of cabal-install (and Cabal) which is new enough to do what you need >> it to? >> >> The trick is to compile Cabal using your /old/ GHC. Step-by-step, this >> involves cd'ing into libraries/Cabal/Cabal and running `cabal install` >> (or install it in a sandbox, if you like) and then cd'ing to >> libraries/Cabal/cabal-install and cabal install'ing that. >> > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sat Sep 27 16:43:13 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 27 Sep 2014 09:43:13 -0700 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> Message-ID: <1411836134-sup-3864@sabre> Hi Reid, Ah yes, this is fallout from commit da7289882610ccae3f16c74be7440d19c29ecd20 Author: Duncan Coutts Date: Wed Aug 27 16:33:20 2014 +0100 Change testsuite to not use old-style file package databases Now uses ghc-pkg init. The file-style databases are no longer supported. So yes, you will need a new version of cabal-install for GHC HEAD. Cheers, Edward Excerpts from Reid Barton's message of 2014-09-27 09:26:08 -0700: > On Fri, Aug 8, 2014 at 8:00 AM, Edward Z. Yang wrote: > > > Hey all, > > > > SPJ pointed out to me today that if you try to run: > > > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > > > with the latest GHC HEAD, this probably will not actually work, because > > your system installed version of Cabal is probably too old to deal with > > the new package key stuff in HEAD. So, how do you get a version > > of cabal-install (and Cabal) which is new enough to do what you need > > it to? > > > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > > (or install it in a sandbox, if you like) and then cd'ing to > > libraries/Cabal/cabal-install and cabal install'ing that. > > > > Hi all, > > The new cabal-install I built last month following the instructions above > started failing with recent GHC HEAD with messages like > > ghc: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with > the correct format. > > I found that repeating these steps with the latest libraries/Cabal > submodule gave me a cabal-install that, so far, appears to be working with > GHC HEAD. So if your cabal-install has stopped working with HEAD, try > building the latest version as outlined in Edward's email. > > Cabal wizards, any gotchas with current Cabal & GHC HEAD I should be aware > of? > > Regards, > Reid Barton From karel.gardas at centrum.cz Sat Sep 27 18:19:17 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 27 Sep 2014 20:19:17 +0200 Subject: tar --help is failing on Solaris. Message-ID: <5426FFA5.30903@centrum.cz> Hello Mikhail, you are the author of the patch eaf2aae18603965ff668384b391fcaa14de19823 in libraries/Cabal which you have merged into GHC HEAD on September 25 in the patch 4be50969491aa471d6c9ab3b9339036a355d45c6 The problem is that your patch breaks build on Solaris, here is the log from the Solaris/x86 builder: http://haskell.inf.elte.hu/builders/solaris-x86-head/178/10.html Could you be so kind and revert this patch or fix it to also work on Solaris? For Solaris the change should be easy, simply if you invoke Solaris' tar with --help, it'll fail with exit code 1 and help message printed into the stderr. If you are curious if it supports --format, then no. Please let me know if you are able to push fix or revert during next week or if I shall deal with it myself. I can't just fix that now myself since I'm overloaded with other tasks till Wednesday night... Thanks! Karel From mikhail.glushenkov at gmail.com Sat Sep 27 19:09:11 2014 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Sat, 27 Sep 2014 21:09:11 +0200 Subject: tar --help is failing on Solaris. In-Reply-To: <5426FFA5.30903@centrum.cz> References: <5426FFA5.30903@centrum.cz> Message-ID: Hi Karel, On 27 September 2014 20:19, Karel Gardas wrote: > > [...] > Could you be so kind and revert this patch or fix it to also work on > Solaris? For Solaris the change should be easy, simply if you invoke > Solaris' tar with --help, it'll fail with exit code 1 and help message > printed into the stderr. If you are curious if it supports --format, then > no. Should be fixed now. Thanks for the heads-up! From karel.gardas at centrum.cz Sat Sep 27 19:46:13 2014 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 27 Sep 2014 21:46:13 +0200 Subject: tar --help is failing on Solaris. In-Reply-To: References: <5426FFA5.30903@centrum.cz> Message-ID: <54271405.3010107@centrum.cz> Hi Mikhail, On 09/27/14 09:09 PM, Mikhail Glushenkov wrote: > On 27 September 2014 20:19, Karel Gardas wrote: >> >> [...] >> Could you be so kind and revert this patch or fix it to also work on >> Solaris? For Solaris the change should be easy, simply if you invoke >> Solaris' tar with --help, it'll fail with exit code 1 and help message >> printed into the stderr. If you are curious if it supports --format, then >> no. > > Should be fixed now. Thanks for the heads-up! Have you already pushed? I don't see it fixed on my end yet: "inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with-ghc="/opt/ghc-7.8.2/bin/ghc" --with-ghc-pkg="/opt/ghc-7.8.2/bin/ghc-pkg" --package-db=/export/home/karel/vcs/ghc-src/tar-test/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --with-hscolour="/export/home/karel/.cabal/bin/HsColour" --configure-option=CFLAGS=" -U__i686 -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -U__i686 -fno-stack-protector " --configure-option=--with-gmp-includes="/usr/include/gmp/" --configure-option=--with-gmp-libraries="/usr/lib/" --constraint "binary == 0.7.1.0" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.1.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin//gcc" --configure-option=--with-cc="/usr/bin//gcc" --with-ar="/usr/xpg4/bin//ar" --with-alex="/export/home/karel/.cabal/bin/alex" --with-happy="/export/home/karel/.cabal/bin/happy" Configuring binary-0.7.1.0... ghc-cabal: '/usr/bin/tar' exited with an error: Usage: tar {c|r|t|u|x}[BDeEFhilmnopPTvw@/[0-7]][bf][X...] [j|z|Z] [blocksize] [tarfile] [size] [exclude-file...] {file | -I include-file | -C directory file}... gmake[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 gmake: *** [all] Error 2 and I've got whole new ghc tree for this test... Thanks! Karel From hvriedel at gmail.com Sat Sep 27 19:51:10 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 27 Sep 2014 21:51:10 +0200 Subject: tar --help is failing on Solaris. In-Reply-To: <54271405.3010107@centrum.cz> (Karel Gardas's message of "Sat, 27 Sep 2014 21:46:13 +0200") References: <5426FFA5.30903@centrum.cz> <54271405.3010107@centrum.cz> Message-ID: <87fvfcx2oh.fsf@gmail.com> On 2014-09-27 at 21:46:13 +0200, Karel Gardas wrote: > Hi Mikhail, > > On 09/27/14 09:09 PM, Mikhail Glushenkov wrote: >> On 27 September 2014 20:19, Karel Gardas wrote: >>> >>> [...] >>> Could you be so kind and revert this patch or fix it to also work on >>> Solaris? For Solaris the change should be easy, simply if you invoke >>> Solaris' tar with --help, it'll fail with exit code 1 and help message >>> printed into the stderr. If you are curious if it supports --format, then >>> no. >> >> Should be fixed now. Thanks for the heads-up! > > Have you already pushed? I don't see it fixed on my end yet: fyi, libraries/Cabal is a submodule, so here's what you should do, (assuming you've ghc's checkout is at its latest state): # update/checkout submodule to latest commit from Cabal's master branch git submodule update --remote libraries/Cabal # test ./validate still works # record submodule update in git index git add libraries/Cabal # create commit, and make sure the commit msg contains the # magic word "submodule" git commit # ... git push HTH, hvr From gintautas.miliauskas at gmail.com Sat Sep 27 21:04:38 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Sat, 27 Sep 2014 23:04:38 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi, I've been spending some time on the Windows build, and a bunch of things came up. 1. Building on msys2 with the provided ghc-tarballs works. The wikipage for MSYS2 should be in good shape. It would be nice to get a bit more testing and then consider replacing the default Windows build page . The new instructions are significantly simpler and basically a few steps of copy & paste after installing msys2. 2. Since the msys2 setup instructions are so simple and linear, perhaps it would be even better to put them in a shellscript and check that in? Then the wikipage would turn into a one-liner. 3. Why is ghc-tarballs a git repository? That does not seem very wise. For now, it does not hurt much, but whenever the tarballs are updated the repository will grow fatter and fatter, forcing people to download all versions of tarballs that were ever checked in. It's not really a problem now (only one version of mingw has ever been checked in so far, for example), but will become annoying. Can we move from the broken model? Could we have a stable folder under haskell.org/ to put the files in, to make sure that they never go away, and just wget/curl them from there? 4. Looks like the rubenvb archive could be updated, there's a new version (gcc 4.8.0) available. That should be a step up from 4.6.3 and should address some complaints about the aged toolchain that I saw on the issue tracker (and this one too) I tried out building with the new tarball, and it seems to work, although I did not look too closely. (Some tests failed, but I have not checked if they also failed with the previous version. That takes so long...) 5. Why are we using the rubenvb build of mingw? I don't think I've seen any comments about that in the repository. Is there anything special about it? A short README with a note next to the tarball would be great. 6. There is an asymmetry between the embedded 64-bit distribution mingw and the 32-bit distribution. The former is a single rubenvb tarball, while the latter is a bunch of files. There's a monolithic rubenvb build available for 32-bit too . Should we use that? It would simplify the build scripts and make the builds more consistent. 7. ghc-tarballs includes perl. Ugh. I don't think there's much perl code remaining in the repository, shall we just clean up that mess and drop the dependency? Or at least just assume that the host system provides it (which msys2 does). 8. A broader question: what general approach to ghc on Windows shall we take? The prebuilt packages currently provided by ghc-tarballs are also covered by msys2's package manager. Why not offload that pain to msys2 then? The advantage here is less maintenance (and automatic upgrades of the toolchain), the disadvantage is that the distribution becomes less stable and msys2 updates could break ghc builds more easily. I think it would make sense to be consistent with the Linux builds; we don't bundle compilers with those. In that sense msys2 would be like another distribution. Of course, we need to also consider if msys2 can be trusted to stick around and stay up to date in the long run. It looks like a relatively new project, so there's some risk. 9. If I understand correctly, one other thing to consider before dropping ghc-tarballs is that Windows ghc still needs GCC utilities (like cpp) to function properly, and so we need to have a prepackaged bundle of binary GCC utilities (and maybe hardcoded paths? not sure) to make that work. On the other hand, a custom-built ghc should work just fine in the msys2 environment which does provide cpp et al., and the additional GCC bundles would perhaps best be owned by, for example, the Haskell Platform project rather than be part of core ghc? 10. Following the idea in (8), I tried to build ghc using the mingw gcc provided by msys2 instead of the one in ghc-tarballs. It was a bit weird. I had to hack configure.ac to disable use of ghc-tarballs and try to use system tools. How about a configure option to enable/disable use of ghc-tarballs? I also ran into some weird issues, for example, the system ld and nm would not get detected by the configure script correctly. They were found when I explicitly set LD=ld and NM=nm. Weird. Will look into that later. Other than that, there were no major problems, except... 11. A build with the host gcc failed. I think the cause is that it is too new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of the currently checked in GMP (libraries/integer-gmp) fails because a utility used in the build process segfaults. I tried upgrading gmp from 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One of the advantages of tracking msys2's gcc would be that we would notice such breakage earlier. Shall I open an issue? 12. Another advantage of switching to msys2's gcc is that it I think it would allow ghc to drop some hacks . 13. Side note: early on because of my own confusion I wasted a bunch of time trying to get ghc to build with /usr/bin/ghc in msys2, which is the cygwin gcc that provides additional POSIX compatibility layers. That could work in theory, but I ran into numerous issues with msys name mangling (/usr/bin/gcc gets really confused when run as c:/msys64/usr/bin/gcc, which breaks many ghc subproject builds). Might be a good idea to put in a guard in the configure script to warn if a cygwin gcc is detected (or add explicit support for it). Actually, looks like there's already a related issue open, although I'm not quite sure what the scope is there (#8842 , thanks Thomas). 14. The test runner assumes native Windows Python, but it's only a few small changes away from working fine on the python2 provided by msys2, which would cut another external build dependency. Could someone review and merge my patches (#9604 , #9626 )? Thanks. On Mon, Sep 15, 2014 at 11:33 PM, Simon Peyton Jones wrote: > Thank you! Indeed Neil Mitchell is also acting as ?guinea pig? at the > moment. It would be **great** if together you were able to clean up the > ?how to build on Windows? page, remove out of date or misleading > information, and yes I think we should focus on msys2. > > > > Great stuff > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Gintautas > Miliauskas > *Sent:* 15 September 2014 21:58 > *To:* ghc-devs at haskell.org > *Subject:* Building ghc on Windows with msys2 > > > > Hello, > > > > I have been messing around a little bit with building GHC from source on > Windows, and found the msys2 wikipage > quite > useful, but somewhat outdated. Quite a few steps in those instructions are > no longer necessary and can be omitted. I am working on cleaning up that > wikipage right now and should be done in a day or two. > > > > I've found a recent email > in > the middle of updating the wikipage about other people planning to do the > same, so I thought I'd shoot an email to make sure that work is not being > duplicated. > > > > msys2 seems to be in good shape and should probably be promoted to the > primary suggested method to build ghc on Windows. Let's look into that once > the new build instructions have been proofread and verified. > > > > Best regards, > > -- > Gintautas Miliauskas > -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sat Sep 27 21:56:38 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 27 Sep 2014 23:56:38 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: (Gintautas Miliauskas's message of "Sat, 27 Sep 2014 23:04:38 +0200") References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87bnq0wwvd.fsf@gmail.com> Hello! I can only address a small subset of your comments as I don't usually develop on Windows and hence lack any significant Windows experience... On 2014-09-27 at 23:04:38 +0200, Gintautas Miliauskas wrote: [...] > 2. Since the msys2 setup instructions are so simple and linear, perhaps it > would be even better to put them in a shellscript and check that in? Then > the wikipage would turn into a one-liner. Fwiw, I recently tried msys2, but after wasting several hours I simply couldn't get it to work in a way where I could ssh (tried Freesshd and Winsshd) into an MSYS2 environemnt. Then I simply installed Cygwin against the recommendation, and then I finally got a working ssh-able environment with a few steps, which roughly where OTTOMH: - Install cygwin (make sure 'wget' and 'openssh' gets installed), - grab https://github.com/transcode-open/apt-cyg and place into /usr/local/bin/ - "cygrunsrv" in order to install sshd service - allow 'sshd.exe' in Windows-firewall settings from now on the graphical Windows console/deskopt isn't required anymore (which was my primary goal). Everything else can be done headless/remote via ssh: - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3 - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's PATH via ~/.bash_profile or similiar - follow similiar steps to grab cabal and install alex/happy like for MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32` to cabal, though. - apt-cyg install automake git - clone and build ghc as if it was MSYS2 Long-story short, if it wasn't for Cygwin, I wouldn't have been able to clean up after some of the Windows breakage I caused recently. It'd be interesting though if there was a way to `ssh` directly (with a sane terminal-emulation) into an MSYS2 environment capable of building GHC. > 3. Why is ghc-tarballs a git repository? That does not seem very wise. [...] > Could we have a stable folder under haskell.org/ to put the files in, to > make sure that they never go away, and just wget/curl them from there? http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 > 8. A broader question: what general approach to ghc on Windows shall we > take? [...] > I think it would make sense to be consistent with the Linux builds; we > don't bundle compilers with those. In that sense msys2 would be like > another distribution. I'd like that... > 9. If I understand correctly, one other thing to consider before dropping > ghc-tarballs is that Windows ghc still needs GCC utilities (like cpp) to > function properly, [...] Fwiw, at least `cpp` could in theory be replaced by `cpphs` [...] > 10. Following the idea in (8), I tried to build ghc using the mingw gcc > provided by msys2 instead of the one in ghc-tarballs. It was a bit weird. I > had to hack configure.ac to disable use of ghc-tarballs and try to use > system tools. How about a configure option to enable/disable use of > ghc-tarballs? Fwiw, Cygwin also provides mingw-gcc (cross)compiler packages to install. So the same could work on Cygwin... > 11. A build with the host gcc failed. I think the cause is that it is too > new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of > the currently checked in GMP (libraries/integer-gmp) fails because a > utility used in the build process segfaults. I tried upgrading gmp from > 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch > used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One > of the advantages of tracking msys2's gcc would be that we would notice > such breakage earlier. Shall I open an issue? The patched in-tree GMP lib isn't necessary anymore with the rewritten integer-gmp2 package (which was one of the motivations to do the rewrite in the first place). [...] > Might be a good idea to put in a guard in the configure script to warn > if a cygwin gcc is detected (or add explicit support for > it). Actually, looks like there's already a related issue open, > although I'm not quite sure what the scope is there (#8842 > , thanks Thomas). It'd be great if one couldn't only use Cygwin as a `build`-environment, but also as the `host`-environment you compile for. > 14. The test runner assumes native Windows Python, but it's only a few > small changes away from working fine on the python2 provided by msys2, > which would cut another external build dependency. Could someone review and > merge my patches (#9604 , > #9626 )? Thanks. Fwiw, the test-runner seems to work fine with the Cygwin-provided Python interpreter. From kyrab at mail.ru Sun Sep 28 07:08:24 2014 From: kyrab at mail.ru (kyra) Date: Sun, 28 Sep 2014 11:08:24 +0400 Subject: Building ghc on Windows with msys2 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <5427B3E8.6040802@mail.ru> On 9/28/2014 1:04 AM, Gintautas Miliauskas wrote: > 11. A build with the host gcc failed. I think the cause is that it is > too new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The > build of the currently checked in GMP (libraries/integer-gmp) fails > because a utility used in the build process segfaults. I tried > upgrading gmp from 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but > the ghc-specific patch used for 5.0.3 no longer applies (is it still > necessary?). Oh brother. One of the advantages of tracking msys2's gcc > would be that we would notice such breakage earlier. Shall I open an > issue? I believe this is not a segfault, it's a GHC RTS' dynamic linker barfing it can't handle duplicated symbols. Since 4.9 gcc (on Windows at least) started to generate .linkonce section for external symbols. I have a patch for this and I successfully built GHC HEAD with the most fresh stock msys2 mingw64 components. However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3. 'Mingw-builds' project (which is now a part of mingw-w64 project and is considered to be an "official" mingw-w64 gcc distribution and is maintained by a man close to Msys2 project) has very nice and complete build of 4.8.3 (64-bit build, for example, is here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). I also urge to not use "msys2's gcc" phrase because it's possible to install gcc which uses msys2 runtime and generates binaries which use msys2 runtime, but it is absolutely wrong thing. What do we want in fact is to use mingw64 (x86_64-w64-mingw32) or mingw32 (i686-w64-mingw32) toolchains based on and targeting mingw-w64 runtime. Cheers, Kyra From gintautas at miliauskas.lt Sun Sep 28 19:16:27 2014 From: gintautas at miliauskas.lt (Gintautas Miliauskas) Date: Sun, 28 Sep 2014 21:16:27 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: <5427B3E8.6040802@mail.ru> References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> <5427B3E8.6040802@mail.ru> Message-ID: > However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on Windows than 4.8.3. Hmm, that sounds like an argument against trusting msys2 to provide a sane mingw gcc compiler... Bummer. What kind of bugs did you have in mind? > 'Mingw-builds' project (which is now a part of mingw-w64 project and is considered to be an "official" mingw-w64 gcc distribution and is maintained by a man close to Msys2 project) has very nice and complete build of 4.8.3 (64-bit build, for example, is here: http://sourceforge.net/ projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ mingw-builds/4.8.3/threads-posix/seh/). Sounds good. Should we switch to this using this package instead of the rubenvb build? > I also urge to not use "msys2's gcc" phrase because it's possible to install gcc which uses msys2 runtime and generates binaries which use msys2 runtime, but it is absolutely wrong thing. What do we want in fact is to use mingw64 (x86_64-w64-mingw32) or mingw32 (i686-w64-mingw32) toolchains based on and targeting mingw-w64 runtime. Yes, I know (now, after wasting some time on that...). The suggestion was exactly to warn the user if such a type of gcc is detected, because that's almost never what you want. On Sun, Sep 28, 2014 at 9:08 AM, kyra wrote: > On 9/28/2014 1:04 AM, Gintautas Miliauskas wrote: > >> 11. A build with the host gcc failed. I think the cause is that it is too >> new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of >> the currently checked in GMP (libraries/integer-gmp) fails because a >> utility used in the build process segfaults. I tried upgrading gmp from >> 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific patch >> used for 5.0.3 no longer applies (is it still necessary?). Oh brother. One >> of the advantages of tracking msys2's gcc would be that we would notice >> such breakage earlier. Shall I open an issue? >> > I believe this is not a segfault, it's a GHC RTS' dynamic linker barfing > it can't handle duplicated symbols. Since 4.9 gcc (on Windows at least) > started to generate .linkonce section for external symbols. I have a patch > for this and I successfully built GHC HEAD with the most fresh stock msys2 > mingw64 components. > > However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on > Windows than 4.8.3. 'Mingw-builds' project (which is now a part of > mingw-w64 project and is considered to be an "official" mingw-w64 gcc > distribution and is maintained by a man close to Msys2 project) has very > nice and complete build of 4.8.3 (64-bit build, for example, is here: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% > 20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). > > I also urge to not use "msys2's gcc" phrase because it's possible to > install gcc which uses msys2 runtime and generates binaries which use msys2 > runtime, but it is absolutely wrong thing. What do we want in fact is to > use mingw64 (x86_64-w64-mingw32) or mingw32 (i686-w64-mingw32) toolchains > based on and targeting mingw-w64 runtime. > > Cheers, > Kyra > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From gintautas.miliauskas at gmail.com Sun Sep 28 19:35:48 2014 From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas) Date: Sun, 28 Sep 2014 21:35:48 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: <87bnq0wwvd.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> <87bnq0wwvd.fsf@gmail.com> Message-ID: Hey, I can only address a small subset of your comments as I don't usually > develop on Windows and hence lack any significant Windows experience... > Thanks. Honestly, I'm no fan of Windows either. Not sure how I got into this mess :) > 2. Since the msys2 setup instructions are so simple and linear, perhaps it > > would be even better to put them in a shellscript and check that in? Then > > the wikipage would turn into a one-liner. > > Fwiw, I recently tried msys2, but after wasting several hours I simply > couldn't get it to work in a way where I could ssh (tried Freesshd and > Winsshd) into an MSYS2 environemnt. > Actually, that seems to work fine over here. I just needed to install the 'openssh' package using pacman (I think it may have been installed by default), then create a user 'sshd' in /etc/passwd (for privilege separation) and create ssh host keys (ssh-keygen -A). Then "sshd" started a server that I was able to connect to successfully. Anyway, this does not seem to be relevant to the build environment discussion... > from now on the graphical Windows console/deskopt isn't required anymore > (which was my primary goal). Everything else can be done headless/remote > via ssh: > > - `wget` ghc-7.6.3 windows bindist and unpack to /opt/ghc-7.6.3 > - prepend /opt/ghc-7.6.3/bin/ and /opt/ghc-7.6.3/mingw/bin/ to user's > PATH via ~/.bash_profile or similiar > - follow similiar steps to grab cabal and install alex/happy like for > MSYS2; you need to pass `--configure-option=--build=x86_64-w64-mingw32` > to cabal, though. > - apt-cyg install automake git > - clone and build ghc as if it was MSYS2 > Fair enough. I prefer msys2 as it seems to be a more minimalistic and simpler environment that Cygwin (and installation seems easier too). Are there other advantages to cygwin? > > 3. Why is ghc-tarballs a git repository? That does not seem very wise. > [...] > > Could we have a stable folder under haskell.org/ to put the files in, to > > make sure that they never go away, and just wget/curl them from there? > > http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 > Hmm, that was a while ago. Whom should I contact to get the files deployed under haskell.org? > 11. A build with the host gcc failed. I think the cause is that it is too > > new (4.9.1, significantly newer than 4.6.3 in ghc-tarballs). The build of > > the currently checked in GMP (libraries/integer-gmp) fails because a > > utility used in the build process segfaults. I tried upgrading gmp from > > 5.0.3 to 6.0.0, and 6.0.0 builds fine by itself but the ghc-specific > patch > > used for 5.0.3 no longer applies (is it still necessary?). Oh brother. > One > > of the advantages of tracking msys2's gcc would be that we would notice > > such breakage earlier. Shall I open an issue? > > The patched in-tree GMP lib isn't necessary anymore with the rewritten > integer-gmp2 package (which was one of the motivations to do the rewrite > in the first place). > Cool! Why is the old library still in the tree then? Can it be deleted? > > Might be a good idea to put in a guard in the configure script to warn > > if a cygwin gcc is detected (or add explicit support for > > it). Actually, looks like there's already a related issue open, > > although I'm not quite sure what the scope is there (#8842 > > , thanks Thomas). > > It'd be great if one couldn't only use Cygwin as a `build`-environment, > but also as the `host`-environment you compile for. > You mean, being able to build binaries which use cygwin1.dll / msys-2.0.dll? Not sure there's much benefit to that... > > 14. The test runner assumes native Windows Python, but it's only a few > > small changes away from working fine on the python2 provided by msys2, > > which would cut another external build dependency. Could someone review > and > > merge my patches (#9604 , > > #9626 )? Thanks. > > Fwiw, the test-runner seems to work fine with the Cygwin-provided Python > interpreter. > Hmm, interesting... -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyrab at mail.ru Mon Sep 29 07:00:01 2014 From: kyrab at mail.ru (kyra) Date: Mon, 29 Sep 2014 11:00:01 +0400 Subject: Building ghc on Windows with msys2 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> <5427B3E8.6040802@mail.ru> Message-ID: <54290371.2020308@mail.ru> On 9/28/2014 11:16 PM, Gintautas Miliauskas wrote: > > However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy > on Windows than 4.8.3. > > Hmm, that sounds like an argument against trusting msys2 to provide a > sane mingw gcc compiler... Bummer. What kind of bugs did you have in mind? Don't think so. I think msys2 mingw64/mingw32 supply more or less the same builds as thread-posix+seh/thread-posix+dwarf builds supplied by 'mingw-builds' (they also make another combinations). One of windows' specific problem of gcc 4.9.1 was that DLL built using it turned out to be broken, such that OS refused to load it. And that was not a binutils' problem, switching compiler only to gcc 4.8.3 fixed things for me. But that was not related to using GHC. And there are chances gcc 4.9.1 is not a culprit itself and simply exposed some bug sitting elsewhere. I didn't investigate the problem thoroughly. > > 'Mingw-builds' project (which is now a part of mingw-w64 project and > is considered to be an "official" mingw-w64 gcc distribution and is > maintained by a man close to Msys2 project) has very nice and complete > build of 4.8.3 (64-bit build, for example, is here: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). > > Sounds good. Should we switch to this using this package instead of > the rubenvb build? Perhaps. At least, I didn't have *any* problems with it. Cheers, Kyra From mail at joachim-breitner.de Mon Sep 29 07:44:30 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Sep 2014 09:44:30 +0200 Subject: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa) In-Reply-To: <20140927210732.436603A002@ghc.haskell.org> References: <20140927210732.436603A002@ghc.haskell.org> Message-ID: <1411976670.2677.0.camel@joachim-breitner.de> Hi, Am Samstag, den 27.09.2014, 21:07 +0000 schrieb git at git.haskell.org: > commit f636faa7b2b7fc1d0663f994ad08f365d39a746d > Author: Herbert Valerio Riedel > Date: Sat Sep 27 22:55:19 2014 +0200 > > Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` > > This is made possible by the AMP, as we don't need the `WrappedMonad` > helper for that anymore. according to http://ghcspeed-nomeata.rhcloud.com/changes/?rev=f636faa7b2b7fc1d0663f994ad08f365d39a746d&exe=2&env=nomeata%27s%20buildbot this has caused a 11% regression in fibheaps allocation: http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/allocs/fibheaps&env=1#/?exe=2&base=2+68&ben=nofib/allocs/fibheaps&env=1&revs=50&equid=on Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvr at gnu.org Mon Sep 29 08:19:04 2014 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 29 Sep 2014 10:19:04 +0200 Subject: Aliasing current module qualifier Message-ID: <8761g66dqf.fsf@gnu.org> Hello *, Here's a situation I've encountered recently, which mades me wish to be able to define a local alias (in order to avoid CPP use). Consider the following stupid module: module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . AnnoyinglyLongModuleName.length Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work length :: a -> Int length _ = 0 null :: a -> Bool null = (== 0) . M.length However, if I try to compile this, GHC complains about AnnoyinglyLongModuleName.hs:4:1: Bad interface file: AnnoyinglyLongModuleName.hi AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) while GHCi tells me: Module imports form a cycle: module ?AnnoyinglyLongModuleName? (AnnoyinglyLongModuleName.hs) imports itself Is there some other way (without CPP) to create a local alias for the current module-name? If not, is there a reason GHC couldn't support this special case of self-aliasing the current module name? PS: Alternatively, this could be done as a language extension but that'd require extending the Haskell grammar: module AnnoyinglyLongModuleName as M (M.length, M.null) where Cheers, hvr From abela at chalmers.se Mon Sep 29 08:43:28 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 29 Sep 2014 10:43:28 +0200 Subject: Aliasing current module qualifier In-Reply-To: <8761g66dqf.fsf@gnu.org> References: <8761g66dqf.fsf@gnu.org> Message-ID: <54291BB0.6060907@chalmers.se> Indeed, being able to introduce a short name for the current module, or having a fixed short name like 'This' or 'Self' would be neat. The standard workaround for your example would be import Prelude hiding (length,null) Did you try a .hs-boot file with your self-import trick? Cheers, Andreas On 29.09.2014 10:19, Herbert Valerio Riedel wrote: > Hello *, > > Here's a situation I've encountered recently, which mades me wish to be > able to define a local alias (in order to avoid CPP use). Consider the > following stupid module: > > > module AnnoyinglyLongModuleName > ( AnnoyinglyLongModuleName.length > , AnnoyinglyLongModuleName.null > ) where > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . AnnoyinglyLongModuleName.length > > > Now it'd be great if I could do the following instead: > > module AnnoyinglyLongModuleName (M.length, M.null) where > > import AnnoyinglyLongModuleName as M -- <- does not work > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . M.length > > However, if I try to compile this, GHC complains about > > AnnoyinglyLongModuleName.hs:4:1: > Bad interface file: AnnoyinglyLongModuleName.hi > AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) > > while GHCi tells me: > > Module imports form a cycle: > module ?AnnoyinglyLongModuleName? (AnnoyinglyLongModuleName.hs) imports itself > > > Is there some other way (without CPP) to create a local alias for the > current module-name? If not, is there a reason GHC couldn't support this > special case of self-aliasing the current module name? > > > PS: Alternatively, this could be done as a language extension but that'd > require extending the Haskell grammar: > > module AnnoyinglyLongModuleName as M (M.length, M.null) where > > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From hvriedel at gmail.com Mon Sep 29 08:48:26 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 29 Sep 2014 10:48:26 +0200 Subject: Aliasing current module qualifier In-Reply-To: <54291BB0.6060907@chalmers.se> (Andreas Abel's message of "Mon, 29 Sep 2014 10:43:28 +0200") References: <8761g66dqf.fsf@gnu.org> <54291BB0.6060907@chalmers.se> Message-ID: <87sija4xt1.fsf@gmail.com> On 2014-09-29 at 10:43:28 +0200, Andreas Abel wrote: > Indeed, being able to introduce a short name for the current module, > or having a fixed short name like 'This' or 'Self' would be neat. > > The standard workaround for your example would be > > import Prelude hiding (length,null) That won't work though, because what I failed to mention is that I needed this (while avoiding CPP) to cope with external modules growing their exports lists, such as Data.Foldable starting to export 'length' and 'null' in base-4.8.0.0 Moreover, hiding a non-existent symbol is a warning in recent GHC's but a hard error in older GHCs, so that's not an option either if you want to avoid CPP, support GHCs back to 7.0, and be -Werror-clean. More generally, 'hiding'-imports aren't robust in terms of forward-compatibility. > > Did you try a .hs-boot file with your self-import trick? Not yet From abela at chalmers.se Mon Sep 29 08:57:19 2014 From: abela at chalmers.se (Andreas Abel) Date: Mon, 29 Sep 2014 10:57:19 +0200 Subject: Aliasing current module qualifier In-Reply-To: <87sija4xt1.fsf@gmail.com> References: <8761g66dqf.fsf@gnu.org> <54291BB0.6060907@chalmers.se> <87sija4xt1.fsf@gmail.com> Message-ID: <54291EEF.7020106@chalmers.se> The other two work arounds are 1. Explicit import lists for the stuff you need. 2. Explicit export list for your module (which you do), and internally use non-overloaded identifiers. module AnnoyinglyLongModuleName ( AnnoyinglyLongModuleName.length , AnnoyinglyLongModuleName.null ) where length = length' null = null' length' :: a -> Int length' _ = 0 null' :: a -> Bool null' = (== 0) . length' On 29.09.2014 10:48, Herbert Valerio Riedel wrote: > On 2014-09-29 at 10:43:28 +0200, Andreas Abel wrote: >> Indeed, being able to introduce a short name for the current module, >> or having a fixed short name like 'This' or 'Self' would be neat. >> >> The standard workaround for your example would be >> >> import Prelude hiding (length,null) > > That won't work though, because what I failed to mention is that I > needed this (while avoiding CPP) to cope with external modules growing > their exports lists, such as Data.Foldable starting to export 'length' > and 'null' in base-4.8.0.0 > > Moreover, hiding a non-existent symbol is a warning in recent GHC's but > a hard error in older GHCs, so that's not an option either if you want > to avoid CPP, support GHCs back to 7.0, and be -Werror-clean. > > More generally, 'hiding'-imports aren't robust in terms of > forward-compatibility. > >> >> Did you try a .hs-boot file with your self-import trick? > > Not yet > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From mail at joachim-breitner.de Mon Sep 29 09:11:56 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Sep 2014 11:11:56 +0200 Subject: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a) In-Reply-To: <20140928130739.F35543A002@ghc.haskell.org> References: <20140928130739.F35543A002@ghc.haskell.org> Message-ID: <1411981916.13710.4.camel@joachim-breitner.de> Hi, Am Sonntag, den 28.09.2014, 13:07 +0000 schrieb git at git.haskell.org: > commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa > Author: Herbert Valerio Riedel > Date: Sun Sep 28 13:02:53 2014 +0200 > > Extend `Foldable` class with `length` and `null` methods > > This completes the `Foldable` class by two important operations which > this way can be optimised for the underlying structure more easily. > > A minor fix for the `containers` submodule was needed to due name clash > > Addresses #9621 > > Reviewed By: ekmett, dfeuer, austin > > Differential Revision: https://phabricator.haskell.org/D250 this broke nofib: ==nofib== para: time to compile Main follows... /data1/ghc-builder/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -c Main.lhs -o Main.o Main.lhs:517:32: No instance for (Foldable t0) arising from a use of ?step? The type variable ?t0? is ambiguous Relevant bindings include par1' :: [t0 a] -> [[t0 a]] (bound at Main.lhs:516:2) Note: there are several potential instances: instance Foldable ((,) a) -- Defined in ?Data.Foldable? instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ?Data.Foldable? instance Foldable (Either a) -- Defined in ?Data.Foldable? ...plus three others In the first argument of ?fold1?, namely ?step? In the second argument of ?(.)?, namely ?fold1 step start? In the second argument of ?(.)?, namely ?minWith cost . fold1 step start? <> Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Mon Sep 29 09:19:18 2014 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 29 Sep 2014 11:19:18 +0200 Subject: [commit: ghc] master: Extend `Foldable` class with `length` and `null` methods (e5cca4a) In-Reply-To: <1411981916.13710.4.camel@joachim-breitner.de> (Joachim Breitner's message of "Mon, 29 Sep 2014 11:11:56 +0200") References: <20140928130739.F35543A002@ghc.haskell.org> <1411981916.13710.4.camel@joachim-breitner.de> Message-ID: <877g0m4wdl.fsf@gmail.com> Hello Austin, As this is already the 2nd time I broke nofib w/o noticing... can we please add building (not necessarily running, i.e. NoFibRuns=0 would be enough) nofib to the Phabricator build-process? Cheers, hvr On 2014-09-29 at 11:11:56 +0200, Joachim Breitner wrote: [...] > Am Sonntag, den 28.09.2014, 13:07 +0000 schrieb git at git.haskell.org: >> commit e5cca4ab246ca2d1ecdd7c39eefd3157547cb6aa >> Author: Herbert Valerio Riedel >> Date: Sun Sep 28 13:02:53 2014 +0200 >> >> Extend `Foldable` class with `length` and `null` methods [...] > > this broke nofib: From thomasmiedema at gmail.com Mon Sep 29 09:40:24 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 29 Sep 2014 11:40:24 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> <87bnq0wwvd.fsf@gmail.com> Message-ID: > > > > 3. Why is ghc-tarballs a git repository? That does not seem very wise. >> [...] >> > Could we have a stable folder under haskell.org/ to put the files in, >> to >> > make sure that they never go away, and just wget/curl them from there? >> >> http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 >> > > Hmm, that was a while ago. Whom should I contact to get the files deployed > under haskell.org? > Here's a different solution to the 'big binary blobs' problem: * Keep the ghc-tarballs git repository, and add it as a submodule * Make sure it doesn't get cloned by default git config -f .gitmodules submodule.ghc-tarballs.update none * Windows developers run (after initial clone --recursive of the ghc repository, one time): git config submodule.ghc-tarballs.update checkout git submodule update --depth=1 * After that, windows developers run the normal: git submodule update The advantages are: * only the most recent ghc-tarballs commit gets cloned initially * subsequent 'git submodule update' runs will make sure always the most recent version of ghc-tarballs is available * full history of ghc-tarballs is tracked, easier bisecting * no extra scripts needed I don't know how much space overhead git adds. wget-ting just the files themselves might still be faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Sep 29 09:41:43 2014 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 29 Sep 2014 11:41:43 +0200 Subject: Building ghc on Windows with msys2 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF22217EF2@DB3PRD3001MB020.064d.mgd.msft.net> <87bnq0wwvd.fsf@gmail.com> Message-ID: Forgot to add. Here is a script I used to test this approach, using libffi-tarballs as an example: https://gist.github.com/thomie/260755a5ab79f020fb79 On Mon, Sep 29, 2014 at 11:40 AM, Thomas Miedema wrote: > >> > 3. Why is ghc-tarballs a git repository? That does not seem very wise. >>> [...] >>> > Could we have a stable folder under haskell.org/ to put the files in, >>> to >>> > make sure that they never go away, and just wget/curl them from there? >>> >>> http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 >>> >> >> Hmm, that was a while ago. Whom should I contact to get the files >> deployed under haskell.org? >> > > Here's a different solution to the 'big binary blobs' problem: > > * Keep the ghc-tarballs git repository, and add it as a submodule > * Make sure it doesn't get cloned by default > git config -f .gitmodules submodule.ghc-tarballs.update none > * Windows developers run (after initial clone --recursive of the ghc > repository, one time): > git config submodule.ghc-tarballs.update checkout > git submodule update --depth=1 > * After that, windows developers run the normal: > git submodule update > > The advantages are: > * only the most recent ghc-tarballs commit gets cloned initially > * subsequent 'git submodule update' runs will make sure always the most > recent version of ghc-tarballs is available > * full history of ghc-tarballs is tracked, easier bisecting > * no extra scripts needed > > I don't know how much space overhead git adds. wget-ting just the files > themselves might still be faster. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Sep 29 09:52:28 2014 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 29 Sep 2014 11:52:28 +0200 Subject: Aliasing current module qualifier In-Reply-To: <8761g66dqf.fsf@gnu.org> References: <8761g66dqf.fsf@gnu.org> Message-ID: <201409291152.28926.jan.stolarek@p.lodz.pl> On a somewhat related note, I'd love to be able to do this in Haskell: import Basics.Nat renaming (_?_ to _??_) (this is taken from Agda). Janek Dnia poniedzia?ek, 29 wrze?nia 2014, Herbert Valerio Riedel napisa?: > Hello *, > > Here's a situation I've encountered recently, which mades me wish to be > able to define a local alias (in order to avoid CPP use). Consider the > following stupid module: > > > module AnnoyinglyLongModuleName > ( AnnoyinglyLongModuleName.length > , AnnoyinglyLongModuleName.null > ) where > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . AnnoyinglyLongModuleName.length > > > Now it'd be great if I could do the following instead: > > module AnnoyinglyLongModuleName (M.length, M.null) where > > import AnnoyinglyLongModuleName as M -- <- does not work > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . M.length > > However, if I try to compile this, GHC complains about > > AnnoyinglyLongModuleName.hs:4:1: > Bad interface file: AnnoyinglyLongModuleName.hi > AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No > such file or directory) > > while GHCi tells me: > > Module imports form a cycle: > module ?AnnoyinglyLongModuleName? (AnnoyinglyLongModuleName.hs) > imports itself > > > Is there some other way (without CPP) to create a local alias for the > current module-name? If not, is there a reason GHC couldn't support this > special case of self-aliasing the current module name? > > > PS: Alternatively, this could be done as a language extension but that'd > require extending the Haskell grammar: > > module AnnoyinglyLongModuleName as M (M.length, M.null) where > > > Cheers, > hvr > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From ekmett at gmail.com Mon Sep 29 09:58:17 2014 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 29 Sep 2014 05:58:17 -0400 Subject: [commit: ghc] master: Set default-impl of `mapM`/`sequence` methods to `traverse`/`sequenceA` (f636faa) In-Reply-To: <1411976670.2677.0.camel@joachim-breitner.de> References: <20140927210732.436603A002@ghc.haskell.org> <1411976670.2677.0.camel@joachim-breitner.de> Message-ID: Hrmm. I wonder if that is in part caused by the inefficient use of sequence in https://github.com/ghc/nofib/blob/master/spectral/fibheaps/Main.lhs#L234 If that sequence . map is swapped for a traverse, what happens? -Edward On Mon, Sep 29, 2014 at 3:44 AM, Joachim Breitner wrote: > Hi, > > > Am Samstag, den 27.09.2014, 21:07 +0000 schrieb git at git.haskell.org: > > commit f636faa7b2b7fc1d0663f994ad08f365d39a746d > > Author: Herbert Valerio Riedel > > Date: Sat Sep 27 22:55:19 2014 +0200 > > > > Set default-impl of `mapM`/`sequence` methods to > `traverse`/`sequenceA` > > > > This is made possible by the AMP, as we don't need the `WrappedMonad` > > helper for that anymore. > > according to > > http://ghcspeed-nomeata.rhcloud.com/changes/?rev=f636faa7b2b7fc1d0663f994ad08f365d39a746d&exe=2&env=nomeata%27s%20buildbot > this has caused a 11% regression in fibheaps allocation: > > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/allocs/fibheaps&env=1#/?exe=2&base=2+68&ben=nofib/allocs/fibheaps&env=1&revs=50&equid=on > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Maeder at dfki.de Mon Sep 29 15:07:05 2014 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon, 29 Sep 2014 17:07:05 +0200 Subject: Aliasing current module qualifier In-Reply-To: <8761g66dqf.fsf@gnu.org> References: <8761g66dqf.fsf@gnu.org> Message-ID: <54297599.2030601@dfki.de> Hi, rather than disambiguating a name from the current module by an abbreviated module name, I would prefer a disambiguation as is done for local names that shadows existing bindings. Then only imported names would need to be qualified (possibly using shorter module names). So names of the current module would simple shadow unqualified imported names. I think, that would only make previously ambiguous modules compile. However, this does not help for the case when the whole module plus some imported names need to be exported. module AnnoyinglyLongModuleName ( module AnnoyinglyLongModuleName , ... ) where (Without re-exports the whole export list could be omitted) Cheers Christian Am 29.09.2014 um 10:19 schrieb Herbert Valerio Riedel: > Hello *, > > Here's a situation I've encountered recently, which mades me wish to be > able to define a local alias (in order to avoid CPP use). Consider the > following stupid module: > > > module AnnoyinglyLongModuleName > ( AnnoyinglyLongModuleName.length > , AnnoyinglyLongModuleName.null > ) where > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . AnnoyinglyLongModuleName.length > > > Now it'd be great if I could do the following instead: > > module AnnoyinglyLongModuleName (M.length, M.null) where > > import AnnoyinglyLongModuleName as M -- <- does not work > > length :: a -> Int > length _ = 0 > > null :: a -> Bool > null = (== 0) . M.length > > However, if I try to compile this, GHC complains about > > AnnoyinglyLongModuleName.hs:4:1: > Bad interface file: AnnoyinglyLongModuleName.hi > AnnoyinglyLongModuleName.hi: openBinaryFile: does not exist (No such file or directory) > > while GHCi tells me: > > Module imports form a cycle: > module ?AnnoyinglyLongModuleName? (AnnoyinglyLongModuleName.hs) imports itself > > > Is there some other way (without CPP) to create a local alias for the > current module-name? If not, is there a reason GHC couldn't support this > special case of self-aliasing the current module name? > > > PS: Alternatively, this could be done as a language extension but that'd > require extending the Haskell grammar: > > module AnnoyinglyLongModuleName as M (M.length, M.null) where > > > Cheers, > hvr > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > From alan.zimm at gmail.com Mon Sep 29 20:38:45 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 29 Sep 2014 22:38:45 +0200 Subject: Feedback request for #9628 AST Annotations Message-ID: Hi All I am looking for some input on #9628 for source annotations. The intent behind this is to make it easier for tool developers to add extra information to the AST. This is to assist in structured editing or other source to source conversions, such as refactoring. One of the use cases would be to maintain the ParsedSource as tightly coupled to the editor, where changes would be made directly to the AST and only indirectly to the text source. This is the approach enabled by structured haskell mode, or demonstrated in lamdu. Ideally it should be possible to perform a change to the ParsedSource, and then submit it to the renamer and typechecker for error and warning feedback. As such the renamer / typechecker should be able to accept the annotated AST. Eventually this process should be incremental, since a given edit takes place in a structured way in a single position at a time, so it should be possible to identify which part of previously done work is invalidated by it and needs to be redone. This would happen in the context of a ghci session operating as a server. In order to lay the initial groundwork for this, I have updated the AST in hsSyn to replace all of the `Located` elements with `GenLocated l`, where `l` is constrained to be a member of class `ApiAnnotation`. class (Ord l, Outputable l, OutputableBndr l) => ApiAnnotation l where annGetSpan :: l -> SrcSpan annSetSpan :: l -> SrcSpan -> l annNoSpan :: l This guarantees that the annotation does in fact keep a `SrcSpan` in it. I have also worked this through the renamer, typechecker, and desugarer, and the monad for core. I have kept the `Located` / `GenLocated SrcSpan` boundary for the parser, and within the `RdrName`,`Name`,`Id` types. In this context the hooks become especially important, but they need to get the annotation type parameter. It seemed extreme to force the `DynamicFlags` to have to have the type parameter, so I am proposing to move the hooks to `HscEnv`, which needs a type parameter, even as a phantom type, to make sure that the right data structures are instantiated in the monads for the various passes. This is a big change, and I am very much working in the dark, so I would love some feedback or discussion. 1. Is this change too big, should I scale it back to just update the HsSyn structures and then lock it down to Located SrcSpan for all the rest? 2. Will the ApiAnnotation constraint and resolution cause performance degradation? 2. Is it ok to move the hooks into HscEnv? 3. In order to have a single session for a project, it needs a single annotation parameter. To support this the parser needs to produce annotated output. It should be a simple case of updating the L0/L1/LL macros and production types. Does it make sense to do this? This is intended to be an enabling change, without changing the structure of any code or the AST. A later change would introduce additional annotations in HsSyn to track the locations of the various keywords and other punctuation so that exactly regenerating source is much easier, without requiring extensive examiniation of the tokens. References 1. https://ghc.haskell.org/trac/ghc/ticket/9628 2. https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations 3. https://phabricator.haskell.org/D246 4. https://github.com/alanz/ghc/commits/wip/ast-ann-location Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Mon Sep 29 21:02:11 2014 From: john at repetae.net (John Meacham) Date: Mon, 29 Sep 2014 14:02:11 -0700 Subject: Aliasing current module qualifier In-Reply-To: References: <8761g66dqf.fsf@gnu.org> Message-ID: You don't need a new language construct, what i do is: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglongLongModuleName as M I think ghc would need to be extended a little to make this convienient as it doesn't handle recursive module imports as transparently. John On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery wrote: > On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel > wrote: > >> Now it'd be great if I could do the following instead: >> >> module AnnoyinglyLongModuleName (M.length, M.null) where >> >> import AnnoyinglyLongModuleName as M -- <- does not work >> > > I think if I wanted this syntax, I'd go for: > > module AnnoyinglyLongModuleName as M where ... > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- John Meacham - http://notanumber.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue Sep 30 00:58:37 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 29 Sep 2014 17:58:37 -0700 Subject: Feedback request for #9628 AST Annotations In-Reply-To: References: Message-ID: <1412038564-sup-8892@sabre> Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45 -0700: > 1. Is this change too big, should I scale it back to just update the > HsSyn structures and then lock it down to Located SrcSpan for all > the rest? I don't claim to speak for the rest of the GHC developers, but I think this change is too big. I am almost tempted to say that we shouldn't add the type parameter at all, and do something else (maybe Backpack can let us extend SrcSpan in a modular way, or even use a dynamically typed map for annotations.) Edward From eir at cis.upenn.edu Tue Sep 30 02:04:28 2014 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 29 Sep 2014 22:04:28 -0400 Subject: Feedback request for #9628 AST Annotations In-Reply-To: <1412038564-sup-8892@sabre> References: <1412038564-sup-8892@sabre> Message-ID: I'm only speaking up because Alan is specifically requesting feedback: I'm really ambivalent about this. I agree with Edward that this is a big change and adds permanent noise in a lot of places. But, I also really respect the goal here -- better tool support. Is it worthwhile to do this using a dynamically typed bit (using Typeable and such), which would avoid the noise? Maybe. What do other languages do? Do we know what, say, Agda does to get such tight coupling with an editor? Does, say, Eclipse have such a chummy relationship with a Java compiler to do its refactoring, or is that separately implemented? Haskell/GHC is not the first project to have this problem, and there's plenty of solutions out there. And, unlike most other times, I don't think Haskell is exceptional in this regard (there's nothing very special about Haskell's AST, maybe beyond indentation-awareness), so we can probably adopt other solutions nicely. Richard On Sep 29, 2014, at 8:58 PM, "Edward Z. Yang" wrote: > Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45 -0700: >> 1. Is this change too big, should I scale it back to just update the >> HsSyn structures and then lock it down to Located SrcSpan for all >> the rest? > > I don't claim to speak for the rest of the GHC developers, but I think > this change is too big. I am almost tempted to say that we shouldn't > add the type parameter at all, and do something else (maybe Backpack > can let us extend SrcSpan in a modular way, or even use a dynamically > typed map for annotations.) > > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From ezyang at mit.edu Tue Sep 30 03:30:59 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 29 Sep 2014 20:30:59 -0700 Subject: Feedback request for #9628 AST Annotations In-Reply-To: References: <1412038564-sup-8892@sabre> Message-ID: <1412047789-sup-9682@sabre> Excerpts from Richard Eisenberg's message of 2014-09-29 19:04:28 -0700: > What do other languages do? Do we know what, say, Agda does to get such tight coupling with an editor? Does, say, Eclipse have such a chummy relationship with a Java compiler to do its refactoring, or is that separately implemented? Eclipse literally has its own Java compiler for development in the IDE. I get the feeling this is not an uncommon pattern... Cheers, Edward From simonpj at microsoft.com Tue Sep 30 09:19:18 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Sep 2014 09:19:18 +0000 Subject: Feedback request for #9628 AST Annotations In-Reply-To: References: <1412038564-sup-8892@sabre> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2223B4EC@DB3PRD3001MB020.064d.mgd.msft.net> I'm anxious about it being too big a change too. I'd be up for it if we had several "customers" all saying "yes, this is precisely what we need to make our usage of the GHC API far far easier". With enough detail so we can understand their use-case. Otherwise I worry that we might go to a lot of effort to solve the wrong problem; or to build a solution that does not, in the end, work for the actual use-case. Another way to tackle this would be to ensure that syntax tree nodes have a "node-key" (a bit like their source location) that clients could use in a finite map, to map node-key to values of their choice. I have not reviewed your patch in detail, but it's uncomfortable that the 'l' parameter gets into IfGblEnv and DsM. That doesn't smell right. Ditto DynFlags/HscEnv, though I think here that you are right that the "hooks" interface is very crucial. After all, the WHOLE POINT is too make the client interface more flexible. I would consult Luite and Edsko, who were instrumental in designing the new hooks interface https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks (I'm not sure if that page is up to date, but I hope so) A good way to proceed might be to identify some of the big users of the GHC API (I'm sure I don't know them all), discuss with them what would help them, and share the results on a wiki page. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 30 September 2014 03:04 | To: Edward Z. Yang | Cc: ghc-devs at haskell.org | Subject: Re: Feedback request for #9628 AST Annotations | | I'm only speaking up because Alan is specifically requesting feedback: | I'm really ambivalent about this. I agree with Edward that this is a | big change and adds permanent noise in a lot of places. But, I also | really respect the goal here -- better tool support. Is it worthwhile | to do this using a dynamically typed bit (using Typeable and such), | which would avoid the noise? Maybe. | | What do other languages do? Do we know what, say, Agda does to get | such tight coupling with an editor? Does, say, Eclipse have such a | chummy relationship with a Java compiler to do its refactoring, or is | that separately implemented? Haskell/GHC is not the first project to | have this problem, and there's plenty of solutions out there. And, | unlike most other times, I don't think Haskell is exceptional in this | regard (there's nothing very special about Haskell's AST, maybe beyond | indentation-awareness), so we can probably adopt other solutions | nicely. | | Richard | | On Sep 29, 2014, at 8:58 PM, "Edward Z. Yang" wrote: | | > Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45 | -0700: | >> 1. Is this change too big, should I scale it back to just update | the | >> HsSyn structures and then lock it down to Located SrcSpan for all | >> the rest? | > | > I don't claim to speak for the rest of the GHC developers, but I | think | > this change is too big. I am almost tempted to say that we | shouldn't | > add the type parameter at all, and do something else (maybe Backpack | > can let us extend SrcSpan in a modular way, or even use a | dynamically | > typed map for annotations.) | > | > Edward | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From alan.zimm at gmail.com Tue Sep 30 12:04:31 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 30 Sep 2014 14:04:31 +0200 Subject: Feedback request for #9628 AST Annotations In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF2223B4EC@DB3PRD3001MB020.064d.mgd.msft.net> References: <1412038564-sup-8892@sabre> <618BE556AADD624C9C918AA5D5911BEF2223B4EC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I tend to agree that this change is much too intrusive for what it attempts to do. I think the concept of a node key could be workable, and ties in to the approach I am taking in ghc-exactprint [1], which uses a SrcSpan together with node type as the annotation key. [1] https://github.com/alanz/ghc-exactprint On Tue, Sep 30, 2014 at 11:19 AM, Simon Peyton Jones wrote: > I'm anxious about it being too big a change too. > > I'd be up for it if we had several "customers" all saying "yes, this is > precisely what we need to make our usage of the GHC API far far easier". > With enough detail so we can understand their use-case. > > Otherwise I worry that we might go to a lot of effort to solve the wrong > problem; or to build a solution that does not, in the end, work for the > actual use-case. > > Another way to tackle this would be to ensure that syntax tree nodes have > a "node-key" (a bit like their source location) that clients could use in a > finite map, to map node-key to values of their choice. > > I have not reviewed your patch in detail, but it's uncomfortable that the > 'l' parameter gets into IfGblEnv and DsM. That doesn't smell right. > > Ditto DynFlags/HscEnv, though I think here that you are right that the > "hooks" interface is very crucial. After all, the WHOLE POINT is too make > the client interface more flexible. I would consult Luite and Edsko, who > were instrumental in designing the new hooks interface > https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks > (I'm not sure if that page is up to date, but I hope so) > > A good way to proceed might be to identify some of the big users of the > GHC API (I'm sure I don't know them all), discuss with them what would help > them, and share the results on a wiki page. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Richard Eisenberg > | Sent: 30 September 2014 03:04 > | To: Edward Z. Yang > | Cc: ghc-devs at haskell.org > | Subject: Re: Feedback request for #9628 AST Annotations > | > | I'm only speaking up because Alan is specifically requesting feedback: > | I'm really ambivalent about this. I agree with Edward that this is a > | big change and adds permanent noise in a lot of places. But, I also > | really respect the goal here -- better tool support. Is it worthwhile > | to do this using a dynamically typed bit (using Typeable and such), > | which would avoid the noise? Maybe. > | > | What do other languages do? Do we know what, say, Agda does to get > | such tight coupling with an editor? Does, say, Eclipse have such a > | chummy relationship with a Java compiler to do its refactoring, or is > | that separately implemented? Haskell/GHC is not the first project to > | have this problem, and there's plenty of solutions out there. And, > | unlike most other times, I don't think Haskell is exceptional in this > | regard (there's nothing very special about Haskell's AST, maybe beyond > | indentation-awareness), so we can probably adopt other solutions > | nicely. > | > | Richard > | > | On Sep 29, 2014, at 8:58 PM, "Edward Z. Yang" wrote: > | > | > Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45 > | -0700: > | >> 1. Is this change too big, should I scale it back to just update > | the > | >> HsSyn structures and then lock it down to Located SrcSpan for all > | >> the rest? > | > > | > I don't claim to speak for the rest of the GHC developers, but I > | think > | > this change is too big. I am almost tempted to say that we > | shouldn't > | > add the type parameter at all, and do something else (maybe Backpack > | > can let us extend SrcSpan in a modular way, or even use a > | dynamically > | > typed map for annotations.) > | > > | > Edward > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > http://www.haskell.org/mailman/listinfo/ghc-devs > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue Sep 30 12:18:06 2014 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 30 Sep 2014 14:18:06 +0200 Subject: Aliasing current module qualifier In-Reply-To: References: <8761g66dqf.fsf@gnu.org> Message-ID: Hello, What semantics are you using for recursive modules? As far as I see, if you take a least fixed point semantics (e.g. as described in "A Formal Specification for the Haskell 98 Module System", http://yav.github.io/publications/modules98.pdf ) this program is incorrect as the module does not export anything. While this may seem a bit counter intuitive at first, this semantics has the benefit of being precise, easily specified, and uniform (e.g it does not require any special treatment of the " current " module). As an example, consider the following variation of your program, where I just moved the definition in a sperate (still recursive) module: module A (M.x) where import B as M module B (M.x) where import A as M x = True I think that it'd be quite confusing if a single recursive module worked differently then a larger recursive group, but it is not at all obvious why B should export 'x'. And for those who like this kind of puzzle: what should happen if 'A' also had a definition for 'x'? Iavor On Sep 29, 2014 11:02 PM, "John Meacham" wrote: > You don't need a new language construct, what i do is: > > module AnnoyinglyLongModuleName (M.length, M.null) where > > import AnnoyinglongLongModuleName as M > > I think ghc would need to be extended a little to make this convienient as > it doesn't handle recursive module imports as transparently. > > John > > On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery > wrote: > >> On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel >> wrote: >> >>> Now it'd be great if I could do the following instead: >>> >>> module AnnoyinglyLongModuleName (M.length, M.null) where >>> >>> import AnnoyinglyLongModuleName as M -- <- does not work >>> >> >> I think if I wanted this syntax, I'd go for: >> >> module AnnoyinglyLongModuleName as M where ... >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > > -- > John Meacham - http://notanumber.net/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Sep 30 18:20:17 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Sep 2014 18:20:17 +0000 Subject: Aliasing current module qualifier In-Reply-To: References: <8761g66dqf.fsf@gnu.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF2223D16C@DB3PRD3001MB020.064d.mgd.msft.net> If there is to be such a language feature, I strongly feel it should be via something like module Long.Name.M( f, g, h ) as K where ... I do not want to try to piggy-back on the possible meaning of a self-import; it?s just asking for trouble, as Iavor points out. Using ?as M? in the module header would be simple. It is easy to explain and fairly easy to implement. I don?t think there are any knock-on complications. So if enough people want it, and someone is prepared to implement it (with a language extension flag of course), then I?d be OK with that. I?m unsure that it?s worth the effort, but I?m happy to let users decide. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Iavor Diatchki Sent: 30 September 2014 13:18 To: john at repetae.net Cc: GHC Users Mailing List; ghc-devs; Herbert Valerio Riedel Subject: Re: Aliasing current module qualifier Hello, What semantics are you using for recursive modules? As far as I see, if you take a least fixed point semantics (e.g. as described in "A Formal Specification for the Haskell 98 Module System", http://yav.github.io/publications/modules98.pdf ) this program is incorrect as the module does not export anything. While this may seem a bit counter intuitive at first, this semantics has the benefit of being precise, easily specified, and uniform (e.g it does not require any special treatment of the " current " module). As an example, consider the following variation of your program, where I just moved the definition in a sperate (still recursive) module: module A (M.x) where import B as M module B (M.x) where import A as M x = True I think that it'd be quite confusing if a single recursive module worked differently then a larger recursive group, but it is not at all obvious why B should export 'x'. And for those who like this kind of puzzle: what should happen if 'A' also had a definition for 'x'? Iavor On Sep 29, 2014 11:02 PM, "John Meacham" > wrote: You don't need a new language construct, what i do is: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglongLongModuleName as M I think ghc would need to be extended a little to make this convienient as it doesn't handle recursive module imports as transparently. John On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery > wrote: On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel > wrote: Now it'd be great if I could do the following instead: module AnnoyinglyLongModuleName (M.length, M.null) where import AnnoyinglyLongModuleName as M -- <- does not work I think if I wanted this syntax, I'd go for: module AnnoyinglyLongModuleName as M where ... -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- John Meacham - http://notanumber.net/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Tue Sep 30 18:47:53 2014 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 30 Sep 2014 20:47:53 +0200 Subject: Feedback request for #9628 AST Annotations In-Reply-To: References: <1412038564-sup-8892@sabre> <618BE556AADD624C9C918AA5D5911BEF2223B4EC@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On further reflection of the goals for the annotation, I would like to put forward the following proposal for comment Instead of physically placing a "node-key" in each AST Node, a virtual node key can be generated from any `GenLocated SrcSpan e' comprising a combination of the `SrcSpan` value and a unique identifier from the constructor for `e`, perhaps using its `TypeRep`, since the entire AST derives Typeable. To further reduce the intrusiveness, a base Annotation type can be defined that captures the location of noise tokens for each AST constructor. This can then be emitted from the parser, if the appropriate flag is set to enable it. So data ApiAnnKey = AK SrcSpan TypeRep mkApiAnnKey :: (Located e) -> ApiAnnKey mkApiAnnKey = ... data Ann = .... | AnnHsLet SrcSpan -- of the word "let" SrcSpan -- of the word "in" | AnnHsDo SrcSpan -- of the word "do" And then in the parser | 'let' binds 'in' exp { mkAnnHsLet $1 $3 (LL $ HsLet (unLoc $2) $4) } The helper is mkAnnHsLet :: Located a -> Located b -> LHsExpr RdrName -> P (LHsExpr RdrName) mkAnnHsLet (L l_let _) (L l_in _) e = do addAnnotation (mkAnnKey e) (AnnHsLet l_let l_in) return e; The Parse Monad would have to accumulate the annotations to be returned at the end, if called with the appropriate flag. There will be some boilerplate in getting the annotations and helper functions defined, but it will not pollute the rest. This technique can also potentially be backported to support older GHC versions via a modification to ghc-parser. https://hackage.haskell.org/package/ghc-parser Regards Alan On Tue, Sep 30, 2014 at 2:04 PM, Alan & Kim Zimmerman wrote: > I tend to agree that this change is much too intrusive for what it > attempts to do. > > I think the concept of a node key could be workable, and ties in to the > approach I am taking in ghc-exactprint [1], which uses a SrcSpan together > with node type as the annotation key. > > [1] https://github.com/alanz/ghc-exactprint > > > On Tue, Sep 30, 2014 at 11:19 AM, Simon Peyton Jones < > simonpj at microsoft.com> wrote: > >> I'm anxious about it being too big a change too. >> >> I'd be up for it if we had several "customers" all saying "yes, this is >> precisely what we need to make our usage of the GHC API far far easier". >> With enough detail so we can understand their use-case. >> >> Otherwise I worry that we might go to a lot of effort to solve the wrong >> problem; or to build a solution that does not, in the end, work for the >> actual use-case. >> >> Another way to tackle this would be to ensure that syntax tree nodes have >> a "node-key" (a bit like their source location) that clients could use in a >> finite map, to map node-key to values of their choice. >> >> I have not reviewed your patch in detail, but it's uncomfortable that the >> 'l' parameter gets into IfGblEnv and DsM. That doesn't smell right. >> >> Ditto DynFlags/HscEnv, though I think here that you are right that the >> "hooks" interface is very crucial. After all, the WHOLE POINT is too make >> the client interface more flexible. I would consult Luite and Edsko, who >> were instrumental in designing the new hooks interface >> https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks >> (I'm not sure if that page is up to date, but I hope so) >> >> A good way to proceed might be to identify some of the big users of the >> GHC API (I'm sure I don't know them all), discuss with them what would help >> them, and share the results on a wiki page. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> | Richard Eisenberg >> | Sent: 30 September 2014 03:04 >> | To: Edward Z. Yang >> | Cc: ghc-devs at haskell.org >> | Subject: Re: Feedback request for #9628 AST Annotations >> | >> | I'm only speaking up because Alan is specifically requesting feedback: >> | I'm really ambivalent about this. I agree with Edward that this is a >> | big change and adds permanent noise in a lot of places. But, I also >> | really respect the goal here -- better tool support. Is it worthwhile >> | to do this using a dynamically typed bit (using Typeable and such), >> | which would avoid the noise? Maybe. >> | >> | What do other languages do? Do we know what, say, Agda does to get >> | such tight coupling with an editor? Does, say, Eclipse have such a >> | chummy relationship with a Java compiler to do its refactoring, or is >> | that separately implemented? Haskell/GHC is not the first project to >> | have this problem, and there's plenty of solutions out there. And, >> | unlike most other times, I don't think Haskell is exceptional in this >> | regard (there's nothing very special about Haskell's AST, maybe beyond >> | indentation-awareness), so we can probably adopt other solutions >> | nicely. >> | >> | Richard >> | >> | On Sep 29, 2014, at 8:58 PM, "Edward Z. Yang" wrote: >> | >> | > Excerpts from Alan & Kim Zimmerman's message of 2014-09-29 13:38:45 >> | -0700: >> | >> 1. Is this change too big, should I scale it back to just update >> | the >> | >> HsSyn structures and then lock it down to Located SrcSpan for all >> | >> the rest? >> | > >> | > I don't claim to speak for the rest of the GHC developers, but I >> | think >> | > this change is too big. I am almost tempted to say that we >> | shouldn't >> | > add the type parameter at all, and do something else (maybe Backpack >> | > can let us extend SrcSpan in a modular way, or even use a >> | dynamically >> | > typed map for annotations.) >> | > >> | > Edward >> | > _______________________________________________ >> | > ghc-devs mailing list >> | > ghc-devs at haskell.org >> | > http://www.haskell.org/mailman/listinfo/ghc-devs >> | >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at repetae.net Tue Sep 30 20:05:03 2014 From: john at repetae.net (John Meacham) Date: Tue, 30 Sep 2014 13:05:03 -0700 Subject: Aliasing current module qualifier In-Reply-To: References: <8761g66dqf.fsf@gnu.org> Message-ID: Yes, that is the semantics I use for recursive module imports in jhc. And you are right in that it does not accept those examples due to being unable to bootstrap the least fixed point. How would the 'as M' proposal interact? Would it actually be new entries in the name table or rewritten as a macro to the current module name? I can see some edge cases where it makes a difference. I am thinking the easiest would be to populate entries for all the M.toplevel names where toplevel are the top level definitions of the module, will implement it and see how it shakes out. John On Tue, Sep 30, 2014 at 5:18 AM, Iavor Diatchki wrote: > Hello, > > What semantics are you using for recursive modules? As far as I see, if > you take a least fixed point semantics (e.g. as described in "A Formal > Specification for the Haskell 98 Module System", > http://yav.github.io/publications/modules98.pdf ) this program is > incorrect as the module does not export anything. > > While this may seem a bit counter intuitive at first, this semantics has > the benefit of being precise, easily specified, and uniform (e.g it does > not require any special treatment of the " current " module). As an > example, consider the following variation of your program, where I just > moved the definition in a sperate (still recursive) module: > > module A (M.x) where > import B as M > > module B (M.x) where > import A as M > x = True > > I think that it'd be quite confusing if a single recursive module worked > differently then a larger recursive group, but it is not at all obvious why > B should export 'x'. And for those who like this kind of puzzle: what > should happen if 'A' also had a definition for 'x'? > > Iavor > On Sep 29, 2014 11:02 PM, "John Meacham" wrote: > >> You don't need a new language construct, what i do is: >> >> module AnnoyinglyLongModuleName (M.length, M.null) where >> >> import AnnoyinglongLongModuleName as M >> >> I think ghc would need to be extended a little to make this convienient >> as it doesn't handle recursive module imports as transparently. >> >> John >> >> On Mon, Sep 29, 2014 at 8:47 AM, Brandon Allbery >> wrote: >> >>> On Mon, Sep 29, 2014 at 4:19 AM, Herbert Valerio Riedel >>> wrote: >>> >>>> Now it'd be great if I could do the following instead: >>>> >>>> module AnnoyinglyLongModuleName (M.length, M.null) where >>>> >>>> import AnnoyinglyLongModuleName as M -- <- does not work >>>> >>> >>> I think if I wanted this syntax, I'd go for: >>> >>> module AnnoyinglyLongModuleName as M where ... >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allbery.b at gmail.com >>> ballbery at sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >>> >> >> >> -- >> John Meacham - http://notanumber.net/ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> -- John Meacham - http://notanumber.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Sep 30 20:10:05 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 30 Sep 2014 15:10:05 -0500 Subject: GHC Weekly news Message-ID: Hi *, Here's the latest weekly news post: https://ghc.haskell.org/trac/ghc/blog/weekly20140930 Included verbatim for those too lazy to open new tabs: ---------------- Hi *, Here's some news for y'all! Apologizes about the unavailability last week; the internet wasn't exactly a very fun place for a system administrator... So without delay, here's the current recap of the past two weeks: - Lots of merged code and code reviews have gone in, and a lot of commits: in the past two weeks since the last update, `ghc.git` has seen just over 100 commits, from about a dozen different developers. - As part of those patches, a significant amount of them have gone towards implementing the "Burning Bridges Proposal" or BBP for the `base` library. This is a set of changes to `base` that have generalized many parts of the API, by putting `Traversable` and `Foldable` in the Prelude. This required a bit of shoveling by Herbert, but now this is all now in GHC HEAD, and will be part of 7.10: - `Prelude` combinators, like `mapM`, have been generalized to the `Traversable` and `Foldable` classes. - Several other modules, like `Control.Monad` and `Data.List`, have been generalized to `Traversable` and `Foldable` where applicable. - `Control.Monad` combinators generalized to `Applicative` where possible. - Similarly, `MonadPlus` combinators like `guard` are generalized to `Alternative`. - `Foldable` has been extended with new methods, like `length` and `null`. - But also, GHC's compiler is now tab-free! That's right, after what seemed like a million years, a very large portion of the code has been detabbed, and `-fwarn-tabs` is now on by default in the GHC build. - There are an assortment of other changes: GHC's linker is not as loud[1], and various documentation improvements. - The windows build is broken *again* unfortunately, this time due to what seems to be a Cabal update, I think. Austin is once again on the case. - The HCAR draft for October has seen some nice improvements. If you're a developer, please amend things. If you're a user, read with eager anticipation of all the new features![2] - It turns out the new Applicative/Monad changes have unfortunately broken the `haskell98` and `haskell2010` packages, with an unclear migration strategy for the future: see #9590. For GHC 7.10, it seems the `haskell2010` packages will need to change to accomodate these standard deviations. If any users of the `haskell98` or `haskell2010` packages would speak up to help, that would be fantastic. The discussion will surely continue for a little bit - 7.10 is still a ways off. In miscellaneous news: - ghc.haskell.org may have been temporarily unavailable during this weekend due to an emergency downtime with our provider for a security update, but the window was quite small. - Relatedly (but not the exact same scenario), the internet also caught fire in several other places, requiring quite a lot of careful watching and remediation after the Bash "ShellShock" bug hit last week. And I think that sums it up quite nicely, folks! Closed tickets for the past two weeks include (there are a lot of them!): #9650, #7068, #5190, #5880, #8374, #9603, #3303, #3470, #3509, #781, #8115, #9641, #9191, #9515, #9326, #7987, #9634, #9576, #9612, #9635, #8593, #7544, #8529, #9338, #5794, #9535, #3646, #617, #8026, #8480, #8881, #9366, #8251, #7673, #8983, #8369, #8897, #8070, #9550, #9057, #9629, #8836, #8960, #8941, #9565, #9589, #5248, #8918, #9568, #9620, #1042, #9557, #7863, #5647, #9610, #5395, #9580, #9529, #4426, #9607, #9592, #8097, #9559, #9560, #4218, #9602, #9528, #9530, #9423, #9400, #1407, #9598, #9597. I'd like to mention that for the above tickets, a *huge* amount of them were closed by one of our newest contributors, **Thomas Miedema**, who went through the bug tracker and confirmed or closed a large majority of them. I lost track of how many. Thanks Thomas! [1] https://github.com/ghc/ghc/commit/9f7e3633c692dce75c27607131bd386178fb0fcf [2] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Sep 30 20:21:16 2014 From: austin at well-typed.com (Austin Seipp) Date: Tue, 30 Sep 2014 15:21:16 -0500 Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590 Message-ID: Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Tue Sep 30 20:25:08 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Sep 2014 20:25:08 +0000 Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF2223D825@DB3PRD3001MB020.064d.mgd.msft.net> I hate #1. Let's avoid if unless it's really crucial to some of our users. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Austin | Seipp | Sent: 30 September 2014 21:21 | To: ghc-devs at haskell.org; glasgow-haskell-users at haskell.org | Subject: The future of the haskell2010/haskell98 packages - AKA Trac | #9590 | | Hello developers, users, friends, | | I'd like you all to weigh in on something - a GHC bug report, that has | happened as a result of making Applicative a superclass of Monad: | | https://ghc.haskell.org/trac/ghc/ticket/9590 | | The very condensed version is this: because haskell2010/haskell98 | packages try to be fairly strictly conforming, they do not have | modules like Control.Applicative. | | Unfortunately, due to the way these packages are structured, many | things are simply re-exported from base, like `Monad`. But | `Applicative` is not, and cannot be imported if you use -XHaskell2010 | and the haskell2010 package. | | The net result here is that haskell98/haskell2010 are hopelessly | broken in the current state: it's impossible to define an instance of | `Monad`, because you cannot define an instance of `Applicative`, | because you can't import it in the first place! | | This leaves us in quite a pickle. | | So I ask: Friends, what do you think we should do? I am particularly | interested in users/developers of current Haskell2010 packages - not | just code that may *be* standard Haskell - code that implies a | dependency on it. | | There was a short discussion between me and Simon Marlow about this in | the morning, and again on IRC this morning between me, Duncan, Edward | K, and Herbert. | | Basically, I only see one of two options: | | - We could make GHC support both: a version of `Monad` without | `Applicative`, and one with it. This creates some complication in the | desugarer, where GHC takes care of `do` syntax (and thus needs to be | aware of `Monad`'s definition and location). But it is, perhaps, quite | doable. | | - We change both packages to export `Applicative` and follow the API | changes in `base` accordingly. | | Note that #1 above is contingent on three things: | | 1) There is interest in this actually happening, and these separate | APIs being supported. If there is not significant interest in | maintaining this, it's unclear if we should go for it. | | 2) It's not overly monstrously complex (I don't think it necessarily | will be, but it might be.) | | 3) You can't like `haskell2010` packages and `base` packages together | in the general case, but, AFAIK, this wasn't the case before either. | | I'd really appreciate your thoughts. This must be sorted out for 7.10 | somehow; the current situation is hopelessly busted. | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From mail at joachim-breitner.de Tue Sep 30 20:36:27 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 30 Sep 2014 22:36:27 +0200 Subject: Build time regressions Message-ID: <1412109387.2676.23.camel@joachim-breitner.de> Hi, the attached graph shows a noticable increase in build time caused by Update Cabal submodule & ghc-pkg to use new module re-export types author Edward Z. Yang https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae and only halfway mitigated by Update `binary` submodule in an attempt to address #9630 author Herbert Valerio Riedel https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bffb35f I am not sure if the improvement is related to the regression, but in any case: Edward, was such an increase expected by you? If not, can you explain it? Can it be avoided? Or maybe Cabal just became much larger... +38% in allocations when running haddock on it seems to confirm this. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: buildtime.png Type: image/png Size: 2019 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ezyang at mit.edu Tue Sep 30 20:54:51 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 30 Sep 2014 13:54:51 -0700 Subject: Build time regressions Message-ID: <1412110484-sup-5631@sabre> Hello Joachim, This was halfway known, but it sounds like we haven't solved it completely. The beginning of the sordid tale was when Cabal HEAD switched to using derived binary instances: https://ghc.haskell.org/trac/ghc/ticket/9583 SPJ fixed the infinite loop bug in the simplifier, but apparently the deriving binary generates a lot of code, meaning a lot of memory. https://ghc.haskell.org/trac/ghc/ticket/9630 hvr's fix was specifically to solve this problem. But it sounds like it didn't eliminate the regression entirely? If there's an unrelated regression, we should suss it out. It would be helpful if someone could revert just the deriving changes, and see if this reverts the compilation time. Edward Excerpts from Joachim Breitner's message of 2014-09-30 13:36:27 -0700: > Hi, > > the attached graph shows a noticable increase in build time caused by > > Update Cabal submodule & ghc-pkg to use new module re-export types > author Edward Z. Yang > https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae > > and only halfway mitigated by > > Update `binary` submodule in an attempt to address #9630 > author Herbert Valerio Riedel > https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bffb35f > > > I am not sure if the improvement is related to the regression, but in > any case: Edward, was such an increase expected by you? If not, can you > explain it? Can it be avoided? > > Or maybe Cabal just became much larger... +38% in allocations when > running haddock on it seems to confirm this. > > Greetings, > Joachim > From malcolm.wallace at me.com Tue Sep 30 21:00:57 2014 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Tue, 30 Sep 2014 22:00:57 +0100 Subject: The future of the haskell2010/haskell98 packages - AKA Trac #9590 In-Reply-To: References: Message-ID: <5F743CA1-227C-4F5C-B38E-1DD860659168@me.com> How about doing the honest thing, and withdrawing both packages in ghc-7.10? Haskell'98 is now 15 years old, and the 2010 standard was never really popular anyway. Regards, Malcolm On 30 Sep 2014, at 21:21, Austin Seipp wrote: Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users at haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users From simonpj at microsoft.com Tue Sep 30 22:25:13 2014 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 30 Sep 2014 22:25:13 +0000 Subject: Building ghc on Windows with msys2 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF2223DA32@DB3PRD3001MB020.064d.mgd.msft.net> Gintautas, and other folk building GHC on Windows, There has been some activity on the ?GHC on Windows? front, which is great. Some time ago I wrote: I would love it if you guys formed a GHC-on-Windows Task Force, who tried to make sure that the Windows experience was always good. At the moment we have lots of Windows users but very few who are willing to help make it work, the recipients of this email being honourable exceptions. but nothing really happened. Maybe this time it can! Possible member of such a task force are: ? Gintautas Miliauskas gintautas.miliauskas at gmail.com ? kyra kyrab at mail.ru ? Marek Wawrzos marek.28.93 at gmail.com ? Tamar Christina > ? Roman Kuznetsov > ? Randy Polen All we need is someone to act as convenor/coordinator and we are good to go. Would any of you be willing to play that role? An advantage of having a working group is that you can decide things. At the moment people often wait for GHC HQ to make a decision, and end up waiting a long time. It would be better if a working group was responsible for the GHC-on-Windows build and then if (say) you want to mandate msys2, you can go ahead and mandate it. Well, obviously consult ghc-devs for advice, but you are in the lead. Does that make sense? I think an early task is to replace what Neil Mitchell encountered: FIVE different wiki pages describing how to build GHC on Windows. We want just one! (Others can perhaps be marked ?out of date/archive? rather than deleted, but it should be clear which is the main choice.) I agree with using msys2 as the main choice. (I?m using it myself.) It may be that Gintautas?s page https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 is already sufficient. Although I?d like to see it tested by others. For example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas Gintautas?s page says nothing about that. Other small thoughts: ? We started including the ghc-tarball stuff because when we relied directly on the gcc that came with msys, we kept getting build failures because the gcc that some random person happened to be using did not work (e..g. they had a too-old or too-new version of msys). By using a single, fixed gcc, we avoided all this pain. ? I don?t know what a ?rubenvb? build is, but I think you can go ahead and say ?use X and Y in this way?. The important thing is that it should be reproducible, and not dependent on the particular Cygwin or gcc or whatever the that user happens to have installed. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gintautas Miliauskas Sent: 15 September 2014 21:58 To: ghc-devs at haskell.org Subject: Building ghc on Windows with msys2 Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwlato at gmail.com Tue Sep 30 23:44:32 2014 From: jwlato at gmail.com (John Lato) Date: Wed, 1 Oct 2014 07:44:32 +0800 Subject: Build time regressions In-Reply-To: <1412110484-sup-5631@sabre> References: <1412110484-sup-5631@sabre> Message-ID: Hi Edward, This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling generic serialization instances for some data structures. In our case, I also thought that INLINE functions were the cause of the problem, but it turns out they were not. We had a nested data structure, e.g. > data Foo { fooBar :: !Bar, ... } with Bar very large (~150 records). even when we explicitly NOINLINE'd the function that serialized Bar, GHC still created a very large helper function of the form: > serialize_foo :: Int# -> Int# -> ... where the arguments were the unboxed fields of the Bar structure, along with the other fields within Foo. It appears that even though the serialization function was NOINLINE'd, it simply created a Builder, and while combining the Builder's ghc saw the full structure. Our serializer uses blaze, but perhaps Binary's builder is similar enough the same thing could happen. Anyway, in our case the fix was to simply remove the bang pattern from the 'fooBar' record field. Then the serialize_foo function takes a Bar as an argument and serializes that. I'm not entirely sure why compilation takes so much longer otherwise. I've tried dumping the output of each simplifier phase and it clearly gets stuck at a certain point, but I didn't really debug in much detail so I don't recall the details. If you think this is related, I can investigate more thoroughly. Cheers, John L. On Wed, Oct 1, 2014 at 4:54 AM, Edward Z. Yang wrote: > Hello Joachim, > > This was halfway known, but it sounds like we haven't solved > it completely. > > The beginning of the sordid tale was when Cabal HEAD switched > to using derived binary instances: > https://ghc.haskell.org/trac/ghc/ticket/9583 > > SPJ fixed the infinite loop bug in the simplifier, but apparently > the deriving binary generates a lot of code, meaning a lot of > memory. https://ghc.haskell.org/trac/ghc/ticket/9630 > hvr's fix was specifically to solve this problem. > > But it sounds like it didn't eliminate the regression entirely? > If there's an unrelated regression, we should suss it out. It would > be helpful if someone could revert just the deriving changes, > and see if this reverts the compilation time. > > Edward > > Excerpts from Joachim Breitner's message of 2014-09-30 13:36:27 -0700: > > Hi, > > > > the attached graph shows a noticable increase in build time caused by > > > > Update Cabal submodule & ghc-pkg to use new module re-export types > > author Edward Z. Yang > > > https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae > > > > and only halfway mitigated by > > > > Update `binary` submodule in an attempt to address #9630 > > author Herbert Valerio Riedel > > > https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bffb35f > > > > > > I am not sure if the improvement is related to the regression, but in > > any case: Edward, was such an increase expected by you? If not, can you > > explain it? Can it be avoided? > > > > Or maybe Cabal just became much larger... +38% in allocations when > > running haddock on it seems to confirm this. > > > > Greetings, > > Joachim > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: