March 2018 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 03 Oct '19

03 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

perf.haskell.org functional again
by Joachim Breitner 30 Nov '18

30 Nov '18

Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim

5 11

Scavenging SRTs in scavenge_one
by Ben Gamari 26 Jun '18

26 Jun '18

Hi Simon, I'm a bit confused by scavenge_one; namely it doesn't scavenge SRTs. It appears that it is primarily used for remembered set entries but it's not at all clear why this means that we can safely ignore SRTs (e.g. in the FUN and THUNK cases). Can you shed some light on this? Cheers, - Ben

3 10

End of Windows Vista support in GHC-8.6?
by Simon Jakobi 10 May '18

10 May '18

Hi! Given that Vista’s EOL was in April 2017 <https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support> i assume that there’s no intention to keep supporting it in GHC-8.6!? I’m asking because I intend to use a function <https://msdn.microsoft.com/en-us/library/windows/desktop/dd405488.aspx> that requires Windows 7 or newer for #13362 <https://ghc.haskell.org/trac/ghc/ticket/13362>. Ending Vista support would also allow us to remove some workarounds <https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=Vista> mostly in RTS. Best, Simon

5 10

Reconfigure required for head.
by Phyx 31 Mar '18

31 Mar '18

Hi all, I have just committed 4de585a which lifts the MAX_PATH restrictions for Haskell programs compiled with GHC 8.6 for Windows users. However when you update, you *MUST* run configure again. This counts for ALL platforms otherwise your build will suffer a not so friendly failure. If you're using Hadrian to build, you must manually update the submodule to HEAD of master as the Hadrian submodule hasn't been bumped yet. Thanks, Tamar

1 0

Phabricator new behavior regarding submitting patches for reviews
by Ömer Sinan Ağacan 31 Mar '18

31 Mar '18

Hi, One of the changes with the recent Phabricator update is that we can no longer submit a patch for reviews until the build bot successfully builds it. I can't even ping people in the comment section until the patch builds. It says: > These changes have not finished building yet and may have build failures. This > revision is currently a draft. You can leave comments, but no one will be > notified until the revision is submitted for review. The "submit" button now says "submit quietly". This is really annoying because - It takes several days for build bot to build a patch (I have a patch that has been in the queue for 3 days now and it's still counting) - I can validate a patch on my laptop in an hour. (slow validate takes about 2-3 hours) Previously I could get approvals, and then test locally and push. Now I can't do that unless I email people about the patch. - In the previous version I could submit an incomplete patch for comments, now I can't do that because no one will be notified and there's no way to ping people to explicitly draw attention (again unless I email people). So if possible (without downgrading it) could we bring back the old behavior (perhaps there's a setting about this?) Thanks, Ömer

2 4

Re: Memory usage exploding for complex pattern matching
by Victor Miraldo (UU) 30 Mar '18

30 Mar '18

Hello, >>>> I have just tried compiling my code with 8.4.2 and using >>>> -fmax-pmcheck-iterations=0, >>>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>>> -v$((1024*1024*12))`). >>>> >>> Hmmm, I'm a bit confused. Why are our results so different? How >>> precisely are you invoking GHC? >> >> Here I meant my whole code, not just the repro. I could have been more clear. >> Nevertheless, I'm calling it through stack: >> > I'll admit that I am a bit lost; Minimal.hs compiles for me with a > maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled > using GHC 8.4.1. Is this not the repro you are referring to? I get the same behavior as you for Minimal.hs. The "my code" above referred to the whole library that I'm developping. In fact, the Minimal.hs file contains a distilled version of that library with a template haskell splice that we are trying to use in one of our fully fledged examples. Do you want me to produce a larger "NotSoMinimal.hs" closer to the real thing? Cheers, Victor

2 1

Re: Memory usage exploding for complex pattern matching
by Victor Miraldo (UU) 30 Mar '18

30 Mar '18

Hello, >> I have just tried compiling my code with 8.4.2 and using >> -fmax-pmcheck-iterations=0, >> I gave GHC 12GB of ram and it still ran out (through `ulimit >> -v$((1024*1024*12))`). >> > Hmmm, I'm a bit confused. Why are our results so different? How > precisely are you invoking GHC? Here I meant my whole code, not just the repro. I could have been more clear. Nevertheless, I'm calling it through stack: stack build --ghc-options="-fmax-pmcheck-iterations=0" I have just ran the repro with and without "-fmax-pmcheck-iterations=0" and got similar results to yours. > Let's start with a fresh ticket; #11195 has a rather long history. Do > you think you could open it and attach your repro? Sure thing, will do it tomorrow! Cheers, Victor

2 1

Re: Memory usage exploding for complex pattern matching
by Victor Miraldo (UU) 30 Mar '18

30 Mar '18

Hello, @Ben > I tried 8.4 and indeed the renamer/typechecker takes dramatically less > memory (yay!), leaving desugar as the largest allocator (allocating > around 3GB) while compiling the minimal example. Furthermore, disabling > the pattern match checker (via -fmax-pmcheck-iterations=0) dramatically > reduces desugarer allocations (to around 60MByte). It looks like you are > right. I have just tried compiling my code with 8.4.2 and using -fmax-pmcheck-iterations=0, I gave GHC 12GB of ram and it still ran out (through `ulimit -v$((1024*1024*12))`). I saw many warnings about the pattern match checker exceeding the iterations I specified: warning: Pattern match checker exceeded (0) iterations in a case alternative. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) Which makes me wonder, is the option really stopping the checker or just displaying something when it exceeds the given number? > Unfortunately, it's not clear what can be done to work around this short > of > disabling the match checker for the entire module, as suggested by > mpickering. Ideally we would have some notion of local warning flags > (e.g. #602), allowing us to disable this (rather expensive) warning for > generated code. Sadly, we aren't there yet. Perhaps you would like to > propose such a mechanism? You guys are much more indicated to propose mechanisms to fix this. If you think this is a sensible mechanism to implement, sure! I'd be happy to propose it. @Simon > Let's make a Trac ticket for this (since there is a nice small reproducer). Or, if it seems a dup, attach the reproducer to some existing ticket. Should I be the one creating it or adding the reproducer? The closest I've seen is: https://ghc.haskell.org/trac/ghc/ticket/11195 > Maybe we should revert the (recent) patch that makes TH code behave like source code, until this pattern-match check business is solved. Let me know when this happens, I'll be happy to test my code again! Thanks! Cheers, Victor

2 1