parenscript-devel August 2012

parenscript-devel@common-lisp.net

5 participants
7 discussions

[parenscript-devel] A simpler way to do multiple value return? (Was: PS test failures in 7be9b45)
by Daniel Gackle 15 Sep '12

15 Sep '12

Those test failures make sense now - thanks. Also, this comment reminded me of something: < the callee.caller property for functions, which multiple value return depends on > I dislike our implementation for multiple value return. Stuffing the values in callee.caller is complicated and doesn't feel right (I think I may have been the one who came up with it; it was a bad idea), plus it relies on one of the shakiest aspects if not of JS itself than certainly of the JS implementations. A simpler way occurred to me the other day and I'd like to know where it breaks. The argument goes like this: since JS is single-threaded and functions have to return synchronously, there can be only one function return in play at any given time, therefore there can be only one multiple-return-value list at any time, therefore why not just store it in a global variable? Say this variable is called *spillover*. Then this: (defun blah () (values 1 2 3)) (defun callblah () (multiple-value-bind (a b c) (blah) (+ a b c))) ...might compile to: function blah() { SPILLOVER = [2, 3]; return 1; }; function callblah() { var a = blah(); var b = SPILLOVER[1]; var c = SPILLOVER[2]; return a + b + c; }; There might be complicating factors that would make the JS more involved in practice, but I don't remember what they are. Apart from being so much simpler, this implementation has two advantages. First, it's "morally" better in Eugenia Cheng's sense (http://cheng.staff.shef.ac.uk/morality/morality.pdf). The multiple return values don't belong to caller or callee, but to the call itself. Caller and callee are functions that persist across many calls and ought not to have information about a specific call attached to them. That's why PS is forced to add ugly code to save the previous value attached to callee and restore it using a try/finally at the end. Second, it would fix a known problem. PS breaks when you have an interloper like FOO here: (defun blah () (values 1 2 3)) (defun foo () (blah)) (defun bar () (multiple-value-bind (a b c) (foo) (+ a b c))) BAR should return 6, and does in CL, but in PS it returns 1, because FOO doesn't return multiple values, so B and C are null and "1 + null + null" is 1 in JS. But the *spillover* hack would make BAR return 6. Could we get away with this, or what am I missing? Daniel On Tue, Aug 28, 2012 at 6:00 PM, Vladimir Sedach <vsedach(a)gmail.com> wrote: > Hi Daniel, > > Yes, those two failures in the eval test suite are expected. > CL-JavaScript doesn't have the callee.caller property for functions, > which multiple value return depends on. I wasn't sure where to comment > those tests out, so I left them in to remind myself to add > callee.caller to CL-JavaScript (I've already talked to Marijn > Haverbeke about that). > > Thank you, > Vladimir > > On Mon, Aug 27, 2012 at 11:58 PM, Daniel Gackle <danielgackle(a)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(a)common-lisp.net > > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > _______________________________________________ > parenscript-devel mailing list > parenscript-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > Those test failures make sense now - thanks. Also, this comment reminded me of something: < the callee.caller property for functions, which multiple value return depends on > I dislike our implementation for multiple value return. Stuffing the values in callee.caller is complicated and doesn't feel right (I think I may have been the one who came up with it; it was a bad idea), plus it relies on one of the shakiest aspects if not of JS itself than certainly of the JS implementations. A simpler way occurred to me the other day and I'd like to know where it breaks. The argument goes like this: since JS is single-threaded and functions have to return synchronously, there can be only one function return in play at any given time, therefore there can be only one multiple-return-value list at any time, therefore why not just store it in a global variable? Say this variable is called *spillover*. Then this: (defun blah () (values 1 2 3)) (defun callblah () (multiple-value-bind (a b c) (blah) (+ a b c))) ...might compile to: function blah() { SPILLOVER = [2, 3]; return 1; }; function callblah() { var a = blah(); var b = SPILLOVER[1]; var c = SPILLOVER[2]; return a + b + c; }; There might be complicating factors that would make the JS more involved in practice, but I don't remember what they are. Apart from being so much simpler, this implementation has two advantages. First, it's "morally" better in Eugenia Cheng's sense (http://cheng.staff.shef.ac.uk/morality/morality.pdf). The multiple return values don't belong to caller or callee, but to the call itself. Caller and callee are functions that persist across many calls and ought not to have information about a specific call attached to them. That's why PS is forced to add ugly code to save the previous value and restore it using a try/finally at the end. Second, it would fix a known problem. PS breaks when you introduce an interloper like FOO here: (defun blah () (values 1 2 3)) (defun foo () (blah)) (defun bar () (multiple-value-bind (a b c) (foo) (+ a b c))) BAR should return 6, and does in CL, but in PS it returns 1, because FOO doesn't return multiple values, so B and C are null and "1 + null + null" is 1 in JS. But the *spillover* hack would make BAR return 6. Could we get away with this, or what am I missing? Daniel

3 26

[parenscript-devel] LOOP extensions pushed; problems with eval tests
by Daniel Gackle 30 Aug '12

30 Aug '12

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(a)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.. > -------------------------------- > >

2 1

[parenscript-devel] Minor glitch in test runner: expected and actual outputs swapped
by Daniel Gackle 30 Aug '12

30 Aug '12

Working on the tests in output-tests.lisp, I noticed that failures are being reported with expected and actual values backwards. That is, when the runner says blah evaluated to "foo" which is not string= to "bar" ... "foo" is actually the expected value and "bar" the actual, so the message ought to say: blah evaluated to "bar" which is not string= to "foo". Daniel

2 1

[parenscript-devel] PS test failures in 7be9b45
by Daniel Gackle 29 Aug '12

29 Aug '12

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.. --------------------------------

2 1

Re: [parenscript-devel] four patches to PS-LOOP etc.
by Boris Smilga 11 Aug '12

11 Aug '12

On 21 Jul 2012, at 14:01, Vladimir Sedach wrote: > [...] Because patch 0003 causes all LOOPs to be > wrapped in blocks, and loop is used in various places, this means that > this code: > > (defun hello-world (&key ((:my-name-key my-name) 1)) > my-name) > > Used to look like: > > function helloWorld() { > var _js2 = arguments.length; > for (var n1 = 0; n1 < _js2; n1 += 2) { > switch (arguments[n1]) { > case 'my-name-key': > myName = arguments[n1 + 1]; > }; > }; > var myName = 'undefined' === typeof myName ? 1 : myName; > return myName; > }; > > And now looks like: > > function helloWorld() { > nilBlock: { > var _js2 = arguments.length; > for (var n1 = 0; n1 < _js2; n1 += 2) { > switch (arguments[n1]) { > case 'my-name-key': > myName = arguments[n1 + 1]; > }; > }; > }; > var myName = 'undefined' === typeof myName ? 1 : myName; > return myName; > }; > > I need a bit of time to think about the right way to fix that > (probably by fixing block not to emit if the body contains no return, > since it is all lexical) [...] Another approach would be to introduce a special PS-LOOP keyword (called NOBLOCK or something in the same vein) which would make LOOP expand to PROGN rather than to BLOCK. Then we could add the keyword to the internal LOOPs and get the PROGNs back. This is simpler than checking for RETURNs, though not necessary more elegant. That said, I don't quite see from the example above why the issue needs fixing in the first place. You can't really mean that the block introduces local scope for myName etc.? — JavaScript doesn't have block scope. So what is your idea? Yours, — B. Smilga.

2 2

[parenscript-devel] Problem using parenscript with ECL
by Magnus Malm 08 Aug '12

08 Aug '12

Hi, I am having problems loading parenscript with ECL. I use quicklisp to load parenscript. My system: Linux 2.6.32-38-generic #83-Ubuntu SMP Wed Jan 4 11:12:07 UTC 2012 x86_64 GNU/Linux Versions: - ECL 12.7.1 (git:e1fdb85bdaca39ad2d2ed06647c7f34cd0ff3585) - Quicklisp 2012-07-03 - named-readtables 2010-10-06 (named-readtables-20101006-darcs.tgz, according to quicklisp) - parenscript 2.4 When I try to load parenscript, I get the following: ---- > (ql:quickload "parenscript") To load "parenscript": Load 1 ASDF system: named-readtables Install 3 Quicklisp releases: anaphora cl-ppcre parenscript ; Fetching #<url "http://beta.quicklisp.org/archive/cl-ppcre/2010-10-06/cl-ppcre-2.0.3.tgz"> ; 153.97KB ================================================== 157,665 bytes in 0.04 seconds (4276.94KB/sec) ; Fetching #<url "http://beta.quicklisp.org/archive/anaphora/2011-06-19/anaphora-0.9.4.tgz"> ; 5.02KB ================================================== 5,136 bytes in 0.00 seconds (0.00KB/sec) ; Fetching #<url "http://beta.quicklisp.org/archive/parenscript/2012-02-08/parenscript-2.4.tgz"> ; 131.45KB ================================================== 134,604 bytes in 0.03 seconds (4107.79KB/sec) ; Loading "parenscript" [package anaphora]................................ [package anaphora-basic].......................... [package anaphora-symbol]......................... [package cl-ppcre]............................. ;;; Error: ;;; in file package.lisp, position 263 ;;; at (in-readtable parenscript) ;;; * The macro form (editor-hints.named-readtables:ensure-readtable ':parenscript) was not expanded successfully. ;;; Error detected: ;;; (editor-hints.named-readtables:ensure-readtable ':parenscript) is not of type editor-hints.named-readtables:named-readtable-designator. Condition of type: COMPILE-ERROR Error while invoking #<compile-op (:VERBOSE NIL) 0000000004ab02a0> on #<cl-source-file "parenscript" "src" "package"> Available restarts: 1. (TRY-RECOMPILING) Try recompiling package 2. (RETRY) Retry compiling #<cl-source-file "parenscript" "src" "package">. 3. (ACCEPT) Continue, treating compiling #<cl-source-file "parenscript" "src" "package"> as having been successful. 4. (ABORT) Give up on "parenscript" 5. (RESTART-TOPLEVEL) Go back to Top-Level REPL. Broken at SI:BYTECODES. [Evaluation of: (QUICKLISP-CLIENT:QUICKLOAD "parenscript")] In: #<process TOP-LEVEL>. ---- Anyone who have had the same problem? It loads fine with SBCL on the same machine, and the same quicklisp setup. Any help or pointers would be much appreciated. -- Magnus Malm

2 3

[parenscript-devel] use (ps::lisp ) as key for ps:create
by F D 07 Aug '12

07 Aug '12

Hello, How can I avoid to have an error in the following example: (let ((cancelstring "cancel")) (ps::ps (ps:create (ps::lisp cancelstring) "val"))) Error: Slot key (PARENSCRIPT:LISP CANCELSTRING) is not one of symbol, string or number. Thank you

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel August 2012