parenscript issueshttps://gitlab.common-lisp.net/parenscript/parenscript/-/issues2023-02-27T09:56:39Zhttps://gitlab.common-lisp.net/parenscript/parenscript/-/issues/11Cache for encode-js-identifier is not thread safe in sbcl2023-02-27T09:56:39ZAsgeir BjørlykkeCache for encode-js-identifier is not thread safe in sbclThe cace for encode-js-identifier is not thread-safe (in sbcl) and I've encountered errors because of this.
Attaching a patch which would fix this problem.
[encode-js-identifier.diff](/uploads/0c4585908a696b8c354dc15e3d2dcdb6/encode-js...The cace for encode-js-identifier is not thread-safe (in sbcl) and I've encountered errors because of this.
Attaching a patch which would fix this problem.
[encode-js-identifier.diff](/uploads/0c4585908a696b8c354dc15e3d2dcdb6/encode-js-identifier.diff)https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/14Can't fork2023-09-22T19:30:56ZBlake McBrideblake@mcbridemail.comCan't forkI kept getting errors when I attempted to fork this repo. I ended up cloning it to https://github.com/blakemcbride/parenscript
My intent is to modernize the generate JavaScript and make it more convenient for use (like making "ps-compi...I kept getting errors when I attempted to fork this repo. I ended up cloning it to https://github.com/blakemcbride/parenscript
My intent is to modernize the generate JavaScript and make it more convenient for use (like making "ps-compile-file" actually compile a Lisp file to a JavaScript file)."https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/13Optimize out clearing MV register when all calls are to JS builtins2023-03-18T15:30:43ZBoris SmilgaOptimize out clearing MV register when all calls are to JS builtinsThe commit [8d384458](/parenscript/parenscript/-/commit/8d38445840f7a33f90f111dfcb3b82c44ff23dc8) handles the situation where a function body doesn't contain function calls, which makes the resetting of the multiple-value register at fun...The commit [8d384458](/parenscript/parenscript/-/commit/8d38445840f7a33f90f111dfcb3b82c44ff23dc8) handles the situation where a function body doesn't contain function calls, which makes the resetting of the multiple-value register at function return unnecessary. However, it leaves out another similar situation, namely, when the calls are to JS builtins, which don't ever produce multiple values. E. g.,
```
(defun foo (x)
(new (*array
(parse-int x)
((@ *object create) *some-proto (create)))))
```
can be safely translated to
```
function foo(x) {
return new Array(parseInt(x), Object.create(SomeProto, { }));
}
```
leaving out the `__PS_MV_REG = [];`.
[Attached herewith](/uploads/1bb0126e990e26756cd73c082ef35f58/f31870c.patch) is a patch which does the extra optimization.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/12Distinct behavior of `@` and `chain`2023-01-11T14:21:37ZAndré GomesDistinct behavior of `@` and `chain`I'm wondering if the following is a bug or a feature. Thank you.
```lisp
PS> (ps (@ elem child-nodes (lisp 0)))
"elem.childNodes[0];"
PS> (ps (chain elem child-nodes (lisp 0)))
"elem.childNodes.lisp(0);"
```I'm wondering if the following is a bug or a feature. Thank you.
```lisp
PS> (ps (@ elem child-nodes (lisp 0)))
"elem.childNodes[0];"
PS> (ps (chain elem child-nodes (lisp 0)))
"elem.childNodes.lisp(0);"
```https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/10`loop` is incomplete2022-08-16T18:52:04ZAndré Gomes`loop` is incompleteAs the manual mentions, `loop` is partially implemented. Here's a concrete example:
```lisp
(ps:ps (let ((foo (list "c" "d")))
(dolist (bar (list "a" "b"))
(let* ((i 0)
(a-foo (aref foo i)))
...As the manual mentions, `loop` is partially implemented. Here's a concrete example:
```lisp
(ps:ps (let ((foo (list "c" "d")))
(dolist (bar (list "a" "b"))
(let* ((i 0)
(a-foo (aref foo i)))
(setf i (1+ i))))))
```
```javascript
(function () {
var foo = ['c', 'd'];
for (var bar = null, _js_arrvar130 = ['a', 'b'], _js_idx129 = 0; _js_idx129 < _js_arrvar130.length; _js_idx129 += 1) {
bar = _js_arrvar130[_js_idx129];
var i = 0;
var aFoo = foo[i];
i += 1;
};
})();
```
```lisp
(ps:ps (let ((foo (list "c" "d")))
(loop for bar in (list "a" "b")
for i from 0
for a-foo = (aref foo i))))
```
```javascript
(function () {
var foo = ['c', 'd'];
var _js135 = ['a', 'b'];
var _js137 = _js135.length;
var FIRST138 = true;
for (var _js136 = 0; _js136 < _js137; _js136 += 1) {
var bar = _js135[_js136];
var i = FIRST138 ? 0 : i + 1;
if (i > null) {
break;
};
var aFoo = foo[i];
FIRST138 = null;
};
})();
```https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/9Prevent top level forms from being lambda wrapped2020-08-28T22:34:14ZAneil MallavarapuPrevent top level forms from being lambda wrappedIn some circumstances, it's useful to prevent lamba-wrapping of forms, particularly at the top level. Some examples include macros that add import capability, like the paren6 `import` macro. Another common one is top level forms that nee...In some circumstances, it's useful to prevent lamba-wrapping of forms, particularly at the top level. Some examples include macros that add import capability, like the paren6 `import` macro. Another common one is top level forms that need to define symbols (like classes) which need to be accessible to other forms elsewhere in the file.
Is there a way to direct `defpsmacro` to prevent lambda wrapping of generated code? I suspect there ought to be a way of binding `in-function-scope?` to get the desired behavior.
To use the [paren6 import macro](https://github.com/BnMcGn/paren6#import ) as an example, given the following code:
```commonlisp
(paren6:import (foo) "./myfile.js")
(foo)
```
Desired result:
```js
var MODSTOR551 = require('./myfile.js');
var foo = MODSTOR551.foo;
foo();
```
Actual result
```js
(function () {
var MODSTOR551 = require('./myfile.js');
var foo = MODSTOR551.foo;
})();
foo(); // Uncaught ReferenceError: foo is not defined
```
I submitted an [issue](https://github.com/BnMcGn/paren6/issues/2) to paren6, which appears to have been resolved with a bit of a hack, but I think Parenscript ought to provide a way for authors to avoid lambda wrapping through a standard mechanism.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/8compile-file-error for src/special-operators with ECL 20.4.24:2020-05-13T07:52:30ZPierre Neidhardtcompile-file-error for src/special-operators with ECL 20.4.24:Using the recently released ECL 20.4.24 (Guix package) and Parenscript from Quicklisp 2020-04-27 I get
```
COMPILE-FILE-ERROR while compiling
#<cl-source-file "parenscript" "src" "special-operators">
[Condition of type UIOP/LISP-B...Using the recently released ECL 20.4.24 (Guix package) and Parenscript from Quicklisp 2020-04-27 I get
```
COMPILE-FILE-ERROR while compiling
#<cl-source-file "parenscript" "src" "special-operators">
[Condition of type UIOP/LISP-BUILD:COMPILE-FILE-ERROR]
Restarts:
0: [RETRY] Retry compiling #<cl-source-file "parenscript" "src" "special-operators">.
1: [ACCEPT] Continue, treating compiling #<cl-source-file "parenscript" "src" "special-operators"> as having been successful.
2: [RETRY] Retry ASDF operation.
3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
4: [RETRY] Retry ASDF operation.
5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration.
--more--
Backtrace:
0: G1175
1: #<bytecompiled-function BYTECODES 0x7fad53b18000>
2: G81
3: TRACK-PACKAGE
4: G80
5: G79
6: G462
7: REPL-EVAL
8: LISTENER-EVAL
9: #<bytecompiled-function BYTECODES 0x7fad53b18050>
10: G540
11: G537
12: G571
13: REPL-LOOP
14: G50
15: G49
16: NIL
```https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/7Standard library function conversion2020-04-03T17:14:58ZPhilipp MarekStandard library function conversionWhen compiling CL functions to JS, there are quite a few functions that don't get translated correctly.
For example, `parse-integer` becomes `parseInteger`, while the JS version would be `parseInt` (yeah, and additional parameters are d...When compiling CL functions to JS, there are quite a few functions that don't get translated correctly.
For example, `parse-integer` becomes `parseInteger`, while the JS version would be `parseInt` (yeah, and additional parameters are different as well).
I'm now pondering the design of such a translation layer.
Basically, there need to be functions defined that take a CL function call (with the actual parameter values translated to variables, so that `(parse-integer input :start (+ 5 2))` would be passed as arguments `input :start #:gensym15`
with the gensym prepared outside.
The big question is, how should this translation table be stored?
* Have a `ps:translate` property on each symbol to be translated. +: Clean separation; -: only possible for already-loaded packages.
* Have a hash-table index by the string representation of each symbol for which a translation is available. +: can be loaded before other libraries; -: a bit performance impact for converting to strings, won't be garbage collected when minimizing an image.
* Have some solution that tries to load additional translations when packages have been added. +: clean and extensible, only required translations loaded; -: when/how should we detect new packages?
Thanks for all other ideas here.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/6Minor doc issue2019-10-16T04:30:51ZDaniel LoweMinor doc issueNear the bottom, it states `MAP-UNTIL` is like `MAP` but replaces the contents of the given array in-place. This should read `MAP-INTO`.Near the bottom, it states `MAP-UNTIL` is like `MAP` but replaces the contents of the given array in-place. This should read `MAP-INTO`.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/5Problem with regex2019-06-07T09:06:16ZVyacheslavProblem with regexHi.
I have a problem with strings. Can you help me?
I need to emit backslash in javascript string. Something like this `'\s'`, but instead I get `'s'` or `'\\\\s'`.
How I can emit exactly one backslash?Hi.
I have a problem with strings. Can you help me?
I need to emit backslash in javascript string. Something like this `'\s'`, but instead I get `'s'` or `'\\\\s'`.
How I can emit exactly one backslash?https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/4Catch function transpilation2019-03-26T07:13:12ZVyacheslavCatch function transpilationHello.
I try to use fetch api, but cannot use `catch` function. When I try something like this:
```common_lisp
(ps:ps
(ps:chain
(fetch "/value")
(then
(lambda (resp)
(chain resp (json))))
(catch
(lambda (err)
...Hello.
I try to use fetch api, but cannot use `catch` function. When I try something like this:
```common_lisp
(ps:ps
(ps:chain
(fetch "/value")
(then
(lambda (resp)
(chain resp (json))))
(catch
(lambda (err)
(ps:chain console (error err))))))
```
I get this:
```javascript
fetch('/value').then(function (resp) {
return resp.json();
})['catch'](function (err) {
return console.error(err);
});
```
It works, but looks strange. :) I expected this:
```javascript
fetch('/value').then(function (resp) {
return resp.json();
}).catch(function (err) {
return console.error(err);
});
```
Is this intentional?https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/3Seems that I found a bug2019-03-19T03:50:17ZVyacheslavSeems that I found a bugHello. Thanks for your great transpiler.
I think I found a bug related with transpiling `loop` macro. Here is the code that I try to use:
```common_lisp
(ps:ps (loop for price in prices
with start = price.date
with value = (ch...Hello. Thanks for your great transpiler.
I think I found a bug related with transpiling `loop` macro. Here is the code that I try to use:
```common_lisp
(ps:ps (loop for price in prices
with start = price.date
with value = (chain price value)
with end = (@ price date)
unless (= value (@ price value))
collect (prog1
(create start start
end prev
value value)
(setf start (@ price date)
value (@ price value)))
do (setf end (@ price date))))
```
Here is what I get:
```javascript
(function () {
var val1556;
var _js1554 = prices.length;
var start = price.date;
var value = chain(price, value);
var end = at(price, date);
var collect1555 = [];
for (var _js1553 = 0; _js1553 < _js1554; _js1553 += 1) {
var price = prices[_js1553];
if (value !== at(price, value)) {
collect1555.push((val1556 = create(start, start, end, prev, value, value), ((start = at(price, date), value = at(price, value)), val1556)));
};
end = at(price, date);
};
return collect1555;
})();
```
May be I'm doing something wrong, but seems that `@` and `chain` do not recognises inside `loop`.
Thanks in advance.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/2Document __PS_MV_REG2020-04-11T21:03:58ZBill St. ClairDocument __PS_MV_REGThe JavaScript variable `__PS_MV_REG` is used to return multiple values from functions. In Parenscript version 2.6, it was set only when you actually RETURNED multiple values. In 2.7, it is set to `[]` before every function return. If yo...The JavaScript variable `__PS_MV_REG` is used to return multiple values from functions. In Parenscript version 2.6, it was set only when you actually RETURNED multiple values. In 2.7, it is set to `[]` before every function return. If your JavaScript happens to `"use strict";`, this will cause a runtime error, unless you include the following before that code executes:
var __PS_MV_REG;
This declaration either needs to be added somewhere or, since I can't think of a good place to put it, other than the header of the HTML file including the Parenscript output, which isn't under Parenscript's control, documented.https://gitlab.common-lisp.net/parenscript/parenscript/-/issues/1readtable case should maybe be different on allegro (10.1)2018-10-13T20:16:11ZSky Hesterreadtable case should maybe be different on allegro (10.1)Package names were getting inverted in `src/package.lisp` during execution of `#'ql:quickload`; the problem seems to be resolved by using `:preserve` case in the parenscript `defreadtable` form.
```
(:case #-allegro :invert #+allegro :p...Package names were getting inverted in `src/package.lisp` during execution of `#'ql:quickload`; the problem seems to be resolved by using `:preserve` case in the parenscript `defreadtable` form.
```
(:case #-allegro :invert #+allegro :preserve)
```