parenscript-devel

parenscript-devel@common-lisp.net

373 discussions

[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

[parenscript-devel] BUG in css-to-string?
by Stuart Overton 22 May '08

22 May '08

I'm really liking parenscript and just got started with it, so this question might be off base, but here goes... I'm writing a parenscript/cl-who/hunchentoot application, and I'm using some code along the lines of: (css-to-string '(((a.foo) (:color "green" :font-size "25pt")) ((a.foo\:hover) (:color "red")))) which generates the following string: "A.FOO { color:green; font-size:25pt; } ; A.FOO:HOVER { color:red; } " Firefox doesn't seem to like the second rule, since it starts with a semicolon. The code of css-to-string I have is: (defun css-to-string (rules) (string-join (mapcar #'css-rule-to-string rules) "; ")) If I substitute it with (defun css-to-string (rules) (concatenate 'string (mapcar #'css-rule-to-string rules))) That problem goes away and Firefox recognizes the second rule. Am I doing something wrong or is this a bug?

1 1

[parenscript-devel] bug with in operator
by Andrew Peterson 12 May '08

12 May '08

SBCL 1.0.12 CL-USER> (require :parenscript) NIL CL-USER> (ps:ps (in p o)) "p IN o;" CL-USER> "in" should be lower case. I tried both the tar version parenscript-20071104 and the latest version at http://common-lisp.net/project/parenscript/repository/parenscript/ andy peterson

2 1

[parenscript-devel] Convenient syntax for array literals
by Daniel Gackle 19 Apr '08

19 Apr '08

Here's a neat little ps macro for easy creation of array literals, including nested arrays: (ps ([] 1 2 3)) => "[1, 2, 3];" (ps ([] 1 (2 3))) => "[1, [2, 3]];" (ps ([] (1 2) ("a" "b"))) => "[[1, 2], ['a', 'b']];" Daniel (defpsmacro [] (&rest args) `(array ,@(mapcar (lambda (arg) (if (and (consp arg) (not (equal '[] (car arg)))) (cons '[] arg) arg)) args)))

1 0

[parenscript-devel] Lisp-like shadowing behavior
by Daniel Gackle 18 Apr '08

18 Apr '08

Below is a ps macro that simulates the shadowing of special variables in Lisp. I'm wondering if anyone thinks this would be useful to add to Parenscript. I wrote it because I have some Javascript functions that reference global variables, and wanted to write some test functions for those without modifying global state. One option of course would be to simply write the original functions to take parameters instead of the global variables. But that complicates their signatures and I'm loath to modify production code to suit tests. With this macro, my test can do this: (ps (shadow-let ((*global-var* "test value")) (function-that-uses-global-var))) and the original value of *global-var* will be restored: var _js3778 = null; try { _js3778 = GLOBALVAR; GLOBALVAR = 'test value'; functionThatUsesGlobalVar(); } finally { GLOBALVAR = _js3778; }; Daniel ------------------------------------------------------------------------ (defpsmacro shadow-let (bindings &body body) (labels ((wrap-expr (bindings body) (if (null bindings) body (list (list 'temporarily-bind (car bindings) (wrap-expr (cdr bindings) body)))))) `(macrolet ((temporarily-bind ((var expr) body) (with-ps-gensyms (temp) `(progn (defvar ,temp nil) (try (progn (setf ,temp ,var) (setf ,var ,expr) ,@body) (:finally (setf ,var ,temp))))))) ,(cons 'progn (wrap-expr bindings body)))))

3 3

[parenscript-devel] The PS code expander in Slime
by Daniel Gackle 01 Apr '08

01 Apr '08

A brief public-service announcement: Is anyone out there using Parenscript with Slime who doesn't know about Vladimir's amazing code expander? Being able to see the generated JS for any PS expression just by hitting C-c j is soooo useful... pretty much guaranteed to speed up your work. http://common-lisp.net/pipermail/bese-devel/2007-June/002999.html Dan

2 1

← Newer
1
...
28
29
30
31
32
33
34
...
38
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

parenscript-devel