[racket] Moving frtime to racket: animation demos hang - require assistance salvaging work on this branch

Hello All,

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:
https://github.com/paddymahoney/racket.git

This branch contains 36 commits. The first 34 are minor, and don't actually
break functionality. See the commit log:
https://github.com/paddymahoney/racket/commits/frtime-to-racket

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'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).

The 36th commit is a new helper "develop-frtime.rkt" which I use to unlink
the install collection and link the development frtime collection.

 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.

My uneducated guesses as to what is occurring:
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's thesis "Integrating Dataflow
Evaluation into a Practical
Higher-Order Call-by-Value Language". From page 99:
"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
fine. Sometimes it may run successfully to completion. Other times,
depending upon what
else is happening, it runs for a while, then suddenly and seemingly without
explanation the
gauge’s properties stop updating when the behaviors change. The point at
which it stops
varies from run to run, but there are never any error messages.
The problem results from an interaction with the memory manager. An
ordinary FRP
application would use the event source returned by the map-e, but in this
case we only
care about side effects, so we neglect to save the result. Since there are
no references to
the updating event source, the garbage collector eventually reclaims it,
and the gauge stops
reacting to changes in the behavior.
To avoid these problems, we define a new abstraction specifically for
side-effecting
event processors. This abstraction, called for-each-e!, works just like
map-e, except that it
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
on a new event stream."

> this seems very much like what I see in the behavior of say,
"demos/analog-clock.rkt". 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'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't know what is occurring at all, and I am at a
loss as to how to resolve this problem.

2. Something isn't being lifted.
> I have run Check Syntax and traced most of the bindings to ensure that
lifted equivalents are being used everywhere. I can't find a binding that
was not lifted, but I cannot rule this out either.
>Files that might be involved:
lang-utils.rkt
lang-core.rkt
opt/frtime-opt-lang.rkt

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.

I have invested a ton of time into understanding enough to make even these
minor changes, and really don't want to see this work die on the vine. So I
open it to you Racket experts for help debugging this.

Instructions to see the issue:
Open a command line and:
> git clone https://github.com/paddymahoney/racket.git
(you might want to do this in a different directory than that which holds
another fork of racket)
>git checkout frtime-to-racket
Open the "racket/collects/frtime/develop-frtime.rkt" 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't, any collection paths will refer to the install
directory, and you will receive errors.
Open "racket/collects/frtime/demos/analog-clock.rkt. Run it.

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'd like to attend the October
RacketConf, and a beverage of some kind would be in order to reward my
hero.

Thank you all,

-Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120817/b59fbe99/attachment.html>