[plt-scheme] I miss end-of-time...

From: engineer at alum.mit.edu (engineer at alum.mit.edu)
Date: Fri Mar 12 11:05:03 EST 2010

At least two of us misunderstood how (stop-when last-world?) works.  I came
up short looking in the docs for an explanation of the errors we were
causing...
 
The doc for (stop-when last-world?) says "the world program is shut down."
Period, end of statement; the specifics that follow do not mention another
call to render.

The doc for (stop-when last-world? last-picture) adds, "after displaying the
world one last time, this time using the scene rendered with last-picture."

I, like Stephen, thought last-world? succeeded render because our programs
weren't stopping until after the drawing.  So we thought we would need to
have our render function deal with an end-state world.  I took the
last-world option in stop-when to be a chance to display one extra last
message and thus not very useful.  But I see it now.

If I understand things correctly, the doc for (stop-when last-world?) should
include a little more, as in, "the world program is shut down after
displaying the world one last time."  With that phrase included, readers
will realize that one more call to render will follow last-world?.

-Paul

-----Original Message-----
From: plt-scheme-bounces at list.cs.brown.edu
[mailto:plt-scheme-bounces at list.cs.brown.edu] On Behalf Of
engineer at alum.mit.edu
Sent: Thursday, March 11, 2010 4:33 PM
To: undisclosed-recipients:
Cc: 'PLT-Scheme Mailing List'
Subject: RE: [plt-scheme] I miss end-of-time...

Nice.  So stop-when does get called before the draw-handler (and after the
tick-handler).  The errors mentioned below are not due to sequencing but
because no alternative draw-handler was specified in the stop-when.

-Paul

-----Original Message-----
From: Carl Eastlund [mailto:carl.eastlund at gmail.com] 
Sent: Thursday, March 11, 2010 3:16 PM
To: engineer at alum.mit.edu
Cc: PLT-Scheme Mailing List
Subject: Re: [plt-scheme] I miss end-of-time...

...and the alternate form of stop-when alleviates that problem by
providing an alternate renderer, which can display something like "End
of Game".

Carl Eastlund

On Thu, Mar 11, 2010 at 3:12 PM,  <engineer at alum.mit.edu> wrote:
> Using a boolean poses the same problem as using a negative number.
>
> -----Original Message-----
> From: plt-scheme-bounces at list.cs.brown.edu
> [mailto:plt-scheme-bounces at list.cs.brown.edu] On Behalf Of Carl Eastlund
> Sent: Thursday, March 11, 2010 3:04 PM
> To: Stephen Bloch
> Cc: PLT-Scheme Mailing List
> Subject: Re: [plt-scheme] I miss end-of-time...
>
> I recommend representing the world as either Nat or false, using false
> for end of game, and use the (stop-when stop? draw) form that lets you
> specify an alternate rendering function for the final world.  That
> form was added specifically for this case, so that if you have an
> alternate world for the end of the game you can draw it separately.
>
> Carl Eastlund
>
> On Thu, Mar 11, 2010 at 2:34 PM, Stephen Bloch <BLOCH at adelphi.edu> wrote:
>> In recent versions of the world/universe teachpacks, the "end-of-time"
> function has been removed.  This makes some animations considerably harder
> or more unnatural to write.
>>
>> Try this: write an animation of a disk whose radius starts at 0 and grows
> by 1 pixel per second.  The animation stops when the user presses any key
on
> the keyboard.
>>
>> You could do this with a struct that contains a "quitting?" field, but my
> students won't see structs for several more weeks. So the model has to be
> just a number.  Now how could the key handler indicate, with a number,
that
> the animation should stop?
>>
>> Well, we could use a negative number, since it'll never go negative in
the
> normal course of events... but since the draw handler is called after the
> tick/mouse/key handlers but before the stop-when handler, that means we're
> going to call a function that draws a disk of specified radius with a
> negative number, and it'll crash.  We could write the draw handler to
check
> whether the number is negative before trying to draw a disk of that
radius,
> but (a) that adds unnecessary complexity, and (b) my students won't see
> conditionals for another week and a half.



Posted on the users mailing list.