[Slime-devel] Showing two test failures...
Hello list, I have a simple bash script that I use to upgrade and test slime that contains the following: ---------------------------------------------------------------------- #! /bin/bash # script name slime-github-setup cd ~/my-slime-sandbox [ -d ./slime ] && rm -rf ./slime #exit #debug exit git clone https://github.com/slime/slime.git cd ~/my-slime-sandbox/slime cd doc make slime.html cd .. #Proper order for these as of 5-22-14 per joao tavora make clean check-fancy make check ---------------------------------------------------------------------- The last time I used it, it ran fine and the test suite completed successfully. Today, however, I find the following two errors: Ran 198 tests, 196 results as expected, 2 unexpected (2014-08-24 18:05:09-0700) 1 expected failures 2 unexpected results: FAILED compile-defun-4 FAILED find-definition\.2-1 make: *** [check] Error 2 Specific error messages: Test compile-defun-4 backtrace: signal(ert-test-failed ("Check failed: error-location-correct")) ert-fail("Check failed: error-location-correct") slime-test-compile-defun("(defun cl-user::foo ()\n (list ` #[nil "\300\301\302\"\207" [slime-test-compile-defun "(defun cl-user byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc byte-code("\306\307!\211▒\211r\310\311!q\210\312 d\313\223)L\210)\3 ert-run-test([cl-struct-ert-test compile-defun-4 "For input ((defun ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a ert-run-tests(t #[(event-type &rest event-args) "\30\307\"\203G \ ert-run-tests-batch(t) slime-batch-test(t) eval((slime-batch-test (quote t))) command-line-1(("-L" "." "--eval" "(require 'slime-tests)" "--eval" command-line() normal-top-level() Test compile-defun-4 condition: (ert-test-failed "Check failed: error-location-correct") FAILED 20/198 compile-defun-4 Test find-definition\.2-1 backtrace: signal(ert-test-failed ("Check failed: Definition now at point.")) ert-fail("Check failed: Definition now at point.") slime-test-find-definition\.2("#.(prog1 nil (defvar *foobar* 42))\n\ #[nil "\300\301\302\303#\207" [slime-test-find-definition\.2 "#.(pro byte-code("\306\307!▒q\210\310\216\311 \312\216\313\314\315\316\3 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc byte-code("\306\307!\211▒\211r\310\311!q\210\312 d\313\223)L\210)\3 ert-run-test([cl-struct-ert-test find-definition\.2-1 "For input (#. ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a ert-run-tests(t #[(event-type &rest event-args) "\30\307\"\203G \ ert-run-tests-batch(t) slime-batch-test(t) eval((slime-batch-test (quote t))) command-line-1(("-L" "." "--eval" "(require 'slime-tests)" "--eval" command-line() normal-top-level() Test find-definition\.2-1 condition: (ert-test-failed "Check failed: Definition now at point.") FAILED 51/198 find-definition\.2-1 failed 52/198 find-definition\.3-1 SKIPPING: test is currently unstable I just upgraded to SBCL-1.2.2 and decide to upgrade slime also. I'm using GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.6). Is there now some reason why my simple script should cause the problem, or are these errors valid? Thanks, Paul Bowyer
On Sun, Aug 24 2014, Paul Bowyer wrote:
2 unexpected results: FAILED compile-defun-4 FAILED find-definition\.2-1 [...] Is there now some reason why my simple script should cause the problem, or are these errors valid?
The source of the errors seem to be the recent changes to SBCL's reader; not your script. compile-defun-4 fails due to the "improved" backquote stuff. I haven't followed the discussion. Why is it neccesary to that ,X returns a struct instead of somehing more traditionanal like (unquote X)? find-definition\.2-1 fails because a change to set-macro-character. This code used to work: (let* ((rt (copy-readtable nil))) (flet ((wrap (fun) (lambda (&rest args) (apply args fun)))) (list (assert (get-dispatch-macro-character #\# #\. rt)) (multiple-value-bind (fun nt) (get-macro-character #\# rt) (set-macro-character #\# (wrap fun) nt rt)) (assert (get-dispatch-macro-character #\# #\. rt))))) but no longer does. Does somebody know if this code is actually non-portable? Helmut
2014-08-25 8:38 GMT+01:00 Helmut Eller:
compile-defun-4 fails due to the "improved" backquote stuff. I haven't followed the discussion. Why is it neccesary to that ,X returns a struct instead of somehing more traditionanal like (unquote X)?
As I see it, that's a correct reader error, you shouldn't be able to `(list 1 ,1 ,@1 (bar)) That ,@1 cause the equivalent append to fail: (append (list `1) (list 1) 1 (list `(bar))) Although I'm not sure I'm looking at the right point of failure, and I didn't actually test it.
find-definition\.2-1 fails because a change to set-macro-character. This code used to work:
(let* ((rt (copy-readtable nil))) (flet ((wrap (fun) (lambda (&rest args) (apply args fun)))) (list (assert (get-dispatch-macro-character #\# #\. rt)) (multiple-value-bind (fun nt) (get-macro-character #\# rt) (set-macro-character #\# (wrap fun) nt rt)) (assert (get-dispatch-macro-character #\# #\. rt)))))
but no longer does. Does somebody know if this code is actually non-portable?
It is actually non-portable, the macro character function is provided by the implementation through make-dispatch-macro-character: http://www.lispworks.com/documentation/HyperSpec/Body/02_add.htm The dispatch character table may be attached to the macro character function, e.g. a funcallable-standard-object with a slot containing the table. Hence the need for make-dispatch-macro-character. In the case of SBCL, it's a bit more twisted, it actually checks for the closure's value: https://github.com/sbcl/sbcl/blob/82e75708c947be3ae4e7884241526ba9c81840f6/s... Best regards, Paulo Madeira
On Mon, Aug 25 2014, Paulo Madeira wrote:
2014-08-25 8:38 GMT+01:00 Helmut Eller:
compile-defun-4 fails due to the "improved" backquote stuff. I haven't followed the discussion. Why is it neccesary to that ,X returns a struct instead of somehing more traditionanal like (unquote X)?
As I see it, that's a correct reader error, you shouldn't be able to
`(list 1 ,1 ,@1 (bar))
That ,@1 cause the equivalent append to fail:
(append (list `1) (list 1) 1 (list `(bar)))
Although I'm not sure I'm looking at the right point of failure, and I didn't actually test it.
The example was: (defun foo () (list `(1 ,(random 10) 2 ,@(random 3) 3 ,(bar)))) and BAR is an undefined function. There used to one warning but now there are two. If we change it to (defun foo () (list `(1 ,(random 10) 2 ,@(make-list 3) 3 ,(bar)))) we get back to a single warning and the real issue: previously the source path of the error was (0 3 1 4 2 2) i.e at (bar) but with the new backquote the source path is (0 3 1) which is at `(1 ...). Clearly a less precise location. The reason I'm asking why this struct was necessary is because sb-c::sub-find-source-paths doesn't descent into that sb-impl::comma struct and the compiler has only sees use the next best path. I guess sb-c::sub-find-source-paths should be updated or just use lists instead of structs.
find-definition\.2-1 fails because a change to set-macro-character. This code used to work:
(let* ((rt (copy-readtable nil))) (flet ((wrap (fun) (lambda (&rest args) (apply args fun)))) (list (assert (get-dispatch-macro-character #\# #\. rt)) (multiple-value-bind (fun nt) (get-macro-character #\# rt) (set-macro-character #\# (wrap fun) nt rt)) (assert (get-dispatch-macro-character #\# #\. rt)))))
but no longer does. Does somebody know if this code is actually non-portable?
It is actually non-portable, the macro character function is provided by the implementation through make-dispatch-macro-character:
http://www.lispworks.com/documentation/HyperSpec/Body/02_add.htm
The dispatch character table may be attached to the macro character function, e.g. a funcallable-standard-object with a slot containing the table. Hence the need for make-dispatch-macro-character. In the case of SBCL, it's a bit more twisted, it actually checks for the closure's value:
https://github.com/sbcl/sbcl/blob/82e75708c947be3ae4e7884241526ba9c81840f6/s...
Surely there are other ways to store dispatch character tables. E.g. the readtable could have a hashtable of dispatch character tables. I don't see any other portable way make this test pass than with get-macro-character/set-macro-character. So I probably mark this test as "fails for SBCL". Helmut
I guess sb-c::sub-find-source-paths should be updated or just use lists instead of structs.
i guess someone who already understands this issue well enough without extra efforts should report it as a bug for the SBCL maintainers: https://bugs.launchpad.net/sbcl -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “In every declining civilization there is a small "remnant" of people who adhere to the right against the wrong; who recognize the difference between good and evil and who will take an active stand for the former and against the latter; who can still think and discern and who will courageously take a stand against the political, social, moral, and spiritual rot or decay of their day.” — Donald S. McAlvaney
On Mon, Aug 25 2014, Attila Lendvai wrote:
I guess sb-c::sub-find-source-paths should be updated or just use lists instead of structs.
i guess someone who already understands this issue well enough without extra efforts should report it as a bug for the SBCL maintainers:
Done: https://bugs.launchpad.net/sbcl/+bug/1361502 Helmut
2014-08-25 20:05 GMT+01:00 Helmut Eller:
Surely there are other ways to store dispatch character tables.
Indeed.
I don't see any other portable way make this test pass than with get-macro-character/set-macro-character. So I probably mark this test as "fails for SBCL".
You'd need a dispatch-macro-character-p here: https://github.com/slime/slime/blob/fb65f98487bc20c3b27923a42fb746bd6de99272... However, I think you can take for granted that the default readtable only has #\# as a dispatch macro character, so you can wrap its simple macro character function *after* wrapping the reader macro function for #\# #\. Best regards, Paulo Madeira
On Mon, Aug 25 2014, Paulo Madeira wrote:
I don't see any other portable way make this test pass than with get-macro-character/set-macro-character. So I probably mark this test as "fails for SBCL". [...] However, I think you can take for granted that the default readtable only has #\# as a dispatch macro character, so you can wrap its simple macro character function *after* wrapping the reader macro function for #\# #\.
Good idea! With that the find-definion.2-1 test passes. Helmut
participants (4)
-
Attila Lendvai -
Helmut Eller -
Paul Bowyer -
Paulo Madeira