Henrik Hjelte mentioned the ParenScript tests, which is a subject I want to bring up since I currently can't run them. The tests are based on FiveAM, the Bese testing framework, however the asdf-install for it is broken right now (it depends on Arnesi, the Bese utility library, which isn't asdf-installable, and when I go pull it from the Bese darcs repository it still has mystery dependencies on other Bese code). Since I don't want to invest time and effort into making FiveAM easy to install, I think maybe we should consider switching test frameworks to something that Just Works? Does anyone have suggestions?
Vladimir
Hello!
On Fri, 22 Jun 2007 18:01:12 +0100, Vladimir Sedach wrote:
The tests are based on FiveAM, the Bese testing framework, however the asdf-install for it is broken right now (it depends on Arnesi, the Bese utility library, which isn't asdf-installable, and when I go pull it from the Bese darcs repository it still has mystery dependencies on other Bese code).
AFAIK arnesi doesn't depend on any other Bese tool, it's mostly the contrary:
===== [18:42] luca@gismo:~$ darcs get http://common-lisp.net/project/bese/repos/arnesi_dev/ Copying patch 343 of 343... done! Applying patch 343 of 343... done. Finished getting. [18:43] luca@gismo:~$ mv /home/luca/.clc/ /home/luca/clc [18:44] luca@gismo:~$ cd arnesi_dev/ [18:44] luca@gismo:~/arnesi_dev$ [18:44] luca@gismo:~/arnesi_dev$ sbcl This is SBCL 1.0.6, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (asdf:oos 'asdf:load-op 'arnesi) [...] ; ; compilation unit finished ; caught 3 STYLE-WARNING conditions ; printed 4 notes NIL * (quit) [18:45] luca@gismo:~/arnesi_dev$ =====
What's broken is FiveAM, as reported at [1]. Fixing it with the suggestion at [2] generates another error, which I'm trying to narrow down and fix [3].
Since I don't want to invest time and effort into making FiveAM easy to install, I think maybe we should consider switching test frameworks to something that Just Works?
Well, IMHO `darcs get` is fairly simple.
Thx, bye, Gismo / Luca
Footnotes: [1] http://common-lisp.net/pipermail/bese-devel/2007-May/002983.html [2] http://common-lisp.net/pipermail/bese-devel/2007-April/002952.html [3] because I want to update the Debian Bese packages as well
Ok, then I'll just wait for your fix.
Thanks, Vladimir
On 6/22/07, Luca Capello luca@pca.it wrote:
Hello!
On Fri, 22 Jun 2007 18:01:12 +0100, Vladimir Sedach wrote:
The tests are based on FiveAM, the Bese testing framework, however the asdf-install for it is broken right now (it depends on Arnesi, the Bese utility library, which isn't asdf-installable, and when I go pull it from the Bese darcs repository it still has mystery dependencies on other Bese code).
AFAIK arnesi doesn't depend on any other Bese tool, it's mostly the contrary:
===== [18:42] luca@gismo:~$ darcs get http://common-lisp.net/project/bese/repos/arnesi_dev/ Copying patch 343 of 343... done! Applying patch 343 of 343... done. Finished getting. [18:43] luca@gismo:~$ mv /home/luca/.clc/ /home/luca/clc [18:44] luca@gismo:~$ cd arnesi_dev/ [18:44] luca@gismo:~/arnesi_dev$ [18:44] luca@gismo:~/arnesi_dev$ sbcl This is SBCL 1.0.6, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information.
- (asdf:oos 'asdf:load-op 'arnesi)
[...] ; ; compilation unit finished ; caught 3 STYLE-WARNING conditions ; printed 4 notes NIL
- (quit)
[18:45] luca@gismo:~/arnesi_dev$
What's broken is FiveAM, as reported at [1]. Fixing it with the suggestion at [2] generates another error, which I'm trying to narrow down and fix [3].
Since I don't want to invest time and effort into making FiveAM easy to install, I think maybe we should consider switching test frameworks to something that Just Works?
Well, IMHO `darcs get` is fairly simple.
Thx, bye, Gismo / Luca
Footnotes: [1] http://common-lisp.net/pipermail/bese-devel/2007-May/002983.html [2] http://common-lisp.net/pipermail/bese-devel/2007-April/002952.html [3] because I want to update the Debian Bese packages as well _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Hello!
On Fri, 22 Jun 2007 20:33:15 +0200, Vladimir Sedach wrote:
Ok, then I'll just wait for your fix.
The FiveAM problem was fixed with the latest patches, but now there's a new problem with parenscript.test, in part similar to [1]:
--8<---------------cut here---------------start------------->8--- ; /var/cache/common-lisp-controller/1000/sbcl/local/home/luca/Hacking/debdarcs/parenscript-upstream/t/test-package.fasl written ; compilation finished in 0:00:00 ; compiling file "/home/luca/Hacking/debdarcs/parenscript-upstream/t/test.lisp" (written 17 JUN 2007 09:22:25 PM): ; compiling (IN-PACKAGE :JS-TEST) ; compiling (DEFUN TRIM-WHITESPACE ...) ; compiling (DEFUN SAME-SPACE-BETWEEN-STATEMENTS ...) ; compiling (DEFUN NO-INDENTATION ...) ; compiling (DEFUN NO-TRAILING-SPACES ...) ; compiling (DEFUN NORMALIZE-JS-CODE ...) ; compiling (DEFMACRO TEST-PS-JS ...) ; compiling (DEFUN RUN-TESTS ...) ; compiling (DEF-SUITE PS-TESTS) ; compiling (IN-SUITE PS-TESTS) debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {10025DEB61}>: Unkown suite PS-TESTS.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Create a new suite named PS-TESTS. 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {10044E5901}> on #<ASDF:CL-SOURCE-FILE "test" {1003214501}>. 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {10044E5901}> on #<ASDF:CL-SOURCE-FILE "test" {1003214501}> as having been successful. 3: [ABORT ] Exit debugger, returning to top level.
(NIL) 0] --8<---------------cut here---------------end--------------->8---
This can be solved with the same patch as at [1] (darcs patch attached), but then the compilation stops again:
--8<---------------cut here---------------start------------->8--- ; compiling (TEST-PS-JS DOT-NOTATION-BUG ...) ; compiling (TEST-PS-JS METHOD-CALL-OP-FORM ...) ; compiling (TEST-PS-JS METHOD-CALL-NUMBER ...) ; compiling (TEST-PS-JS METHOD-CALL-STRING ...); compilation aborted because of fatal error: ; READ failure in COMPILE-FILE: ; READER-ERROR at 2528 (line 82, column 44) on #<SB-SYS:FD-STREAM for "file /home/luca/Hacking/debdarcs/parenscript-upstream/t/test.lisp" {10032C80C1}>:
; /var/cache/common-lisp-controller/1000/sbcl/local/home/luca/Hacking/debdarcs/parenscript-upstream/t/test.fasl written ; compilation finished in 0:00:01 ; illegal terminating character after a colon: #\ WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {1003A661E1}> on #<CL-SOURCE-FILE "test" {10039BFF91}>.
debugger invoked on a ASDF:COMPILE-FAILED in thread #<THREAD "initial thread" {10025DEB61}>: erred while invoking #<COMPILE-OP NIL {1003A661E1}> on #<CL-SOURCE-FILE "test" {10039BFF91}>
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {1003A661E1}> on #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}>. 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {1003A661E1}> on #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level.
((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP NIL {1003A661E1}> #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}>) 0] --8<---------------cut here---------------end--------------->8---
This one is probably a typo, in fact removing the colon solves it (darcs patch attached).
However, the compilation is successful only on SBCL-1.0.6.0, because on CLisp-2.41 (both on a Debian sid) I get:
--8<---------------cut here---------------start------------->8--- ;; Compiling file /home/luca/var/lib/debdarcs/parenscript-upstream/t/test-package.lisp ... ;; Wrote file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test-package.fas ;; Loading file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test-package.fas ... ;; Loaded file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test-package.fas ;; Compiling file /home/luca/var/lib/debdarcs/parenscript-upstream/t/test.lisp ... *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/home/luca/var/lib/debdarcs/parenscript-upstream/t/test.lisp" @212>: there is no character with name "FORM" The following restarts are available: RETRY :R1 Retry performing #<ASDF:COMPILE-OP NIL #x000333D42988> on #<ASDF:CL-SOURCE-FILE "test" #x000333CFAC80>. ACCEPT :R2 Continue, treating #<ASDF:COMPILE-OP NIL #x000333D42988> on #<ASDF:CL-SOURCE-FILE "test" #x000333CFAC80> as having been successful. ABORT :R3 ABORT Break 1 JS-TEST[3]> --8<---------------cut here---------------end--------------->8---
Commenting out line 212 in test.lisp solves the problem. Is my CLisp too old or is something other?
Thx, bye, Gismo / Luca
Footnotes: [1] http://common-lisp.net/pipermail/bese-devel/2007-July/003044.html
I pushed your changes and fixed the character encoding problem for CLisp (by changing #\Form to (code-char 12)).
There are, however, still many tests that fail. The bulk of these failures are because of semantically meaningless differences in parenscript-compiled javascript and the expected javascript. for example:
Failure Details:
--------------------------------
METHOD-CALL-LAMBDA-CALL []: (NORMALIZE-JS-CODE JS-CODE) evaluated to "(function (x) {return x;
})(10).toString()", which is not STRING= to "(function (x) {
return x;
})
(10).toString()"..
It is worth considering using a Javascript parser compare expected vs. compiled Javascript instead of using the slight hack in the current testing code.
Anyhow, now that 5am is compiling we might want to get tests working again.
Thanks, Red
On 7/1/07, Luca Capello luca@pca.it wrote:
Hello!
On Fri, 22 Jun 2007 20:33:15 +0200, Vladimir Sedach wrote:
Ok, then I'll just wait for your fix.
The FiveAM problem was fixed with the latest patches, but now there's a new problem with parenscript.test, in part similar to [1]:
--8<---------------cut here---------------start------------->8--- ; /var/cache/common-lisp-controller/1000/sbcl/local/home/luca/Hacking/debdarcs/parenscript-upstream/t/test- package.fasl written ; compilation finished in 0:00:00 ; compiling file "/home/luca/Hacking/debdarcs/parenscript-upstream/t/test.lisp" (written 17 JUN 2007 09:22:25 PM): ; compiling (IN-PACKAGE :JS-TEST) ; compiling (DEFUN TRIM-WHITESPACE ...) ; compiling (DEFUN SAME-SPACE-BETWEEN-STATEMENTS ...) ; compiling (DEFUN NO-INDENTATION ...) ; compiling (DEFUN NO-TRAILING-SPACES ...) ; compiling (DEFUN NORMALIZE-JS-CODE ...) ; compiling (DEFMACRO TEST-PS-JS ...) ; compiling (DEFUN RUN-TESTS ...) ; compiling (DEF-SUITE PS-TESTS) ; compiling (IN-SUITE PS-TESTS) debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {10025DEB61}>: Unkown suite PS-TESTS.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Create a new suite named PS-TESTS. 1: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {10044E5901}> on #<ASDF:CL-SOURCE-FILE "test" {1003214501}>. 2: [ACCEPT ] Continue, treating #<ASDF:COMPILE-OP NIL {10044E5901}> on #<ASDF:CL-SOURCE-FILE "test" {1003214501}> as having been successful. 3: [ABORT ] Exit debugger, returning to top level.
(NIL) 0] --8<---------------cut here---------------end--------------->8---
This can be solved with the same patch as at [1] (darcs patch attached), but then the compilation stops again:
--8<---------------cut here---------------start------------->8--- ; compiling (TEST-PS-JS DOT-NOTATION-BUG ...) ; compiling (TEST-PS-JS METHOD-CALL-OP-FORM ...) ; compiling (TEST-PS-JS METHOD-CALL-NUMBER ...) ; compiling (TEST-PS-JS METHOD-CALL-STRING ...); compilation aborted because of fatal error: ; READ failure in COMPILE-FILE: ; READER-ERROR at 2528 (line 82, column 44) on #<SB-SYS:FD-STREAM for "file /home/luca/Hacking/debdarcs/parenscript-upstream/t/test.lisp" {10032C80C1}>:
; /var/cache/common-lisp-controller/1000/sbcl/local/home/luca/Hacking/debdarcs/parenscript-upstream/t/test.fasl written ; compilation finished in 0:00:01 ; illegal terminating character after a colon: #\ WARNING: COMPILE-FILE warned while performing #<COMPILE-OP NIL {1003A661E1}> on #<CL-SOURCE-FILE "test" {10039BFF91}>.
debugger invoked on a ASDF:COMPILE-FAILED in thread #<THREAD "initial thread" {10025DEB61}>: erred while invoking #<COMPILE-OP NIL {1003A661E1}> on #<CL-SOURCE-FILE "test" {10039BFF91}>
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:COMPILE-OP NIL {1003A661E1}> on #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}>. 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {1003A661E1}> on #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level.
((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable argument> #<ASDF:COMPILE-OP NIL {1003A661E1}> #<ASDF:CL-SOURCE-FILE "test" {10039BFF91}>) 0] --8<---------------cut here---------------end--------------->8---
This one is probably a typo, in fact removing the colon solves it (darcs patch attached).
However, the compilation is successful only on SBCL-1.0.6.0, because on CLisp-2.41 (both on a Debian sid) I get:
--8<---------------cut here---------------start------------->8--- ;; Compiling file /home/luca/var/lib/debdarcs/parenscript-upstream/t/test- package.lisp ... ;; Wrote file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test- package.fas ;; Loading file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test- package.fas ... ;; Loaded file /var/cache/common-lisp-controller/1000/clisp/local/home/luca/var/lib/debdarcs/parenscript-upstream/t/test- package.fas ;; Compiling file /home/luca/var/lib/debdarcs/parenscript-upstream/t/test.lisp ... *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/home/luca/var/lib/debdarcs/parenscript-upstream/t/test.lisp" @212>: there is no character with name "FORM" The following restarts are available: RETRY :R1 Retry performing #<ASDF:COMPILE-OP NIL #x000333D42988> on #<ASDF:CL-SOURCE-FILE "test" #x000333CFAC80>. ACCEPT :R2 Continue, treating #<ASDF:COMPILE-OP NIL #x000333D42988> on #<ASDF:CL-SOURCE-FILE "test" #x000333CFAC80> as having been successful. ABORT :R3 ABORT Break 1 JS-TEST[3]> --8<---------------cut here---------------end--------------->8---
Commenting out line 212 in test.lisp solves the problem. Is my CLisp too old or is something other?
Thx, bye, Gismo / Luca
Footnotes: [1] http://common-lisp.net/pipermail/bese-devel/2007-July/003044.html
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On 7/2/07, Red Daly reddaly@gmail.com wrote:
There are, however, still many tests that fail. The bulk of these failures are because of semantically meaningless differences in parenscript-compiled javascript and the expected javascript. for example:
It is worth considering using a Javascript parser compare expected vs. compiled Javascript instead of using the slight hack in the current testing code.
I would say it is unnecessary and too complex. If the hack is updated to remove all whitespace (include linebreaks) before comparing generated and expected code, I think that will be good enough to detect 99.9% of all cases were the generated code does not comply with the documentation.
I think find undocumented newly added features and tweaks, and documenting them with expected output is a higher priority. Otherwise it is a big chance they will be forgotten when parenscript is refactored. If there is no test for a feature, it will not be seen.
Anyhow, now that 5am is compiling we might want to get tests working again.
Great work! And yes. And also clean up the documentation. I don't have the time right now, but can help later if there is anything left to do in some weeks.
/Henrik
parenscript-devel@common-lisp.net
-
Henrik Hjelte -
Luca Capello -
Red Daly -
Vladimir Sedach