[racket] DrRacket never uses more than 1 GB?

Re my comment:

> [6] Speaking of DrRacket and debugging, the debugger needs an option
> to limit the display of large items; otherwise DrRacket becomes very
> unresponsive and stepping in the debugger can take many, many seconds
> between each step. Debugging = pain is the wrong lesson to teach new
> folks IMHO.

I tried to take a baby step toward contributing solutions not just
feedback. :) So I dug around debug-tool.rkt attempting to figure out
how to change this.

Looks like simply changing line 1101 to use the existing
truncate-value function, would do the trick. It worked in my
experiment tweaking the distributed debug-tool.rkt, raco make,
restarting DrRacket, and verifying it behaved OK for a few test cases.
(I realize not a great dev env/process; like I said, baby step.)

I submitted this as a feature request, it's item 11055.

HTH,
Greg

On Wed, Jul 14, 2010 at 6:22 PM, Greg Hendershott
<greghendershott at gmail.com> wrote:
> Good news, I found and fixed my memory over-consumption, albeit the hard way.
>
> Some take-aways:
>
> [1] I remain convinced that DrRacket won't use > 1 GB for on Win64.
> [2] It would be great to see DrRacket as a full 64 bit app on Windows
> and Mac OS X someday.
> [3] The intended use of Limit Memory and its interaction with actual
> memory available from the OS, could use some better doc/explanation.
> It will suggest you increase its limit when you hit, but on the list
> I'm learning that can backfire, and anyway I've seen the limit ignored
> ... basically it's all pretty confusing.
> [4] More memory debugging tools would be helpful, as it's non-trivial
> to correlate Racket data to bytes (e.g. no C-style sizeof).
> [5] I learned that some of you seemingly don't use the DrRacket
> environment very much, yourselves? :)
> [6] Speaking of DrRacket and debugging, the debugger needs an option
> to limit the display of large items; otherwise DrRacket becomes very
> unresponsive and stepping in the debugger can take many, many seconds
> between each step. Debugging = pain is the wrong lesson to teach new
> folks IMHO.
> [7] Although DrRacket is already a good "IDE", many people know stuff
> like Eclipse and Visual Studio, and this is a big part of the
> experience of the "language" and important for broader acceptance
> (assuming that's a priority?).
>
> Sorry if that's a random brain-dump but I hope it may be helpful. Also
> I hope it's clear that if I didn't like Racket I wouldn't bother
> offering the feedback, so although this may not feel like a
> compliment, indirectly it is. :)
>
> Cheers,
> Greg
>
> On Tue, Jul 13, 2010 at 8:40 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> On Tue, Jul 13, 2010 at 6:39 PM, Greg Hendershott
>> <greghendershott at gmail.com> wrote:
>>> OK mister smartypants. :)
>>
>> Indeed! :)
>>
>>> I set the limit back to 1024 MB.
>>>
>>> And ... it crashed again DrRacket again.
>>
>> That limit is probably high enough to be ineffective as an actual
>> limit. I don't understand the precise connection between what
>> current-memory-use reports and what the OS says that a process is
>> using, but you want to use the numbers for the former, not the latter.
>>
>>> Just like it did back when I decided to try setting it to "unlimited"
>>> in the first place, to avoid this happening.
>>>
>>> Seriously, is the idea that users are supposed to:
>>> [1] Understand the maximum memory for their system. (Which isn't
>>> documented, but on Win64 is 2 GB ... unless it is actually 1 GB.)
>>> [2] Set the DrRacket memory limit to whatever value they guessed in step 1.
>>> [3] Watch DrRacket abend and lose their work, anyway?
>>>
>>> I'm not trying to be a PITA, I genuinely don't understand the intended usage.
>>>
>>> Also I guess I'm frustrated that I have a memory utilization issue
>>> which is my own darn fault, but I have no clear mental model, yet,
>>> what the heck is happening and how to track it down. In which regard I
>>> suppose I feel like an Alan Perlis punch-line: A programmer who knows
>>> the value, and actually DOES want to understand the cost ... but
>>> can't. Like, if I have to ask the price, I can't afford it ... ?
>>
>> ha!
>>
>> IMO, we are missing good memory debugging tools, but this is a big
>> project so likely you'll have to stick with what we have so far.
>>
>> If you build with one of the alternate collects (sgc?) you can get a
>> fair amount of memory debugging information. Its pretty low-level and
>> there is no visualization to help you understand, but if you are
>> careful and think hard about what it is telling you, you might be able
>> to get some use out of it.
>>
>> Robby
>>
>