RE: space leak in compiler?

On 10 May 2004 12:28, Serge D. Mechveliani wrote:

> The DoCon application has many modules.
> In early versions `make' did the project with -Onot in less that  32Mb
> , and without restart.
> And  ghc-6.2.1  needs more the 90Mb for this.
> Therefore I suspect a space leak due to GC work between compiling
> modules. Only suspect.

That's useful info, thanks.

I found the segmentation fault bug, 6.2.2 will have the fix.

The build now falls over with an error (attached at the end of this
message).

>>   - If you need to compile on small memory machines, I suggest you
>>     avoid --make, and use ordinary Makefiles or hmake instead.  Both
>>     of these will restart the compiler for each module, and hence
>>     avoid the behaviour you're seeing.  You might even get a speedup,
>>     because the compiler won't be forced to use the compacting GC
>>     all the time.
> 
> 
> No, `make' it is all right in any case.
> Simpler commands are preferable.
> It is was all right in earlier GHC, why should it become worse in
> fresh ones?
> It forces the user to repeat the `make' command.
> If so, then, evidently, the GHC driver can do such a repetition
> automatically, until it finishes making.

Restarting 'ghc --make' if it runs out of memory is a horrible solution!
If you need to compile under tight memory constraints, using GHC in
single-module compilation mode (or with hmake) is the right way.

Cheers,
        Simon

pol/Pol3_.hs:352:
    Could not deduce (EuclideanRing a)
        from the context (LinSolvRing (UPol (Pol a)),
                          LinSolvRing (Pol a),
                          CommutativeRing a,
                          CommutativeRing (UPol (Pol a)),
                          MulMonoid (UPol (Pol a)))
      arising from use of `gxBasis' at pol/Pol3_.hs:352
    Probable fix:
        Add (EuclideanRing a) to the class or instance method `gxBasis'
    In the first argument of `($)', namely `gxBasis'
    In a pattern binding:
        (gs, mt) = gxBasis $ (map (fromHeadVarPol . toOverP') fs)
    In the definition of `gxBasis':
        gxBasis (fs@(f : _))
                  = let
                      UPol _ p y dP = f
                      (o, n) = (pPPO p, genericLength $ (pVars p))
                      (toLex, fromLex) = (reordPol $ (lexPPO n),
reordPol o)
                      fromOverP' = (ct f) . ((map (\ (a, j) -> ...)) .
upolMons)
                      p' = toLex p
                      dP' = upLinSolvRing p' eFM
                      s' = cToUPol y dP' p'
                      toOverP' = (ct s') . ((map (\ (a, j) -> ...)) .
upolMons)
                      (gs, mt) = gxBasis $ (map (fromHeadVarPol .
toOverP') fs)
                      back = fromOverP' . (headVarPol dP)
                    in (map back gs, mapmap back mt)