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

Upon changing the 3 occurrences of make-hash in lang-core.rkt to
make-hasheq, the demos/ animations begin to animate. At this moment, and
after rolling back an earlier commit to lang-core.rkt, all of the demos in
the demos folder are now working! Thank you for this fix Gregory!

My goal was to perform a basic migration here-use Racket lang everywhere,
excise as many mzlib dependencies as possible while still maintaining
functionality. At this point, I consider this goal met-all of the demos are
functioning, the language now extends racket vs. scheme or mzscheme. The
scribble is updated to reflect this change.

I am interested in having these changes incorporated into a future Racket
release. How can I go about having these changes reviewed and merged into
some development branch? I'm of course willing to work with someone to
ensure that any blockers are resolved.

Thank you all,
-Patrick

On 18 August 2012 01:57, Gregory Cooper <ghcooper at gmail.com> wrote:

> 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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20120821/25c176b2/attachment-0001.html>