- ghc-devs - Haskell.org

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

17 Apr '18

Hello all, Following up on this, I have created a trac ticket https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a couple days ago. In order to try to hack my way through and get my library to compile, I tried progressively adding more and more pattern synonyms to try to avoid exhaustiveness checking,yet, something really surprising happened. Big examples have type errors where small ones don't! I tried documenting the process in a repository: https://github.com/VictorCMiraldo/ghc-14987-repro-pipeline Unfortunately, however, I couldn't get the self contained repros in the repository above to throw type errors. Hence, I'm attaching my full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs gives type errors, even though it is being generated by the same template haskell code as the other files inside Examples, all of which compile just fine. To trigger the error, just run `stack build`. It really is a shame that the combination of pattern synonyms that shows the best memory performance crashes completely on bigger examples. Any suggestions are appreciated, thank you very much! Have a great weekend! Cheers, Victor On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: > "Victor Miraldo (UU)" <v.cacciarimiraldo(a)uu.nl> writes: > >> 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. >> > Okay, I just wanted to be certain we were indeed seeing the same > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program, > even one with the deep matches seen in Minimal.hs. > > Cheers, > > - Ben >

2 1

CI builds failing
by David Feuer 17 Apr '18

17 Apr '18

It looks like the recent differential builds are all failing like this: compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] Defined but not used: ‘hsc_env’ | 79 | initializePlugins hsc_env df | ^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_apc3 :: TYPE rep_apc2) rep_apc2 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage1/build/PrelRules.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Oddly, I don't see a commit to master failing like this. What's going on? David

3 3

Question about TypeInType
by Iavor Diatchki 16 Apr '18

16 Apr '18

Hello, I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? -Iavor {-# Language TypeInType, TypeFamilies #-} module Help where import Data.Kind type family IxKind (m :: Type) :: Type type family Value (m :: Type) :: IxKind m -> Type data T (k :: Type) (f :: k -> Type) type instance IxKind (T k f) = k type instance Value (T k f) = f {- [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) Desktop/Help.hs:13:31: error: • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ • In the type ‘f’ In the type instance declaration for ‘Value’ | 13 | type instance Value (T k f) = f | ^ Failed, no modules loaded. -}

3 3

RE: Nested Implications
by Simon Peyton Jones 16 Apr '18

16 Apr '18

Mathias I suspect substImplication was removed simply because it was never called, but I’m not certain. The entire cloning and substitution business is very heavyweight. Here’s an alternative idea: * Gather ‘fuvs’, the set of all free unification variables of the constraint you are about to solve. * Solve the constraint * For each variable in ‘fuvs’, set its IORef to Flexi; that is, simply undo any unification that has taken place. That seems simple, very non-invasive, and robust. Simon From: Matthías Páll Gissurarson <pallm(a)student.chalmers.se> Sent: 10 April 2018 00:57 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Nested Implications Greetings Simon, I've been working on implementing the valid substitutions for typed holes in terms of nested implications, and I think I've worked out how to do it. But one thing bothers me. To use the implications that are passed along with the ReportErrCtxt, I have to clone the type variables within, to avoid having side-effects that could impact later searches. I clone the type variables and create a substitution from the old variables to the new, which I'd like to apply to the implication. When I was looking around for how to do that, I came across this code in GHC 7.6.3 https://downloads.haskell.org/~ghc/7.6-latest/docs/html/libraries/ghc-7.6.3…<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.ha…> The `substImplication` function does precisely what I want, i.e. applies a substitution to an implication. However, that code is no longer present in GHC 8.5! The git history doesn't go far enough back for me to find an explanation, so I wanted to ask: why was this function removed? Is there something I should be wary of if I re-implement it? Please correct me if my approach is all wrong, I'd like to hear what you had in mind. -- - Matthías Páll Gissurarson

1 0

GHC Core / STG to supercombinators
by Csaba Hruska 16 Apr '18

16 Apr '18

Hello, I'd like to use GHC as a haskell frontend in a project. I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. Is it possible to use the simplifier to transform the parsed Haskell source to supercombinators? i.e. to do - eta expansion - closure conversion - lambda lifting Regarding the eta expansion and lambda lifting it seems (according the comments in simplifier code) it does not guarantee to make these transformations in every case. If GHC could transform the Core representation to supercombinators, which transformation should I use from *CoreToDo*? https://github.com/ghc/ghc/blob/master/compiler/simplCore/CoreMonad.hs#L107- L135 I'd like to use GHC as a frontend for my custom code generator which can handle (lazy) top level functions only. Is it better to use GHC as a library or is it better to write a compiler plugin to capture the core representation. I do not want to optimize the Core at all neither want to use other parts of GHC's backend (i.e. codegen). Ideally GHC would typecheck and transform everything to top level function and my system would do the rest. Do you know what would be the easiest way to do this? (i.e. via *CoreToDo* or custom calls for the simplifying functions) Or would it be simpler to generate top level (lazy) functions from STG? Regards, Csaba Hruska

3 2

Site of ghc.haskell.org is down?
by Takenobu Tani 16 Apr '18

16 Apr '18

Hi devs, When I accessed `https://ghc.haskell.org/`, the following message is displayed: Your connection is not secure I checked it with Firefox and Chrome. Is it a matter of site setting? Regards, Takenobu

5 6

Error submitting a code review
by ARJANEN Loïc Jean David 13 Apr '18

13 Apr '18

Hello, I'm currently having an issue submitting my first code review. I recently registered on Phabricator and tried to send my first code review through the web interface. However, Harbormaster is failing to build it with the following error in the lease: Couldn't find remote ref. When searching on Google for this error, I found indications that it's related to Drydock not managing to push the changes to the staging area, likely due to a bad SSH key or git URL for arcanist. Could the SSH key issue also apply when using the web interface?Hoping to read from you soon, I wish you a very good day. Yours sincerely,ARJANEN Loïc

3 4

DTrace patch for FreeBSD breaks ability to function as a bootstrap compiler under FreeBSD
by raichoo 13 Apr '18

13 Apr '18

Hi, Last year I've provided a patch that enables DTrace probes under FreeBSD, sadly as it turns out this currently breaks the ability of GHC 8.4.1 to function as a bootstrap compiler under FreeBSD. I've provided a patch that adds a flag to the build system so one can turn off DTrace in case one needs to build a bootstrap compiler. https://phabricator.haskell.org/D4575 This should probably also contain some heads up in the documentation, otherwise someone might end up with a compiler that's not suitable for bootstrapping. Not sure on how this is being handled. I have an idea on how to fix the actual issue but for the time being this might be a suitable workaround. Maybe we can still get this into 8.4.2? I've already notified the FreeBSD ports maintainers regarding this issue. Sorry for the inconvenience. Kind regards, raichoo

2 2

Re: [ANNOUNCE] GHC 8.4.1 released
by Ryan Scott 12 Apr '18

12 Apr '18

I've submitted a Diff [1] for this. Ryan S. ----- [1] https://phabricator.haskell.org/D4586

1 0

Re: [ANNOUNCE] GHC 8.4.1 released
by Ryan Scott 11 Apr '18

11 Apr '18

Thanks, Ben. It looks like the version number for base has not been bumped to 4.11.1.0, despite incorporating this commit [1] which introduces readFieldHash to base. Currently, this makes it impossible to guard against the existence of the readFieldHash function in a project I'm working on. Ryan S. ----- [1] http://git.haskell.org/ghc.git/commit/d5577f44eaf3b9dfdfc77828038782bf818c1…

1 0