From: John L. <cod...@in...> - 2013-10-29 08:58:25
|
Hi. I decided to try building 1.1.12 source from 1.0.58 on Linux first since it's a lot cooler and quieter than doing SPARC. The build itself seems to work fine. However the tests didn't complete. I'm totally lost, any info would be helpful. Thanks, /jl ./subr.sh: line 137: 8104 Killed "$SBCL_RUNTIME" --core "$SBCL_CORE" $SBCL_ARGS --load "$SBCL_PWD/condition-wait-sigcont.lisp" (wd: /tmp/sbcl-1.1.12/tests/threads-test-8088) // Running /tmp/sbcl-1.1.12/tests/toplevel.test.sh // Running /tmp/sbcl-1.1.12/tests/undefined-classoid-bug.test.sh ; file: /tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-1.lisp ; in: DEFUN A-STRUCT-REFERENCER-1 ; (A-STRUCT-SLOT STRUCT) ; ; caught STYLE-WARNING: ; undefined function: A-STRUCT-SLOT ; ; compilation unit finished ; Undefined function: ; A-STRUCT-SLOT ; caught 1 STYLE-WARNING condition ; file: /tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-2.lisp ; in: DEFUN A-STRUCT-REFERENCER-2 ; (A-STRUCT-SLOT STRUCT) ; ; caught STYLE-WARNING: ; undefined function: A-STRUCT-SLOT ; ; compilation unit finished ; Undefined function: ; A-STRUCT-SLOT ; caught 1 STYLE-WARNING condition ; compiling file "/tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-1.lisp" (written 29 OCT 2013 08:44:48 AM): ; compiling (IN-PACKAGE "CL-USER") ; compiling (DEFUN A-STRUCT-REFERENCER-1 ...) ; /tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-1.fasl written ; compilation finished in 0:00:00.004 ; compiling file "/tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-2.lisp" (written 29 OCT 2013 08:44:48 AM): ; compiling (IN-PACKAGE "CL-USER") ; compiling (DEFUN A-STRUCT-REFERENCER-2 ...) ; compiling (DEFSTRUCT A-STRUCT ...) ; /tmp/sbcl-1.1.12/tests/undefined-classoid-bug-test-8138/undefined-classoid-bug-2.fasl written ; compilation finished in 0:00:00.008 test undefined-classoid-bug ok Finished running tests. Status: Expected failure: debug.impure.lisp / BACKTRACE-INTERRUPTED-CONDITION-WAIT Expected failure: dynamic-extent.impure.lisp / (NO-CONSING SPECIALIZED-DX-VECTORS) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Unhandled Error run-program.impure.lisp Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS) Expected failure: walk.impure.lisp / (WALK-LET* HAIRY-SPECIALS) (5 tests skipped for this combination of platform and features) test failed, expected 104 return code, got 1 |
From: Paul K. <pv...@pv...> - 2013-10-29 12:17:32
|
Hi, John Long wrote: > The build itself seems to work fine. However the tests didn't complete. > I'm totally lost, any info would be helpful. [...] > Unhandled Error run-program.impure.lisp Do you have fancy non-ASCII characters in your environment? Integration between my shell and git does that for me, for example; my workaround (because something like utf-8b would be a better idea) is to start a dumber shell in a non-version-controlled location and then cd into the test directory. Paul Khuong |
From: John L. <cod...@in...> - 2013-10-29 12:25:06
|
On Tue, Oct 29, 2013 at 08:17:26AM -0400, Paul Khuong wrote: > Hi, > John Long wrote: > > The build itself seems to work fine. However the tests didn't complete. > > I'm totally lost, any info would be helpful. > [...] > > Unhandled Error run-program.impure.lisp > > Do you have fancy non-ASCII characters in your environment? Hi Paul, I don't know...I believe my locale is set to POSIX or C (certainly not UTF8) but I usually build everything in Emacs. Could that cause a problem? Thanks, /jl |
From: John L. <cod...@in...> - 2013-10-29 12:49:39
|
I ran the tests again in an xterm and got the same error. |
From: Stas B. <sta...@gm...> - 2013-10-30 08:56:59
|
John Long <cod...@in...> writes: > I ran the tests again in an xterm and got the same error. First, run-program no longer re-encodes the environment, so there can't be any problems with non-ascii characters there. Second, xterm won't in any way affect the environment even if it could be problematic. The log you sent is basically useless, it just says that something wrong happened. You have to attach the whole log. But I can predict that the problem is caused by not having /bin/ed. -- With best regards, Stas. |
From: John L. <cod...@in...> - 2013-10-30 10:31:35
|
On Wed, Oct 30, 2013 at 12:56:51PM +0400, Stas Boukarev wrote: > But I can predict that the problem is caused by not having /bin/ed. Thank you, this works. Tests ran to completion with no unexpected failures after installing gnu ed. Installed and running 1.1.2 on Linux x86. Thanks a lot. /jl |
From: John L. <cod...@in...> - 2013-10-30 10:12:37
|
On Wed, Oct 30, 2013 at 12:56:51PM +0400, Stas Boukarev wrote: > John Long <cod...@in...> writes: > > > I ran the tests again in an xterm and got the same error. > First, run-program no longer re-encodes the environment, so there can't > be any problems with non-ascii characters there. > Second, xterm won't in any way affect the environment even if it could > be problematic. I have no way to know this since I was asked about fancy characters. Since nobody said anything further and didn't give any suggestions, I tried to use a plain terminal. > The log you sent is basically useless, it just says that something wrong > happened. You have to attach the whole log. Nobody said this either at the time. Can I attach or post 60,000 lines on this mailing list? > But I can predict that the problem is caused by not having /bin/ed. Ok, I don't have /bin/ed What's supposed to be there? /jl |
From: Stas B. <sta...@gm...> - 2013-10-30 11:14:13
|
John Long <cod...@in...> writes: > On Wed, Oct 30, 2013 at 12:56:51PM +0400, Stas Boukarev wrote: >> John Long <cod...@in...> writes: >> >> > I ran the tests again in an xterm and got the same error. >> First, run-program no longer re-encodes the environment, so there can't >> be any problems with non-ascii characters there. >> Second, xterm won't in any way affect the environment even if it could >> be problematic. > > I have no way to know this since I was asked about fancy characters. Since > nobody said anything further and didn't give any suggestions, I tried to use > a plain terminal. > >> The log you sent is basically useless, it just says that something wrong >> happened. You have to attach the whole log. > > Nobody said this either at the time. Can I attach or post 60,000 lines on > this mailing list? You can run individual tests only, ./run-tests.sh run-program.impure.lisp. You can also cut things out of the larger output. You can ./run-tests.sh --break-on-failure run-program.impure.lisp and paste only the error and the backtrace. Failing either, you can gzip the log and attach it. -- With best regards, Stas. |
From: Christophe R. <cs...@ca...> - 2013-10-30 11:03:32
|
Stas Boukarev <sta...@gm...> writes: > But I can predict that the problem is caused by not having /bin/ed. Can we defend against this problem in some straightforward way? Which of the two run-program tests is actually causing the hang when /bin/ed is not present? Cheers, Christophe |
From: Stas B. <sta...@gm...> - 2013-10-30 11:17:19
|
Christophe Rhodes <cs...@ca...> writes: > Stas Boukarev <sta...@gm...> writes: > >> But I can predict that the problem is caused by not having /bin/ed. > > Can we defend against this problem in some straightforward way? Which > of the two run-program tests is actually causing the hang when /bin/ed > is not present? I don't think it hangs, just fails. But not in the best fashion. * The test can be skipped if /bin/ed is not present. But that will forgo some testing. * We can write our own ed dummy in C and use it. * The test doesn't even have WITH-TEST, hence the not-so-helpful "unhandled error", that can be easily rectified. -- With best regards, Stas. |
From: Paul K. <pv...@pv...> - 2013-10-30 11:29:26
|
Stas Boukarev wrote: > First, run-program no longer re-encodes the environment, so there can't > be any problems with non-ascii characters there. Sure, but one of the tests in run-program.test.sh explicitly converts the environment to strings, twice (once through env and then with sb-ext:posix-environ). For me, that test fails with a SB-IMPL::MALFORMED-ASCII when decoding the output of env, despite the fact that pkhuong@2delilah ~/sbcl ♪ [ sh run-sbcl.sh --noinform --eval '(print sb-impl::*default-external-format*)' --quit (running SBCL from: .) :UTF-8 Paul Khuong |
From: John L. <cod...@in...> - 2013-10-30 11:35:36
|
On Wed, Oct 30, 2013 at 03:17:10PM +0400, Stas Boukarev wrote: > Christophe Rhodes <cs...@ca...> writes: > > > Stas Boukarev <sta...@gm...> writes: > > > >> But I can predict that the problem is caused by not having /bin/ed. > > > > Can we defend against this problem in some straightforward way? Which > > of the two run-program tests is actually causing the hang when /bin/ed > > is not present? > I don't think it hangs, just fails. But not in the best fashion. > * The test can be skipped if /bin/ed is not present. But that will forgo > some testing. > * We can write our own ed dummy in C and use it. > * The test doesn't even have WITH-TEST, hence the not-so-helpful > "unhandled error", that can be easily rectified. Two obvious things would be to put the requirement for gnu ed in the test section of the INSTALL file so we'll be aware of it and then you can at least RTFM those of us who trip over it, and issue a message in the test suite when you get to that point and /bin/ed is not there or does not point to gnu ed or whatever you need there. /jl |
From: Paul K. <pv...@pv...> - 2013-10-30 11:42:38
|
John Long wrote: > On Wed, Oct 30, 2013 at 03:17:10PM +0400, Stas Boukarev wrote: >> Christophe Rhodes<cs...@ca...> writes: >> I don't think it hangs, just fails. But not in the best fashion. >> * The test can be skipped if /bin/ed is not present. But that will forgo >> some testing. >> * We can write our own ed dummy in C and use it. >> * The test doesn't even have WITH-TEST, hence the not-so-helpful >> "unhandled error", that can be easily rectified. > > Two obvious things would be to put the requirement for gnu ed in the test > section of the INSTALL file so we'll be aware of it and then you can at > least RTFM those of us who trip over it, and issue a message in the test > suite when you get to that point and /bin/ed is not there or does not point > to gnu ed or whatever you need there. IIRC, ed was only chosen because POSIX-compliant platforms must have it around; it's only necessary for regression testing. Christophe's suggestions seem best than attempting to document the foibles of our test suite in INSTALL. Paul Khuong |
From: Stas B. <sta...@gm...> - 2013-10-30 11:36:03
|
Paul Khuong <pv...@pv...> writes: > Stas Boukarev wrote: >> First, run-program no longer re-encodes the environment, so there can't >> be any problems with non-ascii characters there. > > Sure, but one of the tests in run-program.test.sh explicitly converts > the environment to strings, twice (once through env and then with > sb-ext:posix-environ). For me, that test fails with a > SB-IMPL::MALFORMED-ASCII when decoding the output of env, despite the > fact that > > pkhuong@2delilah ~/sbcl ♪ [ sh run-sbcl.sh --noinform --eval > (print sb-impl::*default-external-format*)' --quit > (running SBCL from: .) > > :UTF-8 And the failed test was in run-program.impure, which does not touch the environment. -- With best regards, Stas. |
From: Paul K. <pv...@pv...> - 2013-10-30 11:42:43
|
Stas Boukarev wrote: > Paul Khuong<pv...@pv...> writes: > >> Stas Boukarev wrote: >>> First, run-program no longer re-encodes the environment, so there can't >>> be any problems with non-ascii characters there. >> Sure, but one of the tests in run-program.test.sh explicitly converts >> the environment to strings, twice (once through env and then with >> sb-ext:posix-environ). For me, that test fails with a >> SB-IMPL::MALFORMED-ASCII when decoding the output of env, despite the >> fact that >> >> pkhuong@2delilah ~/sbcl ♪ [ sh run-sbcl.sh --noinform --eval >> (print sb-impl::*default-external-format*)' --quit >> (running SBCL from: .) >> >> :UTF-8 > > And the failed test was in run-program.impure, which does not touch the > environment. Quite right. Paul Khuong |