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

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Fri Aug 17 17:40:25 EDT 2012

I've tried to do this before and given up, so... bravo.

A few points
- It would be best to have frtime/base based on racket/base and then a
separate frtime based on racket

- In lang-utils, you dropped eq?, expand-path---but I don't think that
can be a problem

I can't see any problems right away (based on the commit logs), but
I'll try to look into it more.


On Fri, Aug 17, 2012 at 1: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
> 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

Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University

"The glory of God is Intelligence" - D&C 93

Posted on the users mailing list.