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

Hello Matthias,
The git pull request was created-https://github.com/plt/racket/pull/138

I'll follow up there to ensure that the code is in shape to merge. I can
also defend if some of the decisions don't make sense. Thank you for the
pointer!

:)

-Patrick

On 21 August 2012 20:18, Matthias Felleisen <matthias at ccs.neu.edu> wrote:

>
> Can you create a git pull request? -- Matthias
>
>
>
> On Aug 21, 2012, at 8:13 PM, Patrick Mahoney wrote:
>
> 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
>> >>
>>
>
> ____________________
>  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/3bee6e72/attachment-0001.html>