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! <br>
<br>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.<br>
<br>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&#39;m of course willing to work with someone to ensure that any blockers are resolved. <br>
<br>Thank you all, <br>-Patrick<br><br><div class="gmail_quote">On 18 August 2012 01:57, Gregory Cooper <span dir="ltr">&lt;<a href="mailto:ghcooper@gmail.com" target="_blank">ghcooper@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you change the 3 occurrences of make-hash in lang-core.rkt to<br>
make-hasheq, does that not fix things?  That seems to work for me,<br>
though it&#39;s possible my setup is not quite the same...<br>
<br>
Greg<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Aug 17, 2012 at 10:29 PM, Gregory Cooper &lt;<a href="mailto:ghcooper@gmail.com">ghcooper@gmail.com</a>&gt; wrote:<br>
&gt; Hi Patrick,<br>
&gt;<br>
&gt; Thanks for taking on this endeavor, and apologies for the suffering<br>
&gt; you must have endured in dealing with this code.<br>
&gt;<br>
&gt; If I followed your instructions correctly, it looks like things are<br>
&gt; very close to working.  One feature that seems to be broken is the<br>
&gt; storing of references to special top-level signals (which perform<br>
&gt; actions like redrawing animations or updating snips) to protect them<br>
&gt; from the garbage collector.  It&#39;s been a while since I&#39;ve looked at<br>
&gt; this code, but I&#39;ll try to investigate a bit more and see what might<br>
&gt; be going wrong.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Greg<br>
&gt;<br>
&gt; On Fri, Aug 17, 2012 at 12:51 PM, Patrick Mahoney<br>
&gt; &lt;<a href="mailto:paddy.mahoney@gmail.com">paddy.mahoney@gmail.com</a>&gt; wrote:<br>
&gt;&gt; Hello All,<br>
&gt;&gt;<br>
&gt;&gt; I have been working on updating the frtime collection to use the Racket lang<br>
&gt;&gt; rather than the mzscheme language. To this end, I forked on github and<br>
&gt;&gt; created a new branch frtime-to-racket, which can be found at:<br>
&gt;&gt; <a href="https://github.com/paddymahoney/racket.git" target="_blank">https://github.com/paddymahoney/racket.git</a><br>
&gt;&gt;<br>
&gt;&gt; This branch contains 36 commits. The first 34 are minor, and don&#39;t actually<br>
&gt;&gt; break functionality. See the commit log:<br>
&gt;&gt; <a href="https://github.com/paddymahoney/racket/commits/frtime-to-racket" target="_blank">https://github.com/paddymahoney/racket/commits/frtime-to-racket</a><br>
&gt;&gt;<br>
&gt;&gt; The 35th commit is bigger, and represents the bulk of the move of the<br>
&gt;&gt; collection and the other main modules to the racket lang rather than<br>
&gt;&gt; mzscheme. The issue I face is that this commit is breaking all of the demos<br>
&gt;&gt; within the frtime/demos/ subdirectory. These demos rely on animation.rkt at<br>
&gt;&gt; the root. The demos in the frtime/gui/demo directory don&#39;t depend on<br>
&gt;&gt; animation.rkt, and seem to work, albeit with a slow asynchronous perhaps?<br>
&gt;&gt; (perhaps some subset of the issues affecting the animation demos also affect<br>
&gt;&gt; the demos relying only on the fred wrappers).<br>
&gt;&gt;<br>
&gt;&gt; The 36th commit is a new helper &quot;develop-frtime.rkt&quot; which I use to unlink<br>
&gt;&gt; the install collection and link the development frtime collection.<br>
&gt;&gt;<br>
&gt;&gt;  I have very closely reviewed all the changes in the commit logs, and have<br>
&gt;&gt; played around extensively to try to find a particular change that has the<br>
&gt;&gt; effect of breaking the animations, to no avail.<br>
&gt;&gt;<br>
&gt;&gt; My uneducated guesses as to what is occurring:<br>
&gt;&gt; 1.  The behavior seen in running the demos is that they will typically<br>
&gt;&gt; update for a few frames or seconds, but then freeze in place. A similar<br>
&gt;&gt; issue is described in Gregory Cooper&#39;s thesis &quot;Integrating Dataflow<br>
&gt;&gt; Evaluation into a Practical<br>
&gt;&gt; Higher-Order Call-by-Value Language&quot;. From page 99:<br>
&gt;&gt; &quot;There is, however, a problem with the strategy described above that is<br>
&gt;&gt; difficult to di-agnose and debug. The symptoms are as follows: at first, the<br>
&gt;&gt; program seems to work just<br>
&gt;&gt; fine. Sometimes it may run successfully to completion. Other times,<br>
&gt;&gt; depending upon what<br>
&gt;&gt; else is happening, it runs for a while, then suddenly and seemingly without<br>
&gt;&gt; explanation the<br>
&gt;&gt; gauge’s properties stop updating when the behaviors change. The point at<br>
&gt;&gt; which it stops<br>
&gt;&gt; varies from run to run, but there are never any error messages.<br>
&gt;&gt; The problem results from an interaction with the memory manager. An ordinary<br>
&gt;&gt; FRP<br>
&gt;&gt; application would use the event source returned by the map-e, but in this<br>
&gt;&gt; case we only<br>
&gt;&gt; care about side effects, so we neglect to save the result. Since there are<br>
&gt;&gt; no references to<br>
&gt;&gt; the updating event source, the garbage collector eventually reclaims it, and<br>
&gt;&gt; the gauge stops<br>
&gt;&gt; reacting to changes in the behavior.<br>
&gt;&gt; To avoid these problems, we define a new abstraction specifically for<br>
&gt;&gt; side-effecting<br>
&gt;&gt; event processors. This abstraction, called for-each-e!, works just like<br>
&gt;&gt; map-e, except that it<br>
&gt;&gt; ensures its result will not be collected. It also lends itself to a more<br>
&gt;&gt; efficient implementa-tion, since it can throw away the results of the<br>
&gt;&gt; procedure calls instead of enqueuing them<br>
&gt;&gt; on a new event stream.&quot;<br>
&gt;&gt;<br>
&gt;&gt;&gt; this seems very much like what I see in the behavior of say,<br>
&gt;&gt;&gt; &quot;demos/analog-clock.rkt&quot;. You are often able to force an update by dragging<br>
&gt;&gt;&gt; the clock or updating the slider, and occasionally the clock will tick in<br>
&gt;&gt;&gt; the beginning. In addition, sometimes the clock won&#39;t show initially (this<br>
&gt;&gt;&gt; may occur when there is a difference in the way the dataflow graph is<br>
&gt;&gt;&gt; updated?).  However, I have been unsuccessful in determining whether this is<br>
&gt;&gt;&gt; in fact the case, or if there a distinct issue here with similar symptoms.<br>
&gt;&gt;&gt; In fact, I don&#39;t know what is occurring at all, and I am at a loss as to how<br>
&gt;&gt;&gt; to resolve this problem.<br>
&gt;&gt;<br>
&gt;&gt; 2. Something isn&#39;t being lifted.<br>
&gt;&gt;&gt; I have run Check Syntax and traced most of the bindings to ensure that<br>
&gt;&gt;&gt; lifted equivalents are being used everywhere. I can&#39;t find a binding that<br>
&gt;&gt;&gt; was not lifted, but I cannot rule this out either.<br>
&gt;&gt;&gt;Files that might be involved:<br>
&gt;&gt; lang-utils.rkt<br>
&gt;&gt; lang-core.rkt<br>
&gt;&gt; opt/frtime-opt-lang.rkt<br>
&gt;&gt;<br>
&gt;&gt; 3. Persuant to 1, garbage collection behavior/calls have changed, and the<br>
&gt;&gt; result is that some behavior is being collected prematurely. Interactions<br>
&gt;&gt; with mred usage and garbage collection might contribute if this is an issue.<br>
&gt;&gt;<br>
&gt;&gt; I have invested a ton of time into understanding enough to make even these<br>
&gt;&gt; minor changes, and really don&#39;t want to see this work die on the vine. So I<br>
&gt;&gt; open it to you Racket experts for help debugging this.<br>
&gt;&gt;<br>
&gt;&gt; Instructions to see the issue:<br>
&gt;&gt; Open a command line and:<br>
&gt;&gt;&gt; git clone <a href="https://github.com/paddymahoney/racket.git" target="_blank">https://github.com/paddymahoney/racket.git</a><br>
&gt;&gt; (you might want to do this in a different directory than that which holds<br>
&gt;&gt; another fork of racket)<br>
&gt;&gt;&gt;git checkout frtime-to-racket<br>
&gt;&gt; Open the &quot;racket/collects/frtime/develop-frtime.rkt&quot; file in drracket and<br>
&gt;&gt; update the two paths. Run the function (start-developing-frtime) to ensure<br>
&gt;&gt; that the development rather than installation collection is used when we run<br>
&gt;&gt; the demos. If you don&#39;t, any collection paths will refer to the install<br>
&gt;&gt; directory, and you will receive errors.<br>
&gt;&gt; Open &quot;racket/collects/frtime/demos/analog-clock.rkt. Run it.<br>
&gt;&gt;<br>
&gt;&gt; Please let me know if you require any further assistance reproducing this<br>
&gt;&gt; bug, and I will endeavor to provide. In addition, I will be extremely<br>
&gt;&gt; grateful for any assistance here. I&#39;d like to attend the October RacketConf,<br>
&gt;&gt; and a beverage of some kind would be in order to reward my hero.<br>
&gt;&gt;<br>
&gt;&gt; Thank you all,<br>
&gt;&gt;<br>
&gt;&gt; -Patrick<br>
&gt;&gt;<br>
&gt;&gt; ____________________<br>
&gt;&gt;   Racket Users list:<br>
&gt;&gt;   <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
&gt;&gt;<br>
</div></div></blockquote></div><br>