November 2014 - ghc-devs

Re: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
by Jan Stolarek 03 Nov '14

03 Nov '14

Perhaps this should be documented in the User's Guide? Janek Dnia niedziela, 2 listopada 2014, git(a)git.haskell.org napisał: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/c271e32eac65ee95ba1aacc72ed1b24b5 >8ef17ad/ghc > > >--------------------------------------------------------------- > > commit c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Sun Jan 26 11:36:23 2014 +0000 > > Add GHC.Prim.oneShot > > to allow the programer to explictitly set the oneShot flag. This helps > with #7994 and will be used in left folds. Also see > https://ghc.haskell.org/trac/ghc/wiki/OneShot > > This commit touches libraries/base/GHC/Event/Manager.hs (which used to > have a local definition of the name oneShot) to avoid a shadowing > error. > > Differential Revision: https://phabricator.haskell.org/D392 > > >--------------------------------------------------------------- > > c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > compiler/basicTypes/MkId.lhs | 42 > ++++++++++++++++++++-- compiler/prelude/PrelNames.lhs | > 3 +- > libraries/base/GHC/Event/Manager.hs | 6 ++-- > libraries/ghc-prim/GHC/Magic.hs | 11 +++++- > testsuite/.gitignore | 1 + > .../should_compile => simplCore/prog003}/Makefile | 0 > testsuite/tests/simplCore/prog003/OneShot1.hs | 21 +++++++++++ > testsuite/tests/simplCore/prog003/OneShot2.hs | 24 +++++++++++++ > .../simplCore/prog003/simplCore.oneShot.stderr | 21 +++++++++++ > .../simplCore/prog003/simplCore.oneShot.stdout | 1 + > testsuite/tests/simplCore/prog003/test.T | 7 ++++ > 11 files changed, 130 insertions(+), 7 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc c271e32eac65ee95ba1aacc72ed1b24b58ef17ad > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

ghc panic during build
by Gintautas Miliauskas 03 Nov '14

03 Nov '14

Just got this during a build: "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -O0 -this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty -package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -fno-warn-tabs -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -c libraries/base/./GHC/TypeLits.hs -o libraries/base/dist-install/build/GHC/TypeLits.o ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 7.9.20141031 for x86_64-unknown-mingw32): Ix{Int}.index: Index (2053) out of range ((0,10)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/TypeLits.o' failed I may have been building in a non-clean repository after a git pull though, could that have caused this? -- Gintautas Miliauskas

3 2

RE: thenIO removal
by David Feuer 03 Nov '14

03 Nov '14

Simon Peyton Jones wrote: > > It's not a big deal. > > You can probably replace both those bindIOName uses with bindMName (i.e > (>>=)), in TcRnDriver. That will just make GHCi generate code with uses of > overloaded (>>=) that must be evaluated, rather than calling bindIO > directly. It should work just fine, but it'll make everything a tiny bit > slower and more indirect. If it simplified the code a lot, then fine, but > it doesn't really. So I'm inclined to leave it. > That's fine; I don't know why my search didn't turn that up (perhaps it's referenced in some weird indirect way). If we're going to keep thenIO, we should surely define (*>) = (>>) = thenIO, right?

1 0

GHC Trac
by Simon Peyton Jones 03 Nov '14

03 Nov '14

Is it just me, or is the GHC Trac soul-destroyingly slow at the moment? IT takes minutes to load one page! Simon

3 2

GHC on Windows (extended/broad discussion)
by Austin Seipp 03 Nov '14

03 Nov '14

Gintautas, Tamar, Roman, (CC'ing those on https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce, and Kyrill, who has helped us out much in the past) Thank you all for all your help with Windows recently. I apologize for not responding to some of your concerns sooner in the recent threads about tarballs, etc. First off, all your contributions are extremely welcome - GHC has had many talented Windows hackers in days long past, but these days this number has dwindled! Anyone who has an interest in GHC on Windows is in a place to make a big impact and help us. All the work Gintautas has done for example, will dramatically improve the ghc-tarballs scenario. On that note: Gintautas, I will get D339 merged in ASAP, as soon as I test it and make a download mirror for you. Haskell.org has an awesome new CDN setup, and once I implement https://downloads.haskell.org, it will be easy to update tarballs and serve them to mass amounts of users. However, beyond that, we still need more done. First off, if you can help, we can help you! We can make lots of Windows build bots for people on demand, so if you're in desperate need of disk space or your computers are a bit slow, we can help accommodate. Right now, we have nightly builds with Gabor's[1] build system, and soon, we're working on a Phabricator integration, which should be great - and hopefully reduce the amount of breakage substantially. I also notice there is a ticket list of Windows issues[2], and that's fantastic. After a quick glance, a lot of these tickets are old, duplicates, or could possibly be closed or fixed easily. A good first task for any new contributor would be to go through this list, and try to replicate some of them! And you can always ask me - I can certainly help you navigate GHC a bit to get somewhere. But there are still other things. The Win32 package for example, is dreadfully lacking in maintainership. While we merge patches, it would be great to see a Windows developer spearhead and clean it up - we could even make some improvements in GHC itself based on this. This would be an excellent opportunity to make a good impact in the broader ecosystem! Finally, we desperately need someone to consult with when we're up a creek. Are certain patches OK for Windows? What's the best way to fix certain bugs, or implement certain features? I feel like often we try to think about this, but it's a bit lonely when nobody else is there to help! I'm not sure how to fix this, other than encouraging things like doing active code reviews and helping grind out some patches. But at the very minimum, I'd just like to talk with you about things perhaps! So in summary - the work so far is grand, and we want to help you do more! And I'm sure everyone can help - there's always so much to do and so little time, we need to encourage it all we can. As Simon says: Upward and Onward! [1] http://haskell.inf.elte.hu/builders/ [2] https://ghc.haskell.org/trac/ghc/query?status=!closed&os=Windows&desc=1&ord… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 18

Problem with installing "primitive" on Windows/i686
by Gintautas Miliauskas 03 Nov '14

03 Nov '14

Installation of Alex in the msys2 i686 instructions is broken, more details in https://ghc.haskell.org/trac/ghc/ticket/9712. Before I spend more time on this, maybe someone knows off the bat what's going on? $ cabal install alex Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... Failed to install primitive-0.5.4.0 Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): [1 of 1] Compiling Main ( C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o ) Linking C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe ... Configuring primitive-0.5.4.0... setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. -- Gintautas Miliauskas

2 1

thenIO removal
by David Feuer 03 Nov '14

03 Nov '14

GHC.Base has a function, thenIO, that isn't used anywhere in the libraries or compiler, and isn't exported anywhere "public". But for some reason, it's listed in compiler/prelude/PrelNames.lhs, which causes a validation failure if I remove it. Is there a reason that a completely unused function is wired in? Is it a historical artifact, or an optimization that was never completed, or something else? Should I wipe it out of PrelNames, or do we want to use it for something? David

3 2

package hashes
by Simon Peyton Jones 03 Nov '14

03 Nov '14

Edward On branch wip/new-flatten-skolems-Oct14, I'm getting this test failure repeatably on test safePkgO1. I'm pretty sure I have done nothing to mess with package hashes! Any ideas? Simon =====> safePkg01(normal) 108 of 120 [0, 0, 0] cd ./check/pkg01 && $MAKE -s --no-print-directory safePkg01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared </dev/null >safePkg01.run.stdout 2>safePkg01.run.stderr Actual stdout output differs from expected: --- ./check/pkg01/safePkg01.stdout 2014-10-29 15:09:16.000000000 +0000 +++ ./check/pkg01/safePkg01.run.stdout 2014-10-30 15:25:17.799094762 +0000 @@ -29,17 +29,17 @@ require own pkg trusted: True M_SafePkg6 -package dependencies: array-0.5.0.1@array_<HASH> +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: trustworthy require own pkg trusted: False M_SafePkg7 -package dependencies: array-0.5.0.1@array_<HASH> +package dependencies: array-0.5.0.1 base-4.8.0.0* trusted: safe require own pkg trusted: False M_SafePkg8 -package dependencies: array-0.5.0.1@array_<HASH> +package dependencies: array-0.5.0.1 base-4.8.0.0 trusted: trustworthy require own pkg trusted: False

2 1

Core libraries bug tracker
by Simon Peyton Jones 02 Nov '14

02 Nov '14

Edward, and core library colleagues, This came up in our weekly GHC discussion * Does the Core Libraries Committee have a Trac? Surely, surely you should, else you'll lose track of issues. * Would you like to use GHC's Trac for the purpose? Advantages: o People often report core library issues on GHC's Trac anyway, so telling them to move it somewhere else just creates busy-work --- and maybe they won't bother, which leaves it in our pile. o Several of these libraries are closely coupled to GHC, and you might want to milestone some library tickets with an upcoming GHC release * If so we'd need a canonical way to identify tickets as CLC issues. Perhaps by making "core-libraries" the owner? Or perhaps the "Component" field? * Some core libraries (e.g. random) have a maintainer that isn't the committee. So that maintainer should be the owner of the ticket. Or the CLC might like a particular member to own a ticket. Either way, that suggest using the "Component" field to identify CLC tickets * Or maybe you want a Trac of your own? The underlying issue from our end is that we'd like a way to * filter out tickets that you are dealing with * and be sure you are dealing with them * without losing track of milestones... i.e. when building a release we want to be sure that important tickets are indeed fixed before releasing Simon

4 8

Re: [commit: ghc] wip/T9705: Add test case for T9705 (1cca652)
by Gabor Greif 02 Nov '14

02 Nov '14

Hello Gergö, you seem to test pattern synonyms in _class_ declarations here. Would it make sense to also test _instance_ declarations? Cheers, Gabor On 11/1/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : wip/T9705 > Link : > http://ghc.haskell.org/trac/ghc/changeset/1cca652e8d4a8b87daf70bded87cddc39… > >>--------------------------------------------------------------- > > commit 1cca652e8d4a8b87daf70bded87cddc39d973dab > Author: Dr. ERDI Gergo <gergo(a)erdi.hu> > Date: Tue Oct 21 20:51:55 2014 +0800 > > Add test case for T9705 > > >>--------------------------------------------------------------- > > 1cca652e8d4a8b87daf70bded87cddc39d973dab > testsuite/tests/patsyn/should_fail/T9705.hs | 3 +++ > testsuite/tests/patsyn/should_fail/T9705.stderr | 4 ++++ > testsuite/tests/patsyn/should_fail/all.T | 1 + > 3 files changed, 8 insertions(+) > > diff --git a/testsuite/tests/patsyn/should_fail/T9705.hs > b/testsuite/tests/patsyn/should_fail/T9705.hs > new file mode 100644 > index 0000000..54d1d00 > --- /dev/null > +++ b/testsuite/tests/patsyn/should_fail/T9705.hs > @@ -0,0 +1,3 @@ > +{-# LANGUAGE PatternSynonyms #-} > +class C a where > + pattern P = () > diff --git a/testsuite/tests/patsyn/should_fail/T9705.stderr > b/testsuite/tests/patsyn/should_fail/T9705.stderr > new file mode 100644 > index 0000000..d9a3a49 > --- /dev/null > +++ b/testsuite/tests/patsyn/should_fail/T9705.stderr > @@ -0,0 +1,4 @@ > + > +T9705.hs:3:5: > + Pattern synonyms not allowed in instance declarations > + pattern P = () > diff --git a/testsuite/tests/patsyn/should_fail/all.T > b/testsuite/tests/patsyn/should_fail/all.T > index bff6bdf..298f23b 100644 > --- a/testsuite/tests/patsyn/should_fail/all.T > +++ b/testsuite/tests/patsyn/should_fail/all.T > @@ -6,3 +6,4 @@ test('T8961', normal, multimod_compile_fail, ['T8961','']) > test('as-pattern', normal, compile_fail, ['']) > test('T9161-1', normal, compile_fail, ['']) > test('T9161-2', normal, compile_fail, ['']) > +test('T9705', normal, compile_fail, ['']) > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1