Re: [racket-users] a little bug

2020-02-28 Thread Hendrik Boom
On Fri, Feb 28, 2020 at 07:11:02AM -0600, Robby Findler wrote:
> Oh, sorry-- I misunderstood.
> 
> In v7.5, there will be, in some cases, a source location after you
> dismiss that dialog. In the pre-release builds, that's been improved
> somewhat and source location information is more reliably available.

Excellent.

> That said, there are limitations and it isn't always available.

Of course.  If the entire process gets shut down because of memory
 overrun there isn't much left to report on.

> 
> Thanks for using DrR!

It's the easiest way to use Racket.

-- hendrik

> 
> Robby
> 
> On Fri, Feb 28, 2020 at 6:31 AM Hendrik Boom  wrote:
> >
> > On Fri, Feb 28, 2020 at 06:02:31AM -0600, Robby Findler wrote:
> > > I agree that would be great. In the meantime, the Run button does a better
> > > job with error reporting in various ways, including this one so hopefully
> > > you can try that?
> >
> > That's what I was using.  There was a popup message that wasn't any more
> > informative.
> > It says:
> >
> > - The evaluation thread is no longer running, so
> >   no evaluation can take place until the next
> >   execution.
> >
> >   The program ran out of memory.
> >   [V]Show thid dialog ext time
> > [Increase memory limit to 256 megabytes][OK]
> >
> > I'm mentioning this to indicate a way the drracket uer-interface can be
> > improved, especially for beginners.
> >
> > I'm not asking Racket maintainers to step in and debug my code.
> >
> > (Further analysis (by deleting code until there was almost nothing left)
> > indicates it crashed during processing the #lang line at the start.
> > I have started private correspondence with the language author.)
> >
> > -- hendrik
> > >
> > > Robby
> > >
> > > On Fri, Feb 28, 2020 at 5:45 AM Hendrik Boom  
> > > wrote:
> > >
> > > >
> > > > When Racket detects the out-of-memory condition during "background
> > > > processing", it would be useful i the out-of-memory message were to 
> > > > point
> > > > out which particular piece of source text it was having trouble with.  
> > > > Just
> > > > the line number where the expression started that the REPL was having
> > > > trouble with would be a huge help.
> > > >
> > > > And by the way, if Dr. Racket were to be a she, she would be addressed 
> > > > in
> > > > Quebec as Dre. Racket.
> > > >
> > > > On Friday, 5 February 2016 19:19:46 UTC-5, jon stenerson wrote:
> > > >
> > > >> lol. Don't be sorry.  Speaking of anthropomorphization, I really love 
> > > >> Dr
> > > >> Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I
> > > >> employ his services whenever I can. I don't mean to be a whiner; he
> > > >> deserves better than that!
> > > >>
> > > >> Jon
> > > >>
> > > >> On 2/5/2016 3:44 PM, Robby Findler wrote:
> > > >> > Sorry we can't do better. And it is really amazing how I actually
> > > >> > think so anthropomorphically about these things. :) That really was a
> > > >> > literal brain dump.
> > > >> >
> > > >> > Robby
> > > >> >
> > > >> > On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson 
> > > >> wrote:
> > > >> >> Thanks for the explanation. I appreciate it.
> > > >> >>
> > > >> >>
> > > >> >> On 2/5/2016 1:55 PM, Robby Findler wrote:
> > > >> >>> In general, DrRacket does not promise to avoid this situation. Let 
> > > >> >>> me
> > > >> >>> explain a little bit. This program is effectively equivalent to 
> > > >> >>> this
> > > >> >>> one:
> > > >> >>>
> > > >> >>> #lang racket/base
> > > >> >>> (define (run l)
> > > >> >>> (run (cons 'x l)))
> > > >> >>> (run '())
> > > >> >>>
> > > >> >>> (but running at compile time, which is why things happen
> > > >> >>> automatically, but lets leave that aside for now).
> > > >> >>>
> > > >> >>> So when you run that program, DrRacket is asking the operating 
> > > >> >>> system
> > > >> >>> for all of its memory. At some point, the operating system says
> > > >> >>> "sorry, no, we're out of memory" and since the program running 
> > > >> >>> inside
> > > >> >>> DrRacket doesn't really care that we're out of memory, the 
> > > >> >>> operating
> > > >> >>> system responds with "die!". And so DrRacket dies.
> > > >> >>>
> > > >> >>> There are two ways we try to do better. First: we can set limits on
> > > >> >>> the memory. But if the limit is set to be higher than the amount of
> > > >> >>> memory available on the machine, then it is as if the memory limit
> > > >> >>> isn't set. Also worth noting at this point: the way that DrRacket's
> > > >> >>> counting of "how much memory" is only loosely related to the way 
> > > >> >>> that
> > > >> >>> your machine's vendor or the OS counts. There are some constant
> > > >> >>> factors of difference there that depend on things like how the
> > > >> garbage
> > > >> >>> collector is configured and how many other programs are running on
> > > >> >>> your system and what they are doing (like the OS itself likes to 
> > > >> >>> have
> > > >> >>> some of the memory and it (quite reasonably) doesn't want to 

Re: [racket-users] a little bug

2020-02-28 Thread Robby Findler
Oh, sorry-- I misunderstood.

In v7.5, there will be, in some cases, a source location after you
dismiss that dialog. In the pre-release builds, that's been improved
somewhat and source location information is more reliably available.
That said, there are limitations and it isn't always available.

Thanks for using DrR!

Robby

On Fri, Feb 28, 2020 at 6:31 AM Hendrik Boom  wrote:
>
> On Fri, Feb 28, 2020 at 06:02:31AM -0600, Robby Findler wrote:
> > I agree that would be great. In the meantime, the Run button does a better
> > job with error reporting in various ways, including this one so hopefully
> > you can try that?
>
> That's what I was using.  There was a popup message that wasn't any more
> informative.
> It says:
>
> - The evaluation thread is no longer running, so
>   no evaluation can take place until the next
>   execution.
>
>   The program ran out of memory.
>   [V]Show thid dialog ext time
> [Increase memory limit to 256 megabytes][OK]
>
> I'm mentioning this to indicate a way the drracket uer-interface can be
> improved, especially for beginners.
>
> I'm not asking Racket maintainers to step in and debug my code.
>
> (Further analysis (by deleting code until there was almost nothing left)
> indicates it crashed during processing the #lang line at the start.
> I have started private correspondence with the language author.)
>
> -- hendrik
> >
> > Robby
> >
> > On Fri, Feb 28, 2020 at 5:45 AM Hendrik Boom  wrote:
> >
> > >
> > > When Racket detects the out-of-memory condition during "background
> > > processing", it would be useful i the out-of-memory message were to point
> > > out which particular piece of source text it was having trouble with.  
> > > Just
> > > the line number where the expression started that the REPL was having
> > > trouble with would be a huge help.
> > >
> > > And by the way, if Dr. Racket were to be a she, she would be addressed in
> > > Quebec as Dre. Racket.
> > >
> > > On Friday, 5 February 2016 19:19:46 UTC-5, jon stenerson wrote:
> > >
> > >> lol. Don't be sorry.  Speaking of anthropomorphization, I really love Dr
> > >> Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I
> > >> employ his services whenever I can. I don't mean to be a whiner; he
> > >> deserves better than that!
> > >>
> > >> Jon
> > >>
> > >> On 2/5/2016 3:44 PM, Robby Findler wrote:
> > >> > Sorry we can't do better. And it is really amazing how I actually
> > >> > think so anthropomorphically about these things. :) That really was a
> > >> > literal brain dump.
> > >> >
> > >> > Robby
> > >> >
> > >> > On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson 
> > >> wrote:
> > >> >> Thanks for the explanation. I appreciate it.
> > >> >>
> > >> >>
> > >> >> On 2/5/2016 1:55 PM, Robby Findler wrote:
> > >> >>> In general, DrRacket does not promise to avoid this situation. Let me
> > >> >>> explain a little bit. This program is effectively equivalent to this
> > >> >>> one:
> > >> >>>
> > >> >>> #lang racket/base
> > >> >>> (define (run l)
> > >> >>> (run (cons 'x l)))
> > >> >>> (run '())
> > >> >>>
> > >> >>> (but running at compile time, which is why things happen
> > >> >>> automatically, but lets leave that aside for now).
> > >> >>>
> > >> >>> So when you run that program, DrRacket is asking the operating system
> > >> >>> for all of its memory. At some point, the operating system says
> > >> >>> "sorry, no, we're out of memory" and since the program running inside
> > >> >>> DrRacket doesn't really care that we're out of memory, the operating
> > >> >>> system responds with "die!". And so DrRacket dies.
> > >> >>>
> > >> >>> There are two ways we try to do better. First: we can set limits on
> > >> >>> the memory. But if the limit is set to be higher than the amount of
> > >> >>> memory available on the machine, then it is as if the memory limit
> > >> >>> isn't set. Also worth noting at this point: the way that DrRacket's
> > >> >>> counting of "how much memory" is only loosely related to the way that
> > >> >>> your machine's vendor or the OS counts. There are some constant
> > >> >>> factors of difference there that depend on things like how the
> > >> garbage
> > >> >>> collector is configured and how many other programs are running on
> > >> >>> your system and what they are doing (like the OS itself likes to have
> > >> >>> some of the memory and it (quite reasonably) doesn't want to share
> > >> >>> that memory).
> > >> >>>
> > >> >>> The second way is that the OS will sometimes say "you are about to
> > >> >>> cause me to exhaust all of the system's memory and if you do that, I
> > >> >>> will kill you" at which point the GC inside Racket responds with
> > >> >>> "okay, I'll just die first". The main advantage of this is that you
> > >> >>> get an error message saying "out of memory" from Racket instead of an
> > >> >>> error message saying "I killed your program" from the OS (which is
> > >> the
> > >> >>> message you're getting). It turns out to be 

Re: [racket-users] a little bug

2020-02-28 Thread Hendrik Boom
On Fri, Feb 28, 2020 at 06:02:31AM -0600, Robby Findler wrote:
> I agree that would be great. In the meantime, the Run button does a better
> job with error reporting in various ways, including this one so hopefully
> you can try that?

That's what I was using.  There was a popup message that wasn't any more 
informative.
It says:

- The evaluation thread is no longer running, so
  no evaluation can take place until the next
  execution.

  The program ran out of memory.
  [V]Show thid dialog ext time
[Increase memory limit to 256 megabytes][OK]

I'm mentioning this to indicate a way the drracket uer-interface can be 
improved, especially for beginners.

I'm not asking Racket maintainers to step in and debug my code.

(Further analysis (by deleting code until there was almost nothing left) 
indicates it crashed during processing the #lang line at the start.
I have started private correspondence with the language author.)

-- hendrik
> 
> Robby
> 
> On Fri, Feb 28, 2020 at 5:45 AM Hendrik Boom  wrote:
> 
> >
> > When Racket detects the out-of-memory condition during "background
> > processing", it would be useful i the out-of-memory message were to point
> > out which particular piece of source text it was having trouble with.  Just
> > the line number where the expression started that the REPL was having
> > trouble with would be a huge help.
> >
> > And by the way, if Dr. Racket were to be a she, she would be addressed in
> > Quebec as Dre. Racket.
> >
> > On Friday, 5 February 2016 19:19:46 UTC-5, jon stenerson wrote:
> >
> >> lol. Don't be sorry.  Speaking of anthropomorphization, I really love Dr
> >> Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I
> >> employ his services whenever I can. I don't mean to be a whiner; he
> >> deserves better than that!
> >>
> >> Jon
> >>
> >> On 2/5/2016 3:44 PM, Robby Findler wrote:
> >> > Sorry we can't do better. And it is really amazing how I actually
> >> > think so anthropomorphically about these things. :) That really was a
> >> > literal brain dump.
> >> >
> >> > Robby
> >> >
> >> > On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson 
> >> wrote:
> >> >> Thanks for the explanation. I appreciate it.
> >> >>
> >> >>
> >> >> On 2/5/2016 1:55 PM, Robby Findler wrote:
> >> >>> In general, DrRacket does not promise to avoid this situation. Let me
> >> >>> explain a little bit. This program is effectively equivalent to this
> >> >>> one:
> >> >>>
> >> >>> #lang racket/base
> >> >>> (define (run l)
> >> >>> (run (cons 'x l)))
> >> >>> (run '())
> >> >>>
> >> >>> (but running at compile time, which is why things happen
> >> >>> automatically, but lets leave that aside for now).
> >> >>>
> >> >>> So when you run that program, DrRacket is asking the operating system
> >> >>> for all of its memory. At some point, the operating system says
> >> >>> "sorry, no, we're out of memory" and since the program running inside
> >> >>> DrRacket doesn't really care that we're out of memory, the operating
> >> >>> system responds with "die!". And so DrRacket dies.
> >> >>>
> >> >>> There are two ways we try to do better. First: we can set limits on
> >> >>> the memory. But if the limit is set to be higher than the amount of
> >> >>> memory available on the machine, then it is as if the memory limit
> >> >>> isn't set. Also worth noting at this point: the way that DrRacket's
> >> >>> counting of "how much memory" is only loosely related to the way that
> >> >>> your machine's vendor or the OS counts. There are some constant
> >> >>> factors of difference there that depend on things like how the
> >> garbage
> >> >>> collector is configured and how many other programs are running on
> >> >>> your system and what they are doing (like the OS itself likes to have
> >> >>> some of the memory and it (quite reasonably) doesn't want to share
> >> >>> that memory).
> >> >>>
> >> >>> The second way is that the OS will sometimes say "you are about to
> >> >>> cause me to exhaust all of the system's memory and if you do that, I
> >> >>> will kill you" at which point the GC inside Racket responds with
> >> >>> "okay, I'll just die first". The main advantage of this is that you
> >> >>> get an error message saying "out of memory" from Racket instead of an
> >> >>> error message saying "I killed your program" from the OS (which is
> >> the
> >> >>> message you're getting). It turns out to be remarkably difficult to
> >> >>> get this error message to work in all situations. We're better than
> >> we
> >> >>> used to be at it, but at some level, the best we can do in that case
> >> >>> is really just to change the text of the error message. When we're
> >> out
> >> >>> of memory like that, it's very very hard to recover if the limits are
> >> >>> not set up ahead of time (i.e. back to the previous paragraph).
> >> >>>
> >> >>> I hope this clears up the issue somewhat.
> >> >>>
> >> >>> In the meantime, I suggest you lower the memory limit for your
> >> machine.
> >> >>>
> >> 

Re: [racket-users] a little bug

2020-02-28 Thread Robby Findler
I agree that would be great. In the meantime, the Run button does a better
job with error reporting in various ways, including this one so hopefully
you can try that?

Robby

On Fri, Feb 28, 2020 at 5:45 AM Hendrik Boom  wrote:

>
> When Racket detects the out-of-memory condition during "background
> processing", it would be useful i the out-of-memory message were to point
> out which particular piece of source text it was having trouble with.  Just
> the line number where the expression started that the REPL was having
> trouble with would be a huge help.
>
> And by the way, if Dr. Racket were to be a she, she would be addressed in
> Quebec as Dre. Racket.
>
> On Friday, 5 February 2016 19:19:46 UTC-5, jon stenerson wrote:
>
>> lol. Don't be sorry.  Speaking of anthropomorphization, I really love Dr
>> Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I
>> employ his services whenever I can. I don't mean to be a whiner; he
>> deserves better than that!
>>
>> Jon
>>
>> On 2/5/2016 3:44 PM, Robby Findler wrote:
>> > Sorry we can't do better. And it is really amazing how I actually
>> > think so anthropomorphically about these things. :) That really was a
>> > literal brain dump.
>> >
>> > Robby
>> >
>> > On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson 
>> wrote:
>> >> Thanks for the explanation. I appreciate it.
>> >>
>> >>
>> >> On 2/5/2016 1:55 PM, Robby Findler wrote:
>> >>> In general, DrRacket does not promise to avoid this situation. Let me
>> >>> explain a little bit. This program is effectively equivalent to this
>> >>> one:
>> >>>
>> >>> #lang racket/base
>> >>> (define (run l)
>> >>> (run (cons 'x l)))
>> >>> (run '())
>> >>>
>> >>> (but running at compile time, which is why things happen
>> >>> automatically, but lets leave that aside for now).
>> >>>
>> >>> So when you run that program, DrRacket is asking the operating system
>> >>> for all of its memory. At some point, the operating system says
>> >>> "sorry, no, we're out of memory" and since the program running inside
>> >>> DrRacket doesn't really care that we're out of memory, the operating
>> >>> system responds with "die!". And so DrRacket dies.
>> >>>
>> >>> There are two ways we try to do better. First: we can set limits on
>> >>> the memory. But if the limit is set to be higher than the amount of
>> >>> memory available on the machine, then it is as if the memory limit
>> >>> isn't set. Also worth noting at this point: the way that DrRacket's
>> >>> counting of "how much memory" is only loosely related to the way that
>> >>> your machine's vendor or the OS counts. There are some constant
>> >>> factors of difference there that depend on things like how the
>> garbage
>> >>> collector is configured and how many other programs are running on
>> >>> your system and what they are doing (like the OS itself likes to have
>> >>> some of the memory and it (quite reasonably) doesn't want to share
>> >>> that memory).
>> >>>
>> >>> The second way is that the OS will sometimes say "you are about to
>> >>> cause me to exhaust all of the system's memory and if you do that, I
>> >>> will kill you" at which point the GC inside Racket responds with
>> >>> "okay, I'll just die first". The main advantage of this is that you
>> >>> get an error message saying "out of memory" from Racket instead of an
>> >>> error message saying "I killed your program" from the OS (which is
>> the
>> >>> message you're getting). It turns out to be remarkably difficult to
>> >>> get this error message to work in all situations. We're better than
>> we
>> >>> used to be at it, but at some level, the best we can do in that case
>> >>> is really just to change the text of the error message. When we're
>> out
>> >>> of memory like that, it's very very hard to recover if the limits are
>> >>> not set up ahead of time (i.e. back to the previous paragraph).
>> >>>
>> >>> I hope this clears up the issue somewhat.
>> >>>
>> >>> In the meantime, I suggest you lower the memory limit for your
>> machine.
>> >>>
>> >>> Robby
>> >>>
>> >>>
>> >>>
>>
> >>> On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson 
>>
>>
> >>> wrote:
>>  Actually you don't even have to run the program. With memory limit
>> set to
>>  1024, just open a file containing the expression and wait. After a
>> minute
>>  or
>>  two DrRacket puts up a MSVC runtime error dialog.
>> 
>> 
>>  On 2/5/2016 9:39 AM, jon stenerson wrote:
>> > Setting the limit lower helped. Thanks. I did not see that message
>> about
>> > Background Expansion Terminated before. Now I do.
>> >
>> > Jon
>> >
>> > On 2/5/2016 6:55 AM, Robby Findler wrote:
>> >> It took a while for mine for the custodian limit to be reached and
>> for
>> >> the expansion to run out of memory. It may be that the threshhold
>> for
>> >> the memory use is too high on some systems. Maybe the right thing
>> is
>> >> to set the default a bit lower?
>> >>
>> >> Jon: if you open 

Re: [racket-users] a little bug

2020-02-28 Thread Hendrik Boom

When Racket detects the out-of-memory condition during "background 
processing", it would be useful i the out-of-memory message were to point 
out which particular piece of source text it was having trouble with.  Just 
the line number where the expression started that the REPL was having 
trouble with would be a huge help.

And by the way, if Dr. Racket were to be a she, she would be addressed in 
Quebec as Dre. Racket.

On Friday, 5 February 2016 19:19:46 UTC-5, jon stenerson wrote:
>
> lol. Don't be sorry.  Speaking of anthropomorphization, I really love Dr 
> Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I 
> employ his services whenever I can. I don't mean to be a whiner; he 
> deserves better than that! 
>
> Jon 
>
> On 2/5/2016 3:44 PM, Robby Findler wrote: 
> > Sorry we can't do better. And it is really amazing how I actually 
> > think so anthropomorphically about these things. :) That really was a 
> > literal brain dump. 
> > 
> > Robby 
> > 
> > On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson  > wrote: 
> >> Thanks for the explanation. I appreciate it. 
> >> 
> >> 
> >> On 2/5/2016 1:55 PM, Robby Findler wrote: 
> >>> In general, DrRacket does not promise to avoid this situation. Let me 
> >>> explain a little bit. This program is effectively equivalent to this 
> >>> one: 
> >>> 
> >>> #lang racket/base 
> >>> (define (run l) 
> >>> (run (cons 'x l))) 
> >>> (run '()) 
> >>> 
> >>> (but running at compile time, which is why things happen 
> >>> automatically, but lets leave that aside for now). 
> >>> 
> >>> So when you run that program, DrRacket is asking the operating system 
> >>> for all of its memory. At some point, the operating system says 
> >>> "sorry, no, we're out of memory" and since the program running inside 
> >>> DrRacket doesn't really care that we're out of memory, the operating 
> >>> system responds with "die!". And so DrRacket dies. 
> >>> 
> >>> There are two ways we try to do better. First: we can set limits on 
> >>> the memory. But if the limit is set to be higher than the amount of 
> >>> memory available on the machine, then it is as if the memory limit 
> >>> isn't set. Also worth noting at this point: the way that DrRacket's 
> >>> counting of "how much memory" is only loosely related to the way that 
> >>> your machine's vendor or the OS counts. There are some constant 
> >>> factors of difference there that depend on things like how the garbage 
> >>> collector is configured and how many other programs are running on 
> >>> your system and what they are doing (like the OS itself likes to have 
> >>> some of the memory and it (quite reasonably) doesn't want to share 
> >>> that memory). 
> >>> 
> >>> The second way is that the OS will sometimes say "you are about to 
> >>> cause me to exhaust all of the system's memory and if you do that, I 
> >>> will kill you" at which point the GC inside Racket responds with 
> >>> "okay, I'll just die first". The main advantage of this is that you 
> >>> get an error message saying "out of memory" from Racket instead of an 
> >>> error message saying "I killed your program" from the OS (which is the 
> >>> message you're getting). It turns out to be remarkably difficult to 
> >>> get this error message to work in all situations. We're better than we 
> >>> used to be at it, but at some level, the best we can do in that case 
> >>> is really just to change the text of the error message. When we're out 
> >>> of memory like that, it's very very hard to recover if the limits are 
> >>> not set up ahead of time (i.e. back to the previous paragraph). 
> >>> 
> >>> I hope this clears up the issue somewhat. 
> >>> 
> >>> In the meantime, I suggest you lower the memory limit for your 
> machine. 
> >>> 
> >>> Robby 
> >>> 
> >>> 
> >>> 
> >>> On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson  > 
> >>> wrote: 
>  Actually you don't even have to run the program. With memory limit 
> set to 
>  1024, just open a file containing the expression and wait. After a 
> minute 
>  or 
>  two DrRacket puts up a MSVC runtime error dialog. 
>  
>  
>  On 2/5/2016 9:39 AM, jon stenerson wrote: 
> > Setting the limit lower helped. Thanks. I did not see that message 
> about 
> > Background Expansion Terminated before. Now I do. 
> > 
> > Jon 
> > 
> > On 2/5/2016 6:55 AM, Robby Findler wrote: 
> >> It took a while for mine for the custodian limit to be reached and 
> for 
> >> the expansion to run out of memory. It may be that the threshhold 
> for 
> >> the memory use is too high on some systems. Maybe the right thing 
> is 
> >> to set the default a bit lower? 
> >> 
> >> Jon: if you open the "Racket" menu you should see a "Limit 
> Memory..." 
> >> menu item. How does DrRacket do if you change the number in there 
> to 
> >> 256 and then paste the program into the definitions window? Do you 
> see 
> >> the red message at the bottom of 

Re: [racket-users] a little bug

2016-02-05 Thread jon stenerson

Thanks for the explanation. I appreciate it.

On 2/5/2016 1:55 PM, Robby Findler wrote:

In general, DrRacket does not promise to avoid this situation. Let me
explain a little bit. This program is effectively equivalent to this
one:

#lang racket/base
(define (run l)
   (run (cons 'x l)))
(run '())

(but running at compile time, which is why things happen
automatically, but lets leave that aside for now).

So when you run that program, DrRacket is asking the operating system
for all of its memory. At some point, the operating system says
"sorry, no, we're out of memory" and since the program running inside
DrRacket doesn't really care that we're out of memory, the operating
system responds with "die!". And so DrRacket dies.

There are two ways we try to do better. First: we can set limits on
the memory. But if the limit is set to be higher than the amount of
memory available on the machine, then it is as if the memory limit
isn't set. Also worth noting at this point: the way that DrRacket's
counting of "how much memory" is only loosely related to the way that
your machine's vendor or the OS counts. There are some constant
factors of difference there that depend on things like how the garbage
collector is configured and how many other programs are running on
your system and what they are doing (like the OS itself likes to have
some of the memory and it (quite reasonably) doesn't want to share
that memory).

The second way is that the OS will sometimes say "you are about to
cause me to exhaust all of the system's memory and if you do that, I
will kill you" at which point the GC inside Racket responds with
"okay, I'll just die first". The main advantage of this is that you
get an error message saying "out of memory" from Racket instead of an
error message saying "I killed your program" from the OS (which is the
message you're getting). It turns out to be remarkably difficult to
get this error message to work in all situations. We're better than we
used to be at it, but at some level, the best we can do in that case
is really just to change the text of the error message. When we're out
of memory like that, it's very very hard to recover if the limits are
not set up ahead of time (i.e. back to the previous paragraph).

I hope this clears up the issue somewhat.

In the meantime, I suggest you lower the memory limit for your machine.

Robby



On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson  wrote:

Actually you don't even have to run the program. With memory limit set to
1024, just open a file containing the expression and wait. After a minute or
two DrRacket puts up a MSVC runtime error dialog.


On 2/5/2016 9:39 AM, jon stenerson wrote:

Setting the limit lower helped. Thanks. I did not see that message about
Background Expansion Terminated before. Now I do.

Jon

On 2/5/2016 6:55 AM, Robby Findler wrote:

It took a while for mine for the custodian limit to be reached and for
the expansion to run out of memory. It may be that the threshhold for
the memory use is too high on some systems. Maybe the right thing is
to set the default a bit lower?

Jon: if you open the "Racket" menu you should see a "Limit Memory..."
menu item. How does DrRacket do if you change the number in there to
256 and then paste the program into the definitions window? Do you see
the red message at the bottom of the screen or does DrRacket still run
out of memory?

Anthony: I don' thave a good solution for you, but I find that the
menu key short cut (control-k for you?) for killing is more likely to
get thru, because it requires a lot less event handling than the
others.

Robby


On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi 
wrote:

On my system it behaves almost exactly as described by Jon (6.3,
windows).

The one difference is that DrRacket hasn't crashed yet, but the Task
manager reports one processor at 100% and memory use slowly growing.
Currently is at 7.5 GB.





On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico 
wrote:

On 02/05/2016 08:01 AM, Robby Findler wrote:

When I run this, I see a message at the bottom of the DrRacket window
(in red):

Background expansion terminated abnormally (out of memory)

do you see this message?

I tried too, and it stops fine with the same message as Robby. No
phantom CPU usage apparent.

However, I did have a run away DrRacket recently that didn't respond to
stop and took a few minutes to kill because my UI was extremely
sluggish
(partially because X11 and/or the window manager sucks, and my CPU
probably throttled, but still...). I don't have any good data for you
about the circumstances of the issue though.

--
Anthony Carrico

--
You received this message because you are subscribed to the Google
Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You 

Re: [racket-users] a little bug

2016-02-05 Thread jon stenerson
Setting the limit lower helped. Thanks. I did not see that message about 
Background Expansion Terminated before. Now I do.


Jon

On 2/5/2016 6:55 AM, Robby Findler wrote:

It took a while for mine for the custodian limit to be reached and for
the expansion to run out of memory. It may be that the threshhold for
the memory use is too high on some systems. Maybe the right thing is
to set the default a bit lower?

Jon: if you open the "Racket" menu you should see a "Limit Memory..."
menu item. How does DrRacket do if you change the number in there to
256 and then paste the program into the definitions window? Do you see
the red message at the bottom of the screen or does DrRacket still run
out of memory?

Anthony: I don' thave a good solution for you, but I find that the
menu key short cut (control-k for you?) for killing is more likely to
get thru, because it requires a lot less event handling than the
others.

Robby


On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi  wrote:

On my system it behaves almost exactly as described by Jon (6.3, windows).

The one difference is that DrRacket hasn't crashed yet, but the Task
manager reports one processor at 100% and memory use slowly growing.
Currently is at 7.5 GB.





On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico  wrote:

On 02/05/2016 08:01 AM, Robby Findler wrote:

When I run this, I see a message at the bottom of the DrRacket window (in red):

   Background expansion terminated abnormally (out of memory)

do you see this message?

I tried too, and it stops fine with the same message as Robby. No
phantom CPU usage apparent.

However, I did have a run away DrRacket recently that didn't respond to
stop and took a few minutes to kill because my UI was extremely sluggish
(partially because X11 and/or the window manager sucks, and my CPU
probably throttled, but still...). I don't have any good data for you
about the circumstances of the issue though.

--
Anthony Carrico

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread jon stenerson
Actually you don't even have to run the program. With memory limit set 
to 1024, just open a file containing the expression and wait. After a 
minute or two DrRacket puts up a MSVC runtime error dialog.


On 2/5/2016 9:39 AM, jon stenerson wrote:
Setting the limit lower helped. Thanks. I did not see that message 
about Background Expansion Terminated before. Now I do.


Jon

On 2/5/2016 6:55 AM, Robby Findler wrote:

It took a while for mine for the custodian limit to be reached and for
the expansion to run out of memory. It may be that the threshhold for
the memory use is too high on some systems. Maybe the right thing is
to set the default a bit lower?

Jon: if you open the "Racket" menu you should see a "Limit Memory..."
menu item. How does DrRacket do if you change the number in there to
256 and then paste the program into the definitions window? Do you see
the red message at the bottom of the screen or does DrRacket still run
out of memory?

Anthony: I don' thave a good solution for you, but I find that the
menu key short cut (control-k for you?) for killing is more likely to
get thru, because it requires a lot less event handling than the
others.

Robby


On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi 
 wrote:
On my system it behaves almost exactly as described by Jon (6.3, 
windows).


The one difference is that DrRacket hasn't crashed yet, but the Task
manager reports one processor at 100% and memory use slowly growing.
Currently is at 7.5 GB.





On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico 
 wrote:

On 02/05/2016 08:01 AM, Robby Findler wrote:
When I run this, I see a message at the bottom of the DrRacket 
window (in red):


   Background expansion terminated abnormally (out of memory)

do you see this message?

I tried too, and it stops fine with the same message as Robby. No
phantom CPU usage apparent.

However, I did have a run away DrRacket recently that didn't 
respond to
stop and took a few minutes to kill because my UI was extremely 
sluggish

(partially because X11 and/or the window manager sucks, and my CPU
probably throttled, but still...). I don't have any good data for you
about the circumstances of the issue though.

--
Anthony Carrico

--
You received this message because you are subscribed to the Google 
Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to racket-users+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google 
Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to racket-users+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread Robby Findler
Sorry we can't do better. And it is really amazing how I actually
think so anthropomorphically about these things. :) That really was a
literal brain dump.

Robby

On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson  wrote:
> Thanks for the explanation. I appreciate it.
>
>
> On 2/5/2016 1:55 PM, Robby Findler wrote:
>>
>> In general, DrRacket does not promise to avoid this situation. Let me
>> explain a little bit. This program is effectively equivalent to this
>> one:
>>
>> #lang racket/base
>> (define (run l)
>>(run (cons 'x l)))
>> (run '())
>>
>> (but running at compile time, which is why things happen
>> automatically, but lets leave that aside for now).
>>
>> So when you run that program, DrRacket is asking the operating system
>> for all of its memory. At some point, the operating system says
>> "sorry, no, we're out of memory" and since the program running inside
>> DrRacket doesn't really care that we're out of memory, the operating
>> system responds with "die!". And so DrRacket dies.
>>
>> There are two ways we try to do better. First: we can set limits on
>> the memory. But if the limit is set to be higher than the amount of
>> memory available on the machine, then it is as if the memory limit
>> isn't set. Also worth noting at this point: the way that DrRacket's
>> counting of "how much memory" is only loosely related to the way that
>> your machine's vendor or the OS counts. There are some constant
>> factors of difference there that depend on things like how the garbage
>> collector is configured and how many other programs are running on
>> your system and what they are doing (like the OS itself likes to have
>> some of the memory and it (quite reasonably) doesn't want to share
>> that memory).
>>
>> The second way is that the OS will sometimes say "you are about to
>> cause me to exhaust all of the system's memory and if you do that, I
>> will kill you" at which point the GC inside Racket responds with
>> "okay, I'll just die first". The main advantage of this is that you
>> get an error message saying "out of memory" from Racket instead of an
>> error message saying "I killed your program" from the OS (which is the
>> message you're getting). It turns out to be remarkably difficult to
>> get this error message to work in all situations. We're better than we
>> used to be at it, but at some level, the best we can do in that case
>> is really just to change the text of the error message. When we're out
>> of memory like that, it's very very hard to recover if the limits are
>> not set up ahead of time (i.e. back to the previous paragraph).
>>
>> I hope this clears up the issue somewhat.
>>
>> In the meantime, I suggest you lower the memory limit for your machine.
>>
>> Robby
>>
>>
>>
>> On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson 
>> wrote:
>>>
>>> Actually you don't even have to run the program. With memory limit set to
>>> 1024, just open a file containing the expression and wait. After a minute
>>> or
>>> two DrRacket puts up a MSVC runtime error dialog.
>>>
>>>
>>> On 2/5/2016 9:39 AM, jon stenerson wrote:

 Setting the limit lower helped. Thanks. I did not see that message about
 Background Expansion Terminated before. Now I do.

 Jon

 On 2/5/2016 6:55 AM, Robby Findler wrote:
>
> It took a while for mine for the custodian limit to be reached and for
> the expansion to run out of memory. It may be that the threshhold for
> the memory use is too high on some systems. Maybe the right thing is
> to set the default a bit lower?
>
> Jon: if you open the "Racket" menu you should see a "Limit Memory..."
> menu item. How does DrRacket do if you change the number in there to
> 256 and then paste the program into the definitions window? Do you see
> the red message at the bottom of the screen or does DrRacket still run
> out of memory?
>
> Anthony: I don' thave a good solution for you, but I find that the
> menu key short cut (control-k for you?) for killing is more likely to
> get thru, because it requires a lot less event handling than the
> others.
>
> Robby
>
>
> On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi
> 
> wrote:
>>
>> On my system it behaves almost exactly as described by Jon (6.3,
>> windows).
>>
>> The one difference is that DrRacket hasn't crashed yet, but the Task
>> manager reports one processor at 100% and memory use slowly growing.
>> Currently is at 7.5 GB.
>>
>>
>>
>>
>>
>> On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico
>> 
>> wrote:
>>>
>>> On 02/05/2016 08:01 AM, Robby Findler wrote:

 When I run this, I see a message at the bottom of the DrRacket
 window
 (in red):

 Background expansion terminated abnormally (out of memory)

Re: [racket-users] a little bug

2016-02-05 Thread Robby Findler
In general, DrRacket does not promise to avoid this situation. Let me
explain a little bit. This program is effectively equivalent to this
one:

#lang racket/base
(define (run l)
  (run (cons 'x l)))
(run '())

(but running at compile time, which is why things happen
automatically, but lets leave that aside for now).

So when you run that program, DrRacket is asking the operating system
for all of its memory. At some point, the operating system says
"sorry, no, we're out of memory" and since the program running inside
DrRacket doesn't really care that we're out of memory, the operating
system responds with "die!". And so DrRacket dies.

There are two ways we try to do better. First: we can set limits on
the memory. But if the limit is set to be higher than the amount of
memory available on the machine, then it is as if the memory limit
isn't set. Also worth noting at this point: the way that DrRacket's
counting of "how much memory" is only loosely related to the way that
your machine's vendor or the OS counts. There are some constant
factors of difference there that depend on things like how the garbage
collector is configured and how many other programs are running on
your system and what they are doing (like the OS itself likes to have
some of the memory and it (quite reasonably) doesn't want to share
that memory).

The second way is that the OS will sometimes say "you are about to
cause me to exhaust all of the system's memory and if you do that, I
will kill you" at which point the GC inside Racket responds with
"okay, I'll just die first". The main advantage of this is that you
get an error message saying "out of memory" from Racket instead of an
error message saying "I killed your program" from the OS (which is the
message you're getting). It turns out to be remarkably difficult to
get this error message to work in all situations. We're better than we
used to be at it, but at some level, the best we can do in that case
is really just to change the text of the error message. When we're out
of memory like that, it's very very hard to recover if the limits are
not set up ahead of time (i.e. back to the previous paragraph).

I hope this clears up the issue somewhat.

In the meantime, I suggest you lower the memory limit for your machine.

Robby



On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson  wrote:
> Actually you don't even have to run the program. With memory limit set to
> 1024, just open a file containing the expression and wait. After a minute or
> two DrRacket puts up a MSVC runtime error dialog.
>
>
> On 2/5/2016 9:39 AM, jon stenerson wrote:
>>
>> Setting the limit lower helped. Thanks. I did not see that message about
>> Background Expansion Terminated before. Now I do.
>>
>> Jon
>>
>> On 2/5/2016 6:55 AM, Robby Findler wrote:
>>>
>>> It took a while for mine for the custodian limit to be reached and for
>>> the expansion to run out of memory. It may be that the threshhold for
>>> the memory use is too high on some systems. Maybe the right thing is
>>> to set the default a bit lower?
>>>
>>> Jon: if you open the "Racket" menu you should see a "Limit Memory..."
>>> menu item. How does DrRacket do if you change the number in there to
>>> 256 and then paste the program into the definitions window? Do you see
>>> the red message at the bottom of the screen or does DrRacket still run
>>> out of memory?
>>>
>>> Anthony: I don' thave a good solution for you, but I find that the
>>> menu key short cut (control-k for you?) for killing is more likely to
>>> get thru, because it requires a lot less event handling than the
>>> others.
>>>
>>> Robby
>>>
>>>
>>> On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi 
>>> wrote:

 On my system it behaves almost exactly as described by Jon (6.3,
 windows).

 The one difference is that DrRacket hasn't crashed yet, but the Task
 manager reports one processor at 100% and memory use slowly growing.
 Currently is at 7.5 GB.





 On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico 
 wrote:
>
> On 02/05/2016 08:01 AM, Robby Findler wrote:
>>
>> When I run this, I see a message at the bottom of the DrRacket window
>> (in red):
>>
>>Background expansion terminated abnormally (out of memory)
>>
>> do you see this message?
>
> I tried too, and it stops fine with the same message as Robby. No
> phantom CPU usage apparent.
>
> However, I did have a run away DrRacket recently that didn't respond to
> stop and took a few minutes to kill because my UI was extremely
> sluggish
> (partially because X11 and/or the window manager sucks, and my CPU
> probably throttled, but still...). I don't have any good data for you
> about the circumstances of the issue though.
>
> --
> Anthony Carrico
>
> --
> You received this message because you are subscribed to the 

Re: [racket-users] a little bug

2016-02-05 Thread Robby Findler
It took a while for mine for the custodian limit to be reached and for
the expansion to run out of memory. It may be that the threshhold for
the memory use is too high on some systems. Maybe the right thing is
to set the default a bit lower?

Jon: if you open the "Racket" menu you should see a "Limit Memory..."
menu item. How does DrRacket do if you change the number in there to
256 and then paste the program into the definitions window? Do you see
the red message at the bottom of the screen or does DrRacket still run
out of memory?

Anthony: I don' thave a good solution for you, but I find that the
menu key short cut (control-k for you?) for killing is more likely to
get thru, because it requires a lot less event handling than the
others.

Robby


On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi  wrote:
> On my system it behaves almost exactly as described by Jon (6.3, windows).
>
> The one difference is that DrRacket hasn't crashed yet, but the Task
> manager reports one processor at 100% and memory use slowly growing.
> Currently is at 7.5 GB.
>
>
>
>
>
> On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico  wrote:
>> On 02/05/2016 08:01 AM, Robby Findler wrote:
>>> When I run this, I see a message at the bottom of the DrRacket window (in 
>>> red):
>>>
>>>   Background expansion terminated abnormally (out of memory)
>>>
>>> do you see this message?
>>
>> I tried too, and it stops fine with the same message as Robby. No
>> phantom CPU usage apparent.
>>
>> However, I did have a run away DrRacket recently that didn't respond to
>> stop and took a few minutes to kill because my UI was extremely sluggish
>> (partially because X11 and/or the window manager sucks, and my CPU
>> probably throttled, but still...). I don't have any good data for you
>> about the circumstances of the issue though.
>>
>> --
>> Anthony Carrico
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Racket Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to racket-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread Robby Findler
When I run this, I see a message at the bottom of the DrRacket window (in red):

  Background expansion terminated abnormally (out of memory)

do you see this message?

Robby


On Thu, Feb 4, 2016 at 10:29 PM, jon stenerson  wrote:
>
> #lang racket
> (let ((x 1))
>   (letrec-syntax ((m (lambda (t) (syntax (m)
> (m)))
>
> When I run this in DrRacket 6.3 on Win 10 it starts looping. I hit the stop
> button. The interaction window says "user break" and is ready for another
> command.
>
> However, the windows task manager shows DrRacket being very active and
> eating more and more memory. After a minute DrRacket crashes. I guess the
> bug is that the stop button doesn't stop the expander?
>
> Jon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread Anthony Carrico
On 02/05/2016 08:01 AM, Robby Findler wrote:
> When I run this, I see a message at the bottom of the DrRacket window (in 
> red):
> 
>   Background expansion terminated abnormally (out of memory)
> 
> do you see this message?

I tried too, and it stops fine with the same message as Robby. No
phantom CPU usage apparent.

However, I did have a run away DrRacket recently that didn't respond to
stop and took a few minutes to kill because my UI was extremely sluggish
(partially because X11 and/or the window manager sucks, and my CPU
probably throttled, but still...). I don't have any good data for you
about the circumstances of the issue though.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread Pierpaolo Bernardi
On my system it behaves almost exactly as described by Jon (6.3, windows).

The one difference is that DrRacket hasn't crashed yet, but the Task
manager reports one processor at 100% and memory use slowly growing.
Currently is at 7.5 GB.





On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico  wrote:
> On 02/05/2016 08:01 AM, Robby Findler wrote:
>> When I run this, I see a message at the bottom of the DrRacket window (in 
>> red):
>>
>>   Background expansion terminated abnormally (out of memory)
>>
>> do you see this message?
>
> I tried too, and it stops fine with the same message as Robby. No
> phantom CPU usage apparent.
>
> However, I did have a run away DrRacket recently that didn't respond to
> stop and took a few minutes to kill because my UI was extremely sluggish
> (partially because X11 and/or the window manager sucks, and my CPU
> probably throttled, but still...). I don't have any good data for you
> about the circumstances of the issue though.
>
> --
> Anthony Carrico
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [racket-users] a little bug

2016-02-05 Thread jon stenerson
lol. Don't be sorry.  Speaking of anthropomorphization, I really love Dr 
Racket and hope I didn't hurt his feelings (Or is Dr Racket a she?). I 
employ his services whenever I can. I don't mean to be a whiner; he 
deserves better than that!


Jon

On 2/5/2016 3:44 PM, Robby Findler wrote:

Sorry we can't do better. And it is really amazing how I actually
think so anthropomorphically about these things. :) That really was a
literal brain dump.

Robby

On Fri, Feb 5, 2016 at 3:53 PM, jon stenerson  wrote:

Thanks for the explanation. I appreciate it.


On 2/5/2016 1:55 PM, Robby Findler wrote:

In general, DrRacket does not promise to avoid this situation. Let me
explain a little bit. This program is effectively equivalent to this
one:

#lang racket/base
(define (run l)
(run (cons 'x l)))
(run '())

(but running at compile time, which is why things happen
automatically, but lets leave that aside for now).

So when you run that program, DrRacket is asking the operating system
for all of its memory. At some point, the operating system says
"sorry, no, we're out of memory" and since the program running inside
DrRacket doesn't really care that we're out of memory, the operating
system responds with "die!". And so DrRacket dies.

There are two ways we try to do better. First: we can set limits on
the memory. But if the limit is set to be higher than the amount of
memory available on the machine, then it is as if the memory limit
isn't set. Also worth noting at this point: the way that DrRacket's
counting of "how much memory" is only loosely related to the way that
your machine's vendor or the OS counts. There are some constant
factors of difference there that depend on things like how the garbage
collector is configured and how many other programs are running on
your system and what they are doing (like the OS itself likes to have
some of the memory and it (quite reasonably) doesn't want to share
that memory).

The second way is that the OS will sometimes say "you are about to
cause me to exhaust all of the system's memory and if you do that, I
will kill you" at which point the GC inside Racket responds with
"okay, I'll just die first". The main advantage of this is that you
get an error message saying "out of memory" from Racket instead of an
error message saying "I killed your program" from the OS (which is the
message you're getting). It turns out to be remarkably difficult to
get this error message to work in all situations. We're better than we
used to be at it, but at some level, the best we can do in that case
is really just to change the text of the error message. When we're out
of memory like that, it's very very hard to recover if the limits are
not set up ahead of time (i.e. back to the previous paragraph).

I hope this clears up the issue somewhat.

In the meantime, I suggest you lower the memory limit for your machine.

Robby



On Fri, Feb 5, 2016 at 10:53 AM, jon stenerson 
wrote:

Actually you don't even have to run the program. With memory limit set to
1024, just open a file containing the expression and wait. After a minute
or
two DrRacket puts up a MSVC runtime error dialog.


On 2/5/2016 9:39 AM, jon stenerson wrote:

Setting the limit lower helped. Thanks. I did not see that message about
Background Expansion Terminated before. Now I do.

Jon

On 2/5/2016 6:55 AM, Robby Findler wrote:

It took a while for mine for the custodian limit to be reached and for
the expansion to run out of memory. It may be that the threshhold for
the memory use is too high on some systems. Maybe the right thing is
to set the default a bit lower?

Jon: if you open the "Racket" menu you should see a "Limit Memory..."
menu item. How does DrRacket do if you change the number in there to
256 and then paste the program into the definitions window? Do you see
the red message at the bottom of the screen or does DrRacket still run
out of memory?

Anthony: I don' thave a good solution for you, but I find that the
menu key short cut (control-k for you?) for killing is more likely to
get thru, because it requires a lot less event handling than the
others.

Robby


On Fri, Feb 5, 2016 at 7:41 AM, Pierpaolo Bernardi

wrote:

On my system it behaves almost exactly as described by Jon (6.3,
windows).

The one difference is that DrRacket hasn't crashed yet, but the Task
manager reports one processor at 100% and memory use slowly growing.
Currently is at 7.5 GB.





On Fri, Feb 5, 2016 at 2:29 PM, Anthony Carrico

wrote:

On 02/05/2016 08:01 AM, Robby Findler wrote:

When I run this, I see a message at the bottom of the DrRacket
window
(in red):

 Background expansion terminated abnormally (out of memory)

do you see this message?

I tried too, and it stops fine with the same message as Robby. No
phantom CPU usage apparent.

However, I did have a run away DrRacket recently that didn't respond
to
stop and took a few minutes to 

[racket-users] a little bug

2016-02-04 Thread jon stenerson


#lang racket
(let ((x 1))
  (letrec-syntax ((m (lambda (t) (syntax (m)
(m)))

When I run this in DrRacket 6.3 on Win 10 it starts looping. I hit the 
stop button. The interaction window says "user break" and is ready for 
another command.


However, the windows task manager shows DrRacket being very active and 
eating more and more memory. After a minute DrRacket crashes. I guess 
the bug is that the stop button doesn't stop the expander?


Jon

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.