August 2014 - ghc-devs

Core Lint warnings
by Gabor Greif 05 Aug '14

05 Aug '14

Hello all, I see *literally thousands* of these warnings (in yesterday's and) today's bootstraps: {{{ HC [stage 1] libraries/base/dist-install/build/GHC/Base.o *** Core Lint warnings : in result of Desugar (after optimization) *** {-# LINE 261 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_arr :: forall r_agf a_adQ b_adR. (r_agf -> a_adQ) -> (r_agf -> b_adR) -> r_agf -> b_adR] INLINE binder is (non-rule) loop breaker: $c>>_arr {-# LINE 632 "libraries/base/GHC/Base.lhs #-}: Warning: [RHS of $c>>_apH :: forall a_adQ b_adR. GHC.Types.IO a_adQ -> GHC.Types.IO b_adR -> GHC.Types.IO b_adR] INLINE binder is (non-rule) loop breaker: $c>>_apH }}} I don't know when this started and it does not seem to lead to a damaged GHC, but nevertheless it does not look very trustworthy... Any idea what this could be and where it came from? Cheers, Gabor

1 0

Interrupt interruptible foreign calls on HS exit
by Andreas Voellmy 05 Aug '14

05 Aug '14

Hi GHCers, I've been looking into issue #9284, which boils down to getting certain foreign calls issued by HS threads to finish (i.e. return) in the exit sequence of forkProcess. There are several options for solving the particular problem in #9284; one option is to issue the particular foreign calls causing that issue as "interruptible" and then have the exit sequence interrupt interruptible foreign calls. The exit sequence, starting from hs_exit(), goes through hs_exit_(), exitScheduler(), scheduleDoGC(), deleteAllThreads(), and then deleteThread(), where deleteThread is this: static void deleteThread (Capability *cap STG_UNUSED, StgTSO *tso) { // NOTE: must only be called on a TSO that we have exclusive // access to, because we will call throwToSingleThreaded() below. // The TSO must be on the run queue of the Capability we own, or // we must own all Capabilities. if (tso->why_blocked != BlockedOnCCall && tso->why_blocked != BlockedOnCCall_Interruptible) { throwToSingleThreaded(tso->cap,tso,NULL); } } So it looks like interruptible foreign calls are not interrupted in the exit sequence. Is there a good reason why we have this behavior? Could we change it to interrupt TSO's with why_blocked == BlockedOnCCall_Interruptible in the exit sequence? Thanks, Andi P.S. It looks like this was introduced in commit 83d563cb9ede0ba792836e529b1e2929db926355.

2 4

last call... for HP 2014.2.0.0
by Mark Lentczner 05 Aug '14

05 Aug '14

As it stands, I'm planning on calling the final RCs final: - RC2 Mac - RC4 Win - RC3 Src and linux-dist They have a few wibbles, but nothing close to show-stopping. I'll rebuild the web site and upload it tomorrow and announce then as well. - Mark ("still on vacation") L.

1 0

Re: Release building for Windows
by Mark Lentczner 05 Aug '14

05 Aug '14

Seems to me that given the state of affairs, it is best to just leave it as it is this round: That is GHC is built split-obj, but the HP libs on Windows are not. In general, split-obj only makes executables smaller at the expense of link time and memory. It is a trade-off, and I'd make the call for faster link, and now uncertainty for now. So, unless there is objection, I'd call RC4 final for Windows. - Mark

1 0

HEADS UP: linker symbols changed, need to recompile
by Edward Z. Yang 05 Aug '14

05 Aug '14

I've just pushed a set of patches which change the linker symbols GHC chooses for object files; you'll need to make clean and rebuild your tree once you take these changes. Thanks, Edward

1 0

Status updates
by Austin Seipp 04 Aug '14

04 Aug '14

Hi *, Here's some weekly status updates! - I'm merging Applicative-Monad today after a few more minor fixes. OMG YES. This only occurred after fighting off some nasty bugs that took quite a while to track down. Unfortunately this ate up most of my time this week. - I redid the Phabricator page quite a bit on the wiki, as I sent in my earlier email. Do read over it and let me know what you think, I'll be updating it more soon: https://ghc.haskell.org/trac/ghc/wiki/Phabricator - I'm going to be redoing the Git wiki pages a bit today to streamline them, which hopefully will only take a few hours. - I'm draining the patch queue still, both from Phabricator and Trac, although I need to re-triage a few of the Trac tickets in particular which are in 'patch' status. - We have a new committer afoot, Karel Gardas! Yay! He's been working on Solaris support, so having direct access to commit will surely help speed things up here. - DPH will soon be disabled by default in ./validate, although Geoff has stepped up to help alleviate some of the pain (see prior emails from me.) After all that: - I'm going to fix bugs! Yes, I'll actually have time to do that. - Sometime this week I'll also hopefully finish off my Phabricator integrations: better build bot, with accurate logs, and posting to Trac from Phabricator. This is *almost* done, but still needs to be tested/deployed a bit. - I may get around to finally pushing my patches for faster inline copies this week (and -march support) if I still have time. Do let me know if anything is on your mind, or if any of you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Phabricator updates
by Austin Seipp 04 Aug '14

04 Aug '14

Hello *, I've spent the morning re-jiggering our Phabricator documentation: https://ghc.haskell.org/trac/ghc/wiki/Phabricator It now includes: - More screenshots! - Coverage of core applications, including Owners, and better coverage of Herald - Coverage of the new remarkup syntax - Better tips - Linking issues in Phabricator to Trac issues I particularly think people will find 'Owners' very useful, in combination with Herald. I have already organized a lot of the GHC source tree into 'Owner packages' and assigned owners. If you're working on the compiler, please go tweak those and add yourself as an owner of some part of the compiler! In particular the last one is the one you'll want to note the most. When you run `arc diff` now, you can associate a differential revision with a ticket. Here's the documentation with a nice big screenshot: https://ghc.haskell.org/trac/ghc/wiki/Phabricator#Linkingtracticketsandwiki… The TL;DR is when you run `arc diff`, just fill out the new "GHC Trac Issues" field and it'll be linked. As a bonus, it'll automatically show up in commit messages, and be hyperlinked in Phabricator appropriately. Note: Phabricator does not yet comment on Trac still, sorry. I didn't get around to it this week. Please let me know if anything is confusing. I'm sure I need to expand on stuff; in particular I still need to do another pass, adding some screenshots for Audit, and some of the "Philosophy of Phabricator" on how you may want to submit reviews and think about organizing your work. Thanks. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Release building for Windows
by Mark Lentczner 04 Aug '14

04 Aug '14

Randy Polen, undertook porting the new build of Haskell Platform to Windows. He did a great job... but as this is first time stepping up to such a big release, he has some questions about GHC and Windows, and the choices he had to make. He asked me to forward these to this list, as he's not a member. He's cc'd so you can reply to all and include him... or I can forward as needed. >From Randy: ------------------ I am building the Haskell Platform 2014.2.0.0 on the Windows side. Your advice would be very helpful to make sure the HP 2014 for Windows is as good as possible. There were some issues I worked-around, plus some features that seem to not be available in this particular GHC (7.8.3) on the 32-bit and 64-bit Windows platforms, and I would like to confirm that HP 2014.2.0.0 will be shipping something sensible and as expected for the Windows environment, noting things which are supported on other environments but not on Windows. * GHC 7.8.3 on Windows does not support building Haskell into shared libraries, (GHC ticket #8228) so all packages in HP 2014.2.0.0 for Windows have been built without --enable-shared * GHC 7.8.3 on Windows does not currently support LLVM (GHC ticket #7143) * All Windows HP 2014.2.0.0 packages have been built without --enabled-split-objs, in deference to the GHC 7.8 FAQ * Extra python, etc. bits included in the GHC 7.8.3 bindist for 64-bit Windows (GHC issue #9014) are not installed with Windows HP 2014.2.0.0. Is eliding them from the HP 2014.2.0.0 64-bit Windows installation safe and correct (i.e., are they truely not required)? * Missing src/html in GHC packages were worked around by replacing the entire GHC package doc tree of html files with the contents of the "Standard Libraries" tarball (but not for the two packages which are not built for Windows, terminfo and unix). Is this valid to do? Any issues might arise? * ref: http://www.haskell.org/ghc/docs/latest/libraries.html.tar.bz2 Thanks for any advice on these. I do want to make the Windows HP 2014.2.0.0 be as good as it can be. Randy

4 6

Question about BangPatterns semantics/documentation
by Herbert Valerio Riedel 04 Aug '14

04 Aug '14

The GHC User's Guide[1] says: | There is one (apparent) exception to this general rule that a bang | only makes a difference when it precedes a variable or wild-card: a | bang at the top level of a let or where binding makes the binding | strict, regardless of the pattern. (We say "apparent" exception | because the Right Way to think of it is that the bang at the top of a | binding is not part of the pattern; rather it is part of the syntax of | the binding, creating a "bang-pattern binding".) For example: | | let ![x,y] = e in b | | is a bang-pattern binding. Operationally, it behaves just like a case | expression: | | case e of [x,y] -> b However, the following two functions are not equivalent after compilation to Core: g, h :: (Int -> Int) -> Int -> () g f x = let !y = f x in () h f x = case f x of y -> () In fact, compilation results in g = \ (f_asi :: Int -> Int) (x_asj :: Int) -> case f_asi x_asj of _ [Occ=Dead] { I# ipv_sKS -> () } h = \ _ [Occ=Dead] _ [Occ=Dead] -> () Is the documentation inaccurate/incomplete/I-missed-something or is the implementation to blame? Cheers, hvr [1]: http://www.haskell.org/ghc/docs/7.8.3/html/users_guide/bang-patterns.html

3 2

HEADS UP: Applicative-Monad incoming
by Austin Seipp 04 Aug '14

04 Aug '14

Hi all, The Applicative Monad changes will be landing in HEAD soon, hopefully within a few hours once ./validate finishes and I triple-check everything. Why am I sending this? To warn you that you need to update Happy to *at least* version 1.19.4 before you can build GHC again. This is because Happy emitted parsers that had instances of Monad, and thus Happy needed to be fixed to also emit Applicative instances. Please be sure to upgrade your workstations, buildbots, toasters, etc so you don't get caught by surprise. ./configure will fail you if your Happy is invalid. This message is brought to you by sleep deprivation and almost two days of hunting an infinite loop in my changeset, which was quite annoying to track down. I'm sure something will still go wrong during ./validate... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0