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: <pkgs>/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