Re: [Sbcl-help] Current CVS version build failure

Daniel Barlow <dan@...> writes:
> If you're using the CVS instead of the releases, sbcl-devel /might/ be
> a better bet than sbcl-help. But no big deal, chances are it'll get
> picked up anyway. What's probably more important, when reporting bugs
> in CVS versions, is to include the version number which you can find
> in version.lisp-expr - given the vagaries of sourceforge's anoncvs
> mirroring and mailing list delivery, "current cvs version" is not so
> precise.
What's the traffic like on sbcl-devel? I can go ahead and join that
list to post bug reports there if that is the better way to go. I
just don't want to deal with 40+ messages a day or something to do so
;-)
> I believe that the bug you describe was fixed in 0.8.9.42; unless the
> version you're trying to build is that one or newer, please grab it
> and try again. If it's not got as far as the anoncvs mirror, the
> relevant patch is
I did another 'cvs up -dP' and this time SBCL compiled straight
through. Before I go ahead and run the install script though, I do
have a question. I went ahead and ran the additional tests and got
this failure (version.lisp-expr is "0.8.9.46"):
//running threads.impure.lisp test
unhandled condition (of type SIMPLE-FILE-ERROR):
error opening #P"/home/david/usr/src/sbcl/tests/threads-foreign.c":
File exists
0:
("hairy arg processor for top level local call SB!DEBUG:BACKTRACE"
128
#<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {5072119}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
2
#<SIMPLE-FILE-ERROR {906A8C9}>
#<unavailable argument>)[:EXTERNAL]
2: (INVOKE-DEBUGGER 1 #<SIMPLE-FILE-ERROR {906A8C9}>)[:EXTERNAL]
3: (ERROR 7 SIMPLE-FILE-ERROR)[:EXTERNAL]
4: (SB-IMPL::SIMPLE-FILE-PERROR
3
"error opening ~S"
#P"/home/david/usr/src/sbcl/tests/threads-foreign.c"
17)[:EXTERNAL]
5: (OPEN 3 "threads-foreign.c")[:EXTERNAL]
6: (#:EVAL-TMPFUN-2593 0)[:EXTERNAL]
7: (EVAL-IN-LEXENV
2
(WITH-OPEN-FILE (O "threads-foreign.c" :DIRECTION :OUTPUT)
(FORMAT O "void loop_forever() { while(1) ; }~%"))
#S(SB-KERNEL:LEXENV
:FUNS NIL
:VARS NIL
:BLOCKS NIL
:TAGS NIL
:TYPE-RESTRICTIONS NIL
:LAMBDA NIL
:CLEANUP NIL
:POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1)
(SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1)
(COMPILATION-SPEED . 1))))[:EXTERNAL]
8: (SB-FASL::LOAD-AS-SOURCE
3
#<FILE-STREAM
for "file \"/home/david/usr/src/sbcl/tests/threads.impure.lisp\""
{902C6C9}>
NIL
NIL)[:EXTERNAL]
9: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
#P"threads.impure.lisp"
#P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
:ERROR
NIL
NIL
:SOURCE)
10: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
#P"threads.impure.lisp"
#P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
:ERROR
NIL
NIL
NIL)
11: (LOAD 1 "threads.impure.lisp")[:EXTERNAL]
12: (EVAL-IN-LEXENV
2
(LOAD "threads.impure.lisp")
#S(SB-KERNEL:LEXENV
:FUNS NIL
:VARS NIL
:BLOCKS NIL
:TAGS NIL
:TYPE-RESTRICTIONS NIL
:LAMBDA NIL
:CLEANUP NIL
:POLICY ((SAFETY . 3) (COMPILATION-SPEED . 2) (DEBUG . 2) (SPEED . 1)
(SPACE . 1) (SB-EXT:INHIBIT-WARNINGS . 1))))[:EXTERNAL]
13: (SB-EXT:INTERACTIVE-EVAL 1 (LOAD "threads.impure.lisp"))[:EXTERNAL]
14: (SB-IMPL::REPL-FUN 1 T)[:EXTERNAL]
15: ("#'(LAMBDA NIL (LOOP # #))")
16: ("XEP for #'(LAMBDA NIL (LOOP # #))" 0)[:EXTERNAL]
17: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX 1 #<FUNCTION "CLOSURE" {9027A8D}>)[:EXTERNAL]
18: (SB-IMPL::TOPLEVEL-REPL 1 T)[:EXTERNAL]
19: (SB-IMPL::TOPLEVEL-INIT 0)[:EXTERNAL]
20: ("FLET SB!IMPL::RESTART-LISP")
unhandled condition in --disable-debugger mode, quitting
test threads.impure.lisp failed, expected 104 return code, got 1
david@...:~/usr/src/sbcl/tests
$
Should I consider this a show stopper or not? I'm not exactly sure
why a file existing should cause a problem with opening it.
I don't know about the orthodoxy of this, but what I am trying to do
is basicly keep up with the latest SBCL with threads on Linux while
also trying to use it to develop a web application server. I'm doing
several things at once here. I will also be using your detachtty
program so that I can work on a running image with SLIME and stop and
rebuild things independent of SLIME. The idea is to have a boot
script that fires up my Lisp image (and can be used for stoping and
starting it much like apachectl). Call this a long winded way of
saying that I will try to contribute starting in the QA department ;-)
Anyway, if there is no danger of not being able to compile additional
CVS releases of SBCL, I'll go ahead and run the install script.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

Daniel Barlow <dan@...> writes:
> If you're using the CVS instead of the releases, sbcl-devel /might/ be
> a better bet than sbcl-help. But no big deal, chances are it'll get
> picked up anyway. What's probably more important, when reporting bugs
> in CVS versions, is to include the version number which you can find
> in version.lisp-expr - given the vagaries of sourceforge's anoncvs
> mirroring and mailing list delivery, "current cvs version" is not so
> precise.
What's the traffic like on sbcl-devel? I can go ahead and join that
list to post bug reports there if that is the better way to go. I
just don't want to deal with 40+ messages a day or something to do so
;-)
> I believe that the bug you describe was fixed in 0.8.9.42; unless the
> version you're trying to build is that one or newer, please grab it
> and try again. If it's not got as far as the anoncvs mirror, the
> relevant patch is
I did another 'cvs up -dP' and this time SBCL compiled straight
through. Before I go ahead and run the install script though, I do
have a question. I went ahead and ran the additional tests and got
this failure (version.lisp-expr is "0.8.9.46"):
//running threads.impure.lisp test
unhandled condition (of type SIMPLE-FILE-ERROR):
error opening #P"/home/david/usr/src/sbcl/tests/threads-foreign.c":
File exists
0:
("hairy arg processor for top level local call SB!DEBUG:BACKTRACE"
128
#<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {5072119}>)
1: (SB-DEBUG::DEBUGGER-DISABLED-HOOK
2
#<SIMPLE-FILE-ERROR {906A8C9}>
#<unavailable argument>)[:EXTERNAL]
2: (INVOKE-DEBUGGER 1 #<SIMPLE-FILE-ERROR {906A8C9}>)[:EXTERNAL]
3: (ERROR 7 SIMPLE-FILE-ERROR)[:EXTERNAL]
4: (SB-IMPL::SIMPLE-FILE-PERROR
3
"error opening ~S"
#P"/home/david/usr/src/sbcl/tests/threads-foreign.c"
17)[:EXTERNAL]
5: (OPEN 3 "threads-foreign.c")[:EXTERNAL]
6: (#:EVAL-TMPFUN-2593 0)[:EXTERNAL]
7: (EVAL-IN-LEXENV
2
(WITH-OPEN-FILE (O "threads-foreign.c" :DIRECTION :OUTPUT)
(FORMAT O "void loop_forever() { while(1) ; }~%"))
#S(SB-KERNEL:LEXENV
:FUNS NIL
:VARS NIL
:BLOCKS NIL
:TAGS NIL
:TYPE-RESTRICTIONS NIL
:LAMBDA NIL
:CLEANUP NIL
:POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1)
(SB-EXT:INHIBIT-WARNINGS . 1) (DEBUG . 1)
(COMPILATION-SPEED . 1))))[:EXTERNAL]
8: (SB-FASL::LOAD-AS-SOURCE
3
#<FILE-STREAM
for "file \"/home/david/usr/src/sbcl/tests/threads.impure.lisp\""
{902C6C9}>
NIL
NIL)[:EXTERNAL]
9: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
#P"threads.impure.lisp"
#P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
:ERROR
NIL
NIL
:SOURCE)
10: ("hairy arg processor for top level local call SB!FASL::INTERNAL-LOAD"
#P"threads.impure.lisp"
#P"/home/david/usr/src/sbcl/tests/threads.impure.lisp"
:ERROR
NIL
NIL
NIL)
11: (LOAD 1 "threads.impure.lisp")[:EXTERNAL]
12: (EVAL-IN-LEXENV
2
(LOAD "threads.impure.lisp")
#S(SB-KERNEL:LEXENV
:FUNS NIL
:VARS NIL
:BLOCKS NIL
:TAGS NIL
:TYPE-RESTRICTIONS NIL
:LAMBDA NIL
:CLEANUP NIL
:POLICY ((SAFETY . 3) (COMPILATION-SPEED . 2) (DEBUG . 2) (SPEED . 1)
(SPACE . 1) (SB-EXT:INHIBIT-WARNINGS . 1))))[:EXTERNAL]
13: (SB-EXT:INTERACTIVE-EVAL 1 (LOAD "threads.impure.lisp"))[:EXTERNAL]
14: (SB-IMPL::REPL-FUN 1 T)[:EXTERNAL]
15: ("#'(LAMBDA NIL (LOOP # #))")
16: ("XEP for #'(LAMBDA NIL (LOOP # #))" 0)[:EXTERNAL]
17: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX 1 #<FUNCTION "CLOSURE" {9027A8D}>)[:EXTERNAL]
18: (SB-IMPL::TOPLEVEL-REPL 1 T)[:EXTERNAL]
19: (SB-IMPL::TOPLEVEL-INIT 0)[:EXTERNAL]
20: ("FLET SB!IMPL::RESTART-LISP")
unhandled condition in --disable-debugger mode, quitting
test threads.impure.lisp failed, expected 104 return code, got 1
david@...:~/usr/src/sbcl/tests
$
Should I consider this a show stopper or not? I'm not exactly sure
why a file existing should cause a problem with opening it.
I don't know about the orthodoxy of this, but what I am trying to do
is basicly keep up with the latest SBCL with threads on Linux while
also trying to use it to develop a web application server. I'm doing
several things at once here. I will also be using your detachtty
program so that I can work on a running image with SLIME and stop and
rebuild things independent of SLIME. The idea is to have a boot
script that fires up my Lisp image (and can be used for stoping and
starting it much like apachectl). Call this a long winded way of
saying that I will try to contribute starting in the QA department ;-)
Anyway, if there is no danger of not being able to compile additional
CVS releases of SBCL, I'll go ahead and run the install script.
--
I wouldn't mind the rat race so much if it wasn't for all the damn cats.

On Thu, Apr 15, 2004 at 07:23:21PM -0400, David Steuber wrote:
> What's the traffic like on sbcl-devel? I can go ahead and join that
> list to post bug reports there if that is the better way to go. I
> just don't want to deal with 40+ messages a day or something to do so
You can see for yourself: http://news.gmane.org/gmane.lisp.steel%2dbank.devel
> //running threads.impure.lisp test
> unhandled condition (of type SIMPLE-FILE-ERROR):
> error opening #P"/home/david/usr/src/sbcl/tests/threads-foreign.c":
> File exists
Harmless, though odd. I thought this had been fixed.
It will have stopped any foillowing tests fron running, though. I
would remove tests/threads.impure.lisp (or move it outside of the
test/ directory if you'd rather, but you can always get it back from
CVS) and run the tests again
> Anyway, if there is no danger of not being able to compile additional
> CVS releases of SBCL, I'll go ahead and run the install script.
Threads are not needed for building SBCL, at least, so you should be
in no danger there.
-dan

Nikodemus Siivola <tsiivola@...> writes:
> On Fri, 16 Apr 2004 dan@... wrote:
>
>> > //running threads.impure.lisp test
>> > unhandled condition (of type SIMPLE-FILE-ERROR):
>> > error opening #P"/home/david/usr/src/sbcl/tests/threads-foreign.c":
>> > File exists
>>
>> Harmless, though odd. I thought this had been fixed.
>
> In current anoncvs HEAD it isn't (0.8.9.47), which is wierd, since I could
> have sworn I'd seen a commit message on sbcl-commits. Is SF playing silly
> buggers?
I'm not sure, but I think this might be my fault. I think I committed
a bunch of things about a month ago, including a fix for this, but I'd
forgotten that I'd deleted my fix for this in a different attempt to
make the threading tests pass... :-/
Someone with more threads-fu (like, regularly building with them on
:-) than I have might wish to stomp this one properly.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)