August 2008 - parenscript-devel - mailman3.common-lisp.net

[parenscript-devel] js-script deprecated
by Wout Perquin 17 Jan '09

17 Jan '09

Hi, I am quite impressed by ParenScript. I installed it last August, but only recently I started playing with it. Some observations/comments : - js-script was in the Aug-2007 release but now it has been deprecated. By what has it been replaced ? - the js-script didn't work with with-html-output of cl-who, so I wrote my own macro js-script to do the script-tag + CDATA stuff which is still required for scripts in the header - the tutorial (Aug-28, 2007 p3) still refers to js-script -Wout

6 10

[parenscript-devel] Problems with css
by Andrei Stebakov 05 Dec '08

05 Dec '08

Hi I started to use parenscript and javascript portion of it works just fine. Now, I wanted to incorporate some css into the code and ran into problems. When I try to evaluate the sample code: (html-stream *standard-output* (html (:html (:head (css (* :border "1px solid black") (div.bl0rg :font-family "serif") (("a:active" "a:hoover") :color "black" :size "200%")))))) I get an error: Execution of a form compiled with errors. Form: ((STYLE TYPE text/css) (PRINC <!-- ) (PRINC (CSS-RULE-TO-STRING (CSS-RULE * BORDER 1px solid black)) (CSS-RULE-TO-STRING (CSS-RULE DIV.BL0RG FONT-FAMILY serif)) (CSS-RULE-TO-STRING (CSS-RULE (a:active a:hoover) COLOR black SIZE 200%))) .. [Condition of type SB-INT:COMPILED-PROGRAM-ERROR] I am using sbcl 1.0.18 on Ubuntu. How can I solve it? Thank you! Andrew

5 6

[parenscript-devel] Generating HTML in parenscript
by Gary King 26 Nov '08

26 Nov '08

I've just started playing with Parenscript and feel confused about HTML generation. Since Parenscript already includes (the unexported) process-html-forms, it seems to be able to (almost) handle much of the logic for simple HTML generation. Consider that > (parenscript::process-html-forms > `(:html > (:head (:title "ParenScript tutorial: 1st example")) > (:body (:h1 "ParenScript tutorial: 1st example") > (:p "Please click the link below." :br > ((:a :href "#" :onclick ,(ps-inline > (alert "Hello World"))) > "Hello World"))))) produces > (+ "<html/><head><title>ParenScript tutorial: 1st example</title></ > head><body><h1>ParenScript tutorial: 1st example</h1><p>Please click > the link below.<br/><a href=\"#\" onclick=\"javascript:alert(\"Hello > World\")\">Hello World</a></p></body>") It's easy to refactor process-html-forms to arrive at the (slightly incorrect) HTML in a string: > "<html/><head><title>ParenScript tutorial: 1st example</title></ > head><body><h1>ParenScript tutorial: 1st example</h1><p>Please click > the link below.<br/><a href=\"#\" onclick=\"javascript:alert(\"Hello > World\")\">Hello World</a></p></body>" and probably easy to futz with *js-inline-string-delimiter* and the like to get the correct quotes around the body of the onclick handler. So... since Parenscript doesn't do this, I have to ask "Why not"?! It would be nice to use Parenscript for simple HTML generation without having to get (Portable) AServe or some other more full-featured HTML generator. Am I missing something? thanks, -- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM

2 4

[parenscript-devel] Bug: array referencing doesn't work on conditional expression
by Daniel Gackle 14 Nov '08

14 Nov '08

(ps (aref (if a b c) 0)) => "a ? b : c[0];" instead of the correct "(a ? b : c)[0]" Daniel

2 2

[parenscript-devel] Bug: throw (and other operators) should expect an expression
by Daniel Gackle 22 Aug '08

22 Aug '08

The operators "throw", "delete", "void", "typeof", and "new" are not compiling to JS correctly. For example, (ps (throw (if a b c))) => "throw if (a) { b; } else { c; };" when it should be: "throw a ? b : c;" There is an easy fix: hunk ./src/special-forms.lisp 33 - (list 'js-named-operator ',op (compile-parenscript-form value))))) + (list 'js-named-operator ',op (compile-parenscript-form value :expecting :expression))))) Daniel

2 1

[parenscript-devel] Bug: ps::case generates incorrect code on quoted keys
by Daniel Gackle 22 Aug '08

22 Aug '08

I ran into a bug in ps::case (patch below). The trouble occurs when one of the keys that case is trying to match on is quoted: (ps::ps-macroexpand '(case val ('a (b)))) => (SWITCH VAL (QUOTE) (A (B))) This yields the following nonsensical js: "switch (val) { case quote: case a: b();};" A better macroexpansion would avoid processing the quoted form like a list, yielding: (SWITCH VAL ('A (B))) This doesn't produce any javascript, but rather an error: (ps (case val '(a (b)))) => Cannot translate quoted value A to javascript [Condition of type SIMPLE-ERROR] ... which is the desired behavior, because PS always produces this error when encountering a quoted form it doesn't understand. The reason this came up is that I'm building a specialized compiler on top of PS that handles quoted forms by turning them into strings. I've got this to work by means of :around methods on ps::compile-parenscript-form. But now the above bug with ps::case becomes a show-stopper because I need it to work with quoted keys (not just signal an error). I fixed it like so: hunk ./src/special-forms.lisp 189 - (cond ((listp val) + (cond ((and (listp val) (not (eq (car val) 'quote))) Could this fix please be added to PS? Dan

2 1

[parenscript-devel] ParenScript now uses Git for version control
by Travis Cross 22 Aug '08

22 Aug '08

Greetings all, ParenScript has migrated [4] from Darcs to Git for version control. The new repository can be cloned with the command: git clone http://common-lisp.net/project/parenscript/git/parenscript Development momentum and adoption has clearly favored Git in recent years; it is used on an increasing number of major projects (the Linux kernel, X.org, Rails, etc.) [2]. There is no risk of it being abandoned anytime soon. If it were just that though, I probably wouldn't have gone through the pain of converting. The ParenScript darcs repository has become quite slow, especially given its modest size. There are a handful of complex merges in the history that can trigger an exponential meltdown in certain situations [1]. Avoiding more of these types of merges basically means giving up the unique features of Darcs anyway. I'm a big fan of Darcs, but there is also much to love about Git. Once I discovered the power of `git rebase -i`, I stopped missing Darcs. Here are approximate translations for common commands you'll use: darcs get | git clone darcs rec | git commit -v darcs pull | git pull darcs send | git format-patch && git send-email Finally, I do understand that this change may be inconvenient for anyone with a lot of local unsubmitted patches [3]. This change should be best for the project in the long run. Cheers, -- Travis [1] For example, try pulling or unpulling the patch from Tue Jun 26 21:05:23 UTC 2007. [2] In the Lisp world, Kevin Rosenberg has notably converted all of his project repositories to Git. [3] If you find yourself in this position, you have a couple of options: * Clean up your changes and submit them upstream before your branch diverges too much. * Use darcs2git to convert your Darcs repository, then use git-rebase to splice your local changes onto the upstream repository. [4] The old repository is still available for now, but it won't be receiving any more commits.

1 0

[parenscript-devel] What's up with let
by Daniel Gackle 18 Aug '08

18 Aug '08

I need to do a bit of Parenscript hacking for my project and thought I'd upgrade to the latest source first. I had to roll back to the released version, though, because of problems with how code is being generated for let. First, the semantics of let have changed to be more Lisp-like. Is that correct? This causes some practical problems. In much of our app, performance is critical and we can't afford to have temporary variable reassignment, try/finally, and delete magic going on under the hood. What we need is plain-old, naked Javascript variable assignment - the simplest generated code possible. As of 20071104, that's exactly what PS generated for let. Now, it generates code that's considerably more complex, which we mostly can't use. Second, there's the philosophical question (debated on this list several times) about how Lispy Parenscript should try to be. There are good arguments either way, but it seems to me important to remember that Parenscript is not a CL-to-JS compiler, it's JS (plus macros) embedded in CL. The bias so far, which I agree with, has been "when in doubt, adhere closely to JS semantics", because we need the generated JS to be fast, readable, and easy to debug. That's a big deal if you spend a lot of time working with the JS in Firebug (which we do). It seems to me that a CL-to-JS compiler is impractical unless two conditions are fulfilled: the standard JS interpreters are performant enough to handle it, and we no longer have to work manually with the generated code. My questions are: (1) Does anyone need Lispy let, or can we just take it out and revert to the simpler let? (2) If it really is needed, can we come up with an easy way to offer the user their choice of assignment semantics (perhaps a special variable)? In the meantime, I'll switch back to 20071104. Daniel

5 7

[parenscript-devel] The ps-macro for length
by Daniel Gackle 17 Aug '08

17 Aug '08

Parenscript ships with a helper macro like this: (defpsmacro length (a) `(.size ,a)) But there's no "size" function for arrays or strings... in fact, is there a "size" function in JS? For most things, it seems like one would want: (defpsmacro length (a) `(@ ,a length)) What am I missing? Dan

2 1