Re: [racket-dev] Racket 6.0.1 make install-both fails: Racket virtual machine has run out of memory; aborting
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
[racket-dev] Determining if a resolved module path is a real module name
Sometimes, `resolved-module-path-name` produces the symbol '|expanded module|. Is this the only symbol that's produced that _isn't_ the actual name of a module? Also, given that I'm calling `expand` on a module form, is it possible to do something so that I _don't_ end up with '|expanded module| as the name? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Determining if a resolved module path is a real module name
The result of `expand` does not keep track of it source. You may want to use `resolve-module-path-index` from `syntax/modresolve`, providing the original module path as the second argument. The `resolve-module-path-index` function detects the self module path index (which is giving you '|expanded module|) and uses the second argument in its place. At Fri, 16 May 2014 09:58:12 -0400, Sam Tobin-Hochstadt wrote: Sometimes, `resolved-module-path-name` produces the symbol '|expanded module|. Is this the only symbol that's produced that _isn't_ the actual name of a module? Also, given that I'm calling `expand` on a module form, is it possible to do something so that I _don't_ end up with '|expanded module| as the name? Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Determining if a resolved module path is a real module name
On Fri, May 16, 2014 at 10:23 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The result of `expand` does not keep track of it source. You may want to use `resolve-module-path-index` from `syntax/modresolve`, providing the original module path as the second argument. The `resolve-module-path-index` function detects the self module path index (which is giving you '|expanded module|) and uses the second argument in its place. Ok, thanks. I'd actually prefer to know that a particular identifier is a reference to the current module, so if '|expanded module| is only (and always) produced for this case, that's plenty for me. Sam At Fri, 16 May 2014 09:58:12 -0400, Sam Tobin-Hochstadt wrote: Sometimes, `resolved-module-path-name` produces the symbol '|expanded module|. Is this the only symbol that's produced that _isn't_ the actual name of a module? Also, given that I'm calling `expand` on a module form, is it possible to do something so that I _don't_ end up with '|expanded module| as the name? Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Determining if a resolved module path is a real module name
At Fri, 16 May 2014 10:40:44 -0400, Sam Tobin-Hochstadt wrote: On Fri, May 16, 2014 at 10:23 AM, Matthew Flatt mfl...@cs.utah.edu wrote: The result of `expand` does not keep track of it source. You may want to use `resolve-module-path-index` from `syntax/modresolve`, providing the original module path as the second argument. The `resolve-module-path-index` function detects the self module path index (which is giving you '|expanded module|) and uses the second argument in its place. Ok, thanks. I'd actually prefer to know that a particular identifier is a reference to the current module, so if '|expanded module| is only (and always) produced for this case, that's plenty for me. You should look for #f as the first result of `module-path-index-split`, instead, since that's defined to indicate the self module path index. At Fri, 16 May 2014 09:58:12 -0400, Sam Tobin-Hochstadt wrote: Sometimes, `resolved-module-path-name` produces the symbol '|expanded module|. Is this the only symbol that's produced that _isn't_ the actual name of a module? Also, given that I'm calling `expand` on a module form, is it possible to do something so that I _don't_ end up with '|expanded module| as the name? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
