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 <ghcoo...@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 <ghcoo...@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.maho...@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
