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