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: <a href="https://github.com/paddymahoney/racket.git">https://github.com/paddymahoney/racket.git</a> This branch contains 36 commits. The first 34 are minor, and don't actually break functionality. See the commit log: <a href="https://github.com/paddymahoney/racket/commits/frtime-to-racket">https://github.com/paddymahoney/racket/commits/frtime-to-racket</a> 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 <a href="https://github.com/paddymahoney/racket.git">https://github.com/paddymahoney/racket.git</a> (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