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

If you change the 3 occurrences of make-hash in lang-core.rkt to
make-hasheq, does that not fix things?  That seems to work for me,
though it's possible my setup is not quite the same...

Greg

On Fri, Aug 17, 2012 at 10:29 PM, Gregory Cooper <ghcooper at gmail.com> wrote:
> Hi Patrick,
>
> Thanks for taking on this endeavor, and apologies for the suffering
> you must have endured in dealing with this code.
>
> If I followed your instructions correctly, it looks like things are
> very close to working.  One feature that seems to be broken is the
> storing of references to special top-level signals (which perform
> actions like redrawing animations or updating snips) to protect them
> from the garbage collector.  It's been a while since I've looked at
> this code, but I'll try to investigate a bit more and see what might
> be going wrong.
>
> Cheers,
> Greg
>
> On Fri, Aug 17, 2012 at 12: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
>>