At Thu, 15 May 2014 18:34:20 -0400, Neil Van Dyke wrote:
> FYI, a 6.0.1 install from source failed. I can't spend any time on it
> right now.
>
> System: 32-bit x86 dual-core, Debian Squeeze, no virtualization, no
> swap, 3 GB RAM total, almost 2 GB RAM free.
>
> $ ./configure --prefix=/usr/local/racket-6.0.1 --enable-both
> [[...]]
> $ make both
> [[...]]
> $ sudo make install-both
> [[...]]
> raco setup: 0 making: /htdp-lib/stepper
> Racket virtual machine has run out of memory; aborting
> Aborted
> make: *** [install-both] Error 134
What was the most recent
raco setup: 1 making: ...
line? My guess is that it will be the "math" collection.
I was running into similar problems with v6.0.1 on VMs that are
configured with relatively small amounts of RAM (i.e., 2 GB). Since
v6.0.1, I've fixed a leak in the handling of modules and namespaces.
That repair reduces the memory use of `raco setup` so that builds work
again on my small-RAM VMs.
As an extreme example, with v6.0.1,
racket -c -l math
peaks at something like 1.6GB on a 64-bit machine (according to the
Racket GC) in v6.0.1, while the same peaks at around 0.3GB in the
current development version.
Since you're using a 32-bit machine with 2 places, the trade-offs are a
little different, but I think you're probably seeing the same thing.
The development version and the next release should behave better.
The leaks that I fixed were related to compilation submodules, so they
were introduced relatively recently (in the last couple of years) and
could hide until we starting using submodules enough. Also, the leaks
were not the "didn't free memory" kind, but roughly the "should have
freed memory earlier" kind, which are more difficult to detect.
_
Racket Developers list:
http://lists.racket-lang.org/dev
