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 <matth...@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 <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 > > >
____________________ Racket Users list: http://lists.racket-lang.org/users
