RE: T14394 output

Gah! Yes that's the right output. I'm not sure how I messed that up. Sorry Simon | -Original Message- | From: Ben Gamari [mailto:b...@well-typed.com] | Sent: 08 November 2017 18:57 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: T14394 output |

Re: Building on limited memory environments (or does -M really work?)

Hey Saurabh, from my experience with CircleCI it builds on machines with e.g. 32 cores showing up in htop (but allows you to use way less that that). But ghc sees 32 cores so -j will compile up to 32 modules at the same time (thus using tons of RAM). I solved that by setting -jN to the actual

T14394 output

Hi Simon, It seems that your recent commit 30058b0e45e9 may not be quite right. Specifically, the expected output for T14394 is empty, whereas the test is almost certainly going to produce output. The current output is, pattern Foo :: () => (b ~ a) => a :~~: b -- Defined at :5:1 pattern

Re: Building on limited memory environments (or does -M really work?)

Note that there are two -j flags, one to `stack` and one to `ghc`. I'm not completely sure what `stack`s -j does at the moment, but IIRC it specifies how many *packages* are built in parallel (maybe running tests is counted towards that job limit too). This means that `stack build -j3` may (and

Re: Building on limited memory environments (or does -M really work?)

Saurabh Nanda writes: >> >> Did you ever make any progress on this, Saurabh? >> > > We made progress in some sense, by introducing a separate `stack build -j1` > step in our CI pipeline for compiling packages that are known to use a lot > of memory. > > >> >> * -j just

Re: Building on limited memory environments (or does -M really work?)

> > Did you ever make any progress on this, Saurabh? > We made progress in some sense, by introducing a separate `stack build -j1` step in our CI pipeline for compiling packages that are known to use a lot of memory. > > * -j just tells GHC to parallelise compilation across modules. This can >