parenscript-devel May 2012

parenscript-devel@common-lisp.net

6 participants
8 discussions

[parenscript-devel] :join isn't being interpreted as a javascript function
by Russell Sim 31 Jul '12

31 Jul '12

Hi, I think I have encountered a bug while using the who-ps-html macro. (who-ps-html (:li (:img :src icon :size 40) (:p message) (:span :class "author" name) (:span :class "date" timestamp))) The first expansion of the who-ps-html yields, (STRINGIFY "<LI><IMG SRC=\"" ICON "\" SIZE=\"40\">" MESSAGE "" NAME "" TIMESTAMP "</LI>") But the javascript generated is, ['<LI><IMG SRC="', icon, '" SIZE="40">', message, '', name, '', timestamp, '</LI>']['join']('') I have been able to get the correct behaviour by applying the following patch, since join is a symbol that is imported via the ps-js-symbols package. commit 86d39309692987644798148e24fd67b70667eaa7 (HEAD, refs/heads/master) Author: Russell Sim <russell.sim(a)gmail.com> Date: Tue May 29 09:12:30 2012 +1000 Fixed :join bug in stringify expansion. Modified src/non-cl.lisp diff --git a/src/non-cl.lisp b/src/non-cl.lisp index 387bd29..f2ed0e7 100644 --- a/src/non-cl.lisp +++ b/src/non-cl.lisp @@ -203,7 +203,7 @@ (defpsmacro stringify (&rest things) (if (and (= (length things) 1) (stringp (car things))) (car things) - `((@ (list ,@things) :join) ""))) + `((@ (list ,@things) join) ""))) (defun stringify (&rest things) "Like concatenate but prints all of its arguments." (format nil "~{~A~}" things)) Cheers, Russell

3 4

[parenscript-devel] Inconsistent compilation of the empty list?
by Daniel Gackle 27 Jul '12

27 Jul '12

I have some test data where occasionally an empty list appears as an element inside of some other list. It's getting compiled to the JS string "[]" when what I need is the array literal [], in a way that seems inconsistent. Specifically, these are good: PS> (ps []) "[];" PS> (ps '()) "[];" PS> (ps '(1 2)) "[1, 2];" But these are not, because they generate either the string '[]' or null as the second element, when what I need is the array literal []: PS> (ps '(1 [])) "[1, '[]'];" PS> (ps '(1 ())) "[1, null];" Is this an inconsistency? Is there a workaround? Daniel

2 1

[parenscript-devel] top-level LET and LET* will not create global variables
by Yakov Zaytsev 27 Jul '12

27 Jul '12

Is this expected? CL-USER> (ql:quickload "parenscript") ... CL-USER> (defpackage :ps-user (:use :cl :ps)) #<The PS-USER package, 0/16 internal, 0/16 external> CL-USER> (in-package "PS-USER") #<The PS-USER package, 0/16 internal, 0/16 external> PS-USER> (ps (let ((s-a)))) "(function () { var sA = null; return null; })();" Also, $ cat foo.lisp (let ((s-a)) (+ s-a 42) (chain s-a (append-child foo))) PS-USER> (ps-compile-file "foo.lisp") "(function () { var sA = null; sA + 42; return sA.appendChild(foo); })(); " PS-USER> Which is against documentation "Top-level LET and LET* forms will create new global variables, or overwrite the values of already existing global variables with the same name." Please comment

3 2

[parenscript-devel] bug with lambda, with-slots, and if
by Andy Peterson 09 May '12

09 May '12

with latest quicklisp version. PS> (ps (with-slots (x y) p (if (< x 0) y x))) "if (p.x < 0) { p.y; } else { p.x; };" PS> (ps (lambda (p) (with-slots (x y) p (if (< x 0) y x)))) Control stack guard page temporarily disabled: proceed with caution ; Evaluation aborted on #<SB-KERNEL::CONTROL-STACK-EXHAUSTED {10050DD133}>. Backtrace: 0: (sb-kernel::control-stack-exhausted-error) 1: ("foreign function: call_into_lisp") 2: ("foreign function: post_signal_tramp") 3: (sb-impl::gethash3 0 34360628242 0) 4: ((flet #:body-fun-224564 :in sb-impl::gethash3)) 5: (lookup-macro-def x (#<hash-table :TEST eq :COUNT 2 {100507F353}> #<hash-table :TEST eq :COUNT 4 {1004118C13}>)) 6: (ps-macroexpand-1 x) 7: (ps-macroexpand x) 8: (try-expressionizing-if? 'x 1) 9: (try-expressionizing-if? (%js-getprop p 'x) 1) 10: (try-expressionizing-if? 'x 1) 11: (try-expressionizing-if? (%js-getprop p 'x) 1) 12: (try-expressionizing-if? 'x 1) 13: (try-expressionizing-if? (%js-getprop p 'x) 1) 14: (try-expressionizing-if? 'x 1) 15: (try-expressionizing-if? (%js-getprop p 'x) 1) 16: (try-expressionizing-if? 'x 1) 17: (try-expressionizing-if? (%js-getprop p 'x) 1) 18: (try-expressionizing-if? 'x 1) 19: (try-expressionizing-if? (%js-getprop p 'x) 1) The bug is not a show-stopper because I can do this: PS> (ps (lambda (p) (with-slots (x y) p (cond ((< x 0) y) (t x))))) "(function (p) { if (p.x < 0) { return p.y; } else { return p.x; }; });" -- andy

3 3

[parenscript-devel] PS LOOP now supports key-value iteration and collection
by Daniel Gackle 08 May '12

08 May '12

I've made the following changes to PS LOOP and pushed them on a branch called "loop" pending the fixing of the pretty-printer as we discussed a couple weeks ago. These changes capture some idioms that were common in our code. They deviate from CL's LOOP (I could not bring myself to implement "BEING THE HASH-KEYS OF") in ways that are appropriate for JS semantics. Since PS LOOP was not fully compatible with CL's LOOP anyway, this is not much of a loss. (1) Added a FOR..OF clause that iterates through the keys of a JS object. This translates to JS's "for k in obj" loops and corresponds roughly to "loop for k being the hash-keys of" in CL. (ps (loop :for k :of obj :do (foo k))) "for (var k in obj) { foo(k); };" To bind both key and value, you specify a pair. (This is an icky bit of syntax but it feels like the least icky option of the ones I'm aware of.) (ps (loop :for (k v) :of obj :do (foo k v))) "for (var k in obj) { var v = obj[k]; foo(k, v); };" Destructuring works on the value position just like they do everywhere else, so you can unpack an array. (Note that in this example the key variable isn't needed so we can put NIL in there.) (ps (loop :for (nil (v1 v2)) :of obj :do (foo v1 v2))) "for (var _js23095 in obj) { var _js23096 = obj[_js23095]; var v1 = _js23096[0]; var v2 = _js23096[1]; foo(v1, v2); };" ... or named properties (by using keywords): (ps (loop :for (nil (:hello :world)) :of obj :do (foo hello world))) "for (var _js23097 in obj) { var var23099 = obj[_js23097]; var hello23101 = var23099.hello; var world23102 = var23099.world; foo(hello23101, world23102); };" Side note: To get the scoping right for parallel loop clauses is tricky because LOOP orders things "step test step test" where JS's FOR does "step step test test", meaning that the second step will be evaluated even if the first test fails. It got trickier with the introduction of FOR..OF, so I adopted a simpler implementation that has some advantages (much tighter generated loop code) but also some disadvantages: (a) it was a pain to support :INITIALLY clauses so I dropped them (I'd be surprised if anyone ever used it), and (b) complex loops sometimes require an extra temporary variable to track whether the loop is on its first iteration or not. (2) There is now a MAP..TO clause that works like COLLECT only instead of building an array, builds an object mapping keys to values: (ps (loop :for str :in strs :map str :to (length str))) "(function () { var _js23109 = strs.length; var map23110 = { }; for (var _js23108 = 0; _js23108 < _js23109; _js23108 += 1) { var str = strs[_js23108]; map23110[str] = str.length; }; return map23110; })();" (3) In FOR..ON, a BY term can now be an integer. For example, you can say "by 2" instead of "by #'cddr" which makes little sense for JS arrays: (ps (loop :for (key val) :on pairs :by 2 :do (foo key val))) "for (var _js23094 = pairs; _js23094.length > 0; _js23094 = _js23094.slice(2)) { var key = _js23094[0]; var val = _js23094[1]; foo(key, val); };" If BY doesn't get a number, it assumes it got a function: (ps (loop :for (key val) :on pairs :by blah :do (foo key val))) "for (var _js23112 = pairs; _js23112.length > 0; _js23112 = blah(_js23112)) { var key = _js23112[0]; var val = _js23112[1]; foo(key, val); };" Daniel

2 1

[parenscript-devel] Inaccurate lexical capture in loop
by Daniel Gackle 08 May '12

08 May '12

PS seems to think that the variable named BLOCK is being captured by the irrelevant lambda and inserts a WITH binding. PS> (ps (loop :for i :from 0 :below 5 :do (let ((block (elt blocks i))) (foo block) (lambda () nil)))) "for (var i = 0; i < 5; i += 1) { with ({ block : null }) { var block = blocks[i]; foo(block); function () { return null; }; }; };" This doesn't happen if you take out the lambda: PS> (ps (loop :for i :from 0 :below 5 :do (let ((block (elt blocks i))) (foo block)))) "for (var i = 0; i < 5; i += 1) { var block = blocks[i]; foo(block); };" ... or even if you rename BLOCK to B: PS> (ps (loop :for i :from 0 :below 5 :do (let ((b (elt blocks i))) (foo b) (lambda () nil)))) "for (var i = 0; i < 5; i += 1) { var b = blocks[i]; foo(b); function () { return null; }; };" I thought this might be because PS had compiled a different form where BLOCK was indeed captured by closure in a loop and was remembering this inappropriately. But that doesn't seem right because the problem is reproducible on a fresh restart of PS. Daniel

2 1

[parenscript-devel] Loop return values don't get returned
by Daniel Gackle 05 May '12

05 May '12

Commit 83f4ea appears to have implemented return values from loop expressions, which is great and something I've wanted for a long time. But there seems to be a bug insofar as the return values never actually get returned: An example is this FOR loop - foo() should return 40 but returns NaN (10 * null) instead: (defun foo () (* 10 (for ((i 0)) (( i 3) (return i))))) => function foo() { return 10 * (function () { var loopResultVar6945 = null; for (var i = 0; i < 10; ++i) { if (i > 3) { loopResultVar6945 = i; break; }; }; loopResultVar6945; })(); }; I get the same result using the LOOP macro, and WHILE loops have the same problem. Daniel

2 1

[parenscript-devel] Printer inconsistencies as of 60154a
by Daniel Gackle 05 May '12

05 May '12

I've been trying to upgrade our PS version and have some problems to report. This email concerns issues with the changes to the printer in commit 60154a. Accordingly, the code samples below need to be formatted in a fixed-width font to be readable. Also, they're all in JS rather than PS for obvious reasons. I can provide the corresponding PS forms if desired. First, a simple for loop used to be printed like this: for (var n = 0; n < 10; n += 1) { blah(n); }; is now: for (var n = 0; n < 10; n += 1) { blah(n); }; Not sure if that was intended, but it's so nonstandard that I can't bear to look at it. If one were going to put line breaks in the for loop declaration, surely there ought to be a line per clause rather than an arbitrary break between the second and third. But three lines is too many and anyway the whole thing is weird; it really belongs on one line. Second, there seem to be bugs in how expressions in a comma-delimited list are line-separated and indented. Apologies for the contrived JS here, but I have to make the lines long enough to trigger an indentation. Code that used to be in one line like this: var obj = (obj3433 = { }, (obj3433.foooooooooooo = 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); is now being indented like this: var obj = (obj3433 = { }, (obj3433.foooooooooooo = 'oooooooooooooooooooooooooooooooo', obj3433.baaaaaaaaar = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', obj3433)); I like the idea, but it seems the third (and any subsequent) lines ought to be aligned with the second. Here's a real example of the same problem from our code: var bucket = (g4 = m1 - sol[label], (g5 = m2 - sol[label], (g6 = rcplus === 'col' ? rect3437[0] : rect3437[2], (g7 = rcplus === 'col' ? rect3437[1] : rect3437[3], rc === 'col' ? [g4, g5, g6, g7] : [g6, g7, g4, g5])))); There are other more complex examples of nested grouped expressions that are coming out pretty strangely: var sh = ( obj3439 = { markup : packIgrid(markup), tiling : csh.tiling, ultc : ultc, ultr : ultr }, ( (g3 = (it = csh.coldeltas, it != null && it !== false ? xcopy(it) : null), g3 != null ? (obj3439.coldeltas = g3) : null), ( g4 = (it3440 = csh.rowdeltas, it3440 != null && it3440 !== false ? xcopy(it3440) : null), g4 != null ? (obj3439.rowdeltas = g4) : null), obj3439)); It does seem like a good idea to not have all this on one line, but it's far from clear what the indentation policy is. Similar inconsistencies afflict curly braces: queueMsg(brl, { acknowledge : true }, mailbox); or: return ss.appointmentTicket = { col : c + (cols || 0), row : r + (rows || 0) }; and here's a monster one: var REGRESSIONS = [{ type : 'js', target : 'ff', file1 : 'f1', file2 : 'f2' }, { type : 'js', target : 'ie6', file1 : 'ie61', file2 : 'ie62' }, { type : 'js', target : 'ie7', file1 : 'ie71', file2 : 'ie72' }, { type : 'js', target : 'ie8', file1 : 'ie81', file2 : 'ie82' }, { type : 'js', target : 'safari', file1 : 'saf1', file2 : 'saf2' }, { type : 'js', target : 'chrome', file1 : 'chr1', file2 : 'chr2' }, { type : 'js', target : 'node', file1 : 'n1', file2 : 'n2' }, { type : 'html', target : 'ff', file1 : 'hf1', file2 : 'hf2' }, { type : 'html', target : 'ie6', file1 : 'hie61', file2 : 'hie62' }, { type : 'html', target : 'ie7', file1 : 'hie71', file2 : 'hie72' }, { type : 'html', target : 'ie8', file1 : 'hie81', file2 : 'hie82' }, { type : 'html', target : 'safari', file1 : 'hsaf1', file2 : 'hsaf2' }, { type : 'html', target : 'chrome', file1 : 'hchr1', file2 : 'hchr2' }, { type : 'css', target : 'chrome', file1 : 'c1', file2 : 'c2' }, { type : 'css', target : 'ie8', file1 : 'ie1', file2 : 'ie2' }]; I have some respect for how much harder this problem is than it appears to be, having worked on similar issues for our Numen REPL and not being too happy with what I came up with. That being said, these changes to the printer probably make the JS less readable in our case rather than more readable. It would be better to do less and have it be consistent. At a minimum, I hope we can fix the more indecorous areas. Daniel

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel May 2012