Hello All, <br><br>I have been working on updating the frtime collection
 to use the Racket lang rather than the mzscheme language. To this end, I
 forked on github and created a new branch frtime-to-racket, which can 
be found at: <br><a href="https://github.com/paddymahoney/racket.git">https://github.com/paddymahoney/racket.git</a><br><br>This branch contains 36 commits. The first 34 are minor, and don&#39;t actually break functionality. See the commit log: <br>
<a href="https://github.com/paddymahoney/racket/commits/frtime-to-racket">https://github.com/paddymahoney/racket/commits/frtime-to-racket</a><br><br>The
 35th commit is bigger, and represents the bulk of the move of the 
collection and the other main modules to the racket lang rather than 
mzscheme. The issue I face is that this commit is breaking all of the 
demos within the frtime/demos/ subdirectory. These demos rely on 
animation.rkt at the root. The demos in the frtime/gui/demo directory 
don&#39;t depend on animation.rkt, and seem to work, albeit with a slow 
asynchronous perhaps? (perhaps some subset of the issues affecting the 
animation demos also affect the demos relying only on the fred 
wrappers). <br>
The 36th commit is a new helper &quot;develop-frtime.rkt&quot; which I use to 
unlink the install collection and link the development frtime 
collection. <br><br> I have very closely reviewed all the changes in the
 commit logs, and have played around extensively to try to find a 
particular change that has the effect of breaking the animations, to no 
avail. <br>
My uneducated guesses as to what is occurring:<br>
1.  The behavior seen in running the demos is that they will typically 
update for a few frames or seconds, but then freeze in place. A similar 
issue is described in Gregory Cooper&#39;s thesis &quot;Integrating Dataflow Evaluation into a Practical<br>

Higher-Order Call-by-Value Language&quot;. From page 99: <br>

&quot;There is, however, a problem with the strategy described above that is 
difficult to di-agnose and debug. The symptoms are as follows: at first,
 the program seems to work just<br>

fine. Sometimes it may run successfully to completion. Other times, depending upon what<br>

else is happening, it runs for a while, then suddenly and seemingly without explanation the<br>

gauge’s properties stop updating when the behaviors change. The point at which it stops<br>

varies from run to run, but there are never any error messages.<br>

The problem results from an interaction with the memory manager. An ordinary FRP<br>

application would use the event source returned by the map-e, but in this case we only<br>

care about side effects, so we neglect to save the result. Since there are no references to<br>

the updating event source, the garbage collector eventually reclaims it, and the gauge stops<br>

reacting to changes in the behavior.<br>

To avoid these problems, we define a new abstraction specifically for side-effecting<br>

event processors. This abstraction, called for-each-e!, works just like map-e, except that it<br>

ensures its result will not be collected. It also lends itself to a more
 efficient implementa-tion, since it can throw away the results of the 
procedure calls instead of enqueuing them<br>

on a new event stream.&quot; <br>

&gt; this seems very much like what I see in the behavior of say, 
&quot;demos/analog-clock.rkt&quot;. You are often able to force an update by 
dragging the clock or updating the slider, and occasionally the clock 
will tick in the beginning. In addition, sometimes the clock won&#39;t show 
initially (this may occur when there is a difference in the way the 
dataflow graph is updated?).  However, I have been unsuccessful in 
determining whether this is in fact the case, or if there a distinct 
issue here with similar symptoms. In fact, I don&#39;t know what is 
occurring at all, and I am at a loss as to how to resolve this problem.<br>
2. Something isn&#39;t being lifted.<br>
&gt; I have run Check Syntax and traced most of the bindings to ensure 
that lifted equivalents are being used everywhere. I can&#39;t find a 
binding that was not lifted, but I cannot rule this out either.<br>
&gt;Files that might be involved: <br>
3. Persuant to 1, garbage collection behavior/calls have changed, and 
the result is that some behavior is being collected prematurely. 
Interactions with mred usage and garbage collection might contribute if 
this is an issue. <br>
I have invested a ton of time into understanding enough to make even 
these minor changes, and really don&#39;t want to see this work die on the 
vine. So I open it to you Racket experts for help debugging this. <br>
Instructions to see the issue: <br>
Open a command line and: <br>
&gt; git clone <a href="https://github.com/paddymahoney/racket.git">https://github.com/paddymahoney/racket.git</a><br>
(you might want to do this in a different directory than that which holds another fork of racket)<br>
&gt;git checkout frtime-to-racket<br>
Open the &quot;racket/collects/frtime/develop-frtime.rkt&quot; file in drracket 
and update the two paths. Run the function (start-developing-frtime) to 
ensure that the development rather than installation collection is used 
when we run the demos. If you don&#39;t, any collection paths will refer to 
the install directory, and you will receive errors. <br>
Open &quot;racket/collects/frtime/demos/analog-clock.rkt. Run it.<br>
Please let me know if you require any further assistance reproducing 
this bug, and I will endeavor to provide. In addition, I will be 
extremely grateful for any assistance here. I&#39;d like to attend the 
October RacketConf, and a beverage of some kind would be in order to 
reward my hero. <br>
Thank you all, <br>