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

I don't see anything obvious, but two things usually trip me up in
this transition: make-hash-table creates eq?-based hash tables and
make-hash creates equal?-based hash tables, and pretty-print in older
code is called pretty-write in newer code. You should probably also
read over the release notes as they'll highlight the big gotchas with
this kind of transition (I think).

I'm guessing that you don't have very good unit tests to work with
here, so if you have energy to take that route, I'd say that building
them might also be a good approach (and it will help future
contributors to this codebase!). Just work to find a difference in
behavior between the two versions, codifying the behavior of old
functions in a test suite and looking for differences in the new
versions of the functions.

Robby

On Fri, Aug 17, 2012 at 2:51 PM, Patrick Mahoney
<paddy.mahoney at gmail.com> wrote:
> 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
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>