[plt-scheme] Fr. Time questions

From: ifconfig nslookup (configurator at gmail.com)
Date: Fri Sep 17 12:28:30 EDT 2004

This is just a shot in the dark, but perhaps it is freezing regularly
because the time it takes to calculate whatever it is you are
calculating is more than, say, a second, and your code uses seconds
and thus needs to recalculate faster than possible, creating a
calculation loop which does not allow it time to refresh the display
or handle events?


On Fri, 17 Sep 2004 11:38:18 -0400 (EDT), Gregory Cooper
<greg at cs.brown.edu> wrote:
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > 1.  Dr. Scheme is still freezing regularly when I use Fr. Time.  It
> I haven't witnessed this myself, though I don't use Windows.  I'm not sure
> if it's a bug in FrTime, or FrTime exposing a bug in [the Windows version
> of] DrScheme.  While it's definitely a serious issue, I don't have any
> clear leads about where to look, at least for the moment.  Sorry.  :-(
> > 2.  Is there a way to have the dynamic updating pause and resume?  Or
> > perhaps ensure that several operations are atomic vs one update of the
> > clock?  I've written some code to simulate gravity with a planet
> Posting code would probably help, though I'll be out of town and with
> limited network access for a couple of weeks.  A more recent version of
> FrTime might help some, either from CVS or from
> http://www.cs.brown.edu/~greg/frtime.plt
> However, if the problem is really that you need to synchronize the main
> thread (which creates the signals) with the FrTime engine (which updates
> the signals), then the solution may be a bit more complicated, though
> certainly possible.
> > 3.  snapshot and value seem to freeze everything recursively.  For
> > example, the following code:
> The problem is really that FrTime's cons flattens a list of behaviors into
> a monolithic behavior.  (I've decided that this is not the way it should
> work, and fixing it is near the top of my priority list.)  For now, a
> simple fix might be to use the primitive MzScheme cons:
> (require (rename mzscheme mz:cons cons))
> (and replace every cons with mz:cons)
> I hope this helps.  Also, feel free to take the last two points off the
> list (if you want) and send follow-up questions directly to me.
> Greg

Posted on the users mailing list.