<div>As described in my previous email (see below), I've now pushed the</div><div>LOOP extensions after fixing a number of failing js output tests. The</div><div>glitch I mentioned turned out not to be a problem after all. As far</div>
<div>as I can tell, my changes and Boris' play nicely together. (Thanks</div><div>again Boris!) Also, I'll repeat here that I've deleted support for the</div><div>:INITIALLY clause, because it was making the implementation a pain and</div>
<div>I don't know of anyone who uses it. If that's a problem, speak up and</div><div>we'll figure something out.</div><div><br></div><div>I've also added a bunch of new output tests for LOOP and two new eval</div>
<div>tests for LOOP... whereupon I hit a problem.</div><div><br></div><div>Here are the two new eval tests:</div><div><br></div><div> (test-js-eval loop-append</div><div> (loop :for i :from 0 :below 10 :by 3 :append (list i (* i 100)))</div>
<div> '(0 0 3 300 6 600 9 900))</div><div><br></div><div> (test-js-eval loop-for-on</div><div> (loop :for (a b) :on '(10 20 30 40 50 60) :by 2 :collect (list b a))</div><div> '((20 10) (40 30) (60 50)))</div>
<div><br></div><div>The first one passes and the second one fails. Unfortunately, the</div><div>message given upon failure is not very useful. It prints the actual</div><div>value as NIL when it clearly isn't NIL but rather some kind of</div>
<div>unexpected JS object:</div><div><br></div><div>loop-for-on []: </div><div> (funcall (if (typep #:g21383 'structure-object) #'equalp #'equal) #:g21383 (jsarray '((20 10) (40 30) (60 50)))) was NIL..</div>
<div> </div><div>I spent some time mucking around with CL-JS trying to get some</div><div>transparency into that damn value, with little success. CL-JS's</div><div>*PRINTLIB* facility prints nested arrays only by flattening them,</div>
<div>which seems rather shoddy, but running it does suggest that the</div><div>correct array is being produced. My bet is that the test runner's</div><div>equality operator is breaking on the nesting. In fact that's very</div>
<div>likely the case because this trivial test fails:</div><div><br></div><div> (test-js-eval nested-array</div><div> '((20 10) (40 30) (60 50))</div><div> '((20 10) (40 30) (60 50)))</div><div><br></div>
<div>So, before I add more eval tests for LOOP, two questions:</div><div><br></div><div>(1) Can we make the test output more informative than NIL when an</div><div> expression doesn't have the expected value?</div>
<div><br></div><div>(2) Can we run the tests with an equality operator that handles</div><div> nested arrays and see if it fixes that failing test?</div><div><br></div><div>Daniel</div><div><br></div><br><div class="gmail_quote">
On Mon, Aug 27, 2012 at 9:58 PM, Daniel Gackle <span dir="ltr"><<a href="mailto:danielgackle@gmail.com" target="_blank">danielgackle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I've rebased my PS LOOP extensions [1] onto the latest commit</div><div>(7be9b45) and recompiled Skysheet. The generated JS looks fine. There</div><div>was one glitch that I'll report separately along with a workaround.</div>
<div>Before pushing the LOOP extensions onto master, though, I want to</div><div>update any relevant PS tests. Some will fail because the LOOP output</div><div>has changed quite a bit. Unfortunately I'm also seeing failures when I</div>
<div>run the tests in 7be9b45, which is prior to any of these LOOP</div><div>changes. I've pasted the output below [2]. It doesn't look like these</div><div>failures are related to work in ps-loop.lisp, so I'll just ignore them</div>
<div>for the time being, but Vladimir can you please comment on whether you</div><div>know about them or whether there's something unexpected going on?</div><div><br></div><div>Daniel</div><div><br></div><div>[1] These are the constructs FOR..OF and MAP..TO, plus a change to</div>
<div>FOR..ON, that I described in my email to this list on April 11. They</div><div>are currently sitting in the "loop" branch. Rebasing them was</div><div>nontrivial because of Boris' additions to ps-loop.lisp, but it seems</div>
<div>to have all gone ok. Boris, if you're reading this, please look out for any</div><div>regressions once I push these changes and let us know if you notice anything.</div><div><br></div><div>[2] Running output tests:</div>
<div>........................................................................................................................................................................................................................................................................................................................................................................................................................................</div>
<div> Did 424 checks.</div><div> Pass: 424 (100%)</div><div> Skip: 0 ( 0%)</div><div> Fail: 0 ( 0%)</div><div>Running package system tests:</div><div>.........</div><div> Did 9 checks.</div><div> Pass: 9 (100%)</div>
<div> Skip: 0 ( 0%)</div><div> Fail: 0 ( 0%)</div><div>Running CL-JavaScript eval tests:</div><div>...........................f...............X......................</div><div> Did 66 checks.</div><div> Pass: 64 (96%)</div>
<div> Skip: 0 ( 0%)</div><div> Fail: 2 ( 3%)</div><div> Failure Details:</div><div> --------------------------------</div><div> mv-return1 []: </div><div> Unexpected Error: #<cl-js:js-condition #x30200155257D></div>
<div>[js] TypeError: undefined has no properties...</div><div> --------------------------------</div><div> --------------------------------</div><div> dynamic-extent-function-return-values []: </div><div> (funcall (if (typep #:g36204 'structure-object) #'equalp #'equal) #:g36204 (jsarray '(1 2 3))) was NIL..</div>
<div> --------------------------------</div><div><br></div>
</blockquote></div><br>