Menu
▾
▴
clisp-devel
|
From: <don...@is...> - 2009-10-29 18:39:14
|
... ;; Loaded file /root/clisp/build-dir/trace.fas ;; Loading file /root/clisp/build-dir/cmacros.fas ... ;; Loaded file /root/clisp/build-dir/cmacros.fas ;; Loading file /root/clisp/build-dir/compiler.fas ... *** - SYSTEM::%FIND-PACKAGE: There is no package with name "COMPILER" Bye. make: *** [interpreted.mem] Error 1 make clean solves the problem But this is not a minor inconvenience when you're doing 5 nightly builds. I think I've tried to raise this problem before. Are there cases where you (developers) care about causing incremental make's to break? Or should I just start my nightly builds with make clean? |
|
From: <don...@is...> - 2010-08-10 11:30:54
|
... ;; Loaded file /home/clisp-build/clisp/src/clos-class4.lisp ;; Loading file /home/clisp-build/clisp/src/clos-class5.lisp ... WARNING: DEFGENERIC: redefining function SHARED-INITIALIZE in /home/clisp-build/clisp/src/clos-class5.lisp, was defined in top-level *** - EVAL: undefined function WARN-IF-GF-ALREADY-CALLED Bye. make: *** [interpreted.mem] Error 1 |
|
From: <don...@is...> - 2011-07-30 22:32:13
|
ends like this: ==== rm -f COPYRIGHT ln -s ../COPYRIGHT COPYRIGHT rm -f GNU-GPL ln -s ../GNU-GPL GNU-GPL rm -f SUMMARY ln -s ../SUMMARY SUMMARY ln -s ../src/NEWS NEWS ./txt2c -I../src// < ../src/_README > txt.c Could not open include file ../src//src/_README.en make: *** [README] Error 1 |
|
From: Sam S. <sd...@gn...> - 2011-08-01 15:12:58
|
> * Don Cohen <qba...@vf...> [2011-07-30 15:32:15 -0700]: > > ends like this: > ==== > rm -f COPYRIGHT > ln -s ../COPYRIGHT COPYRIGHT > rm -f GNU-GPL > ln -s ../GNU-GPL GNU-GPL > rm -f SUMMARY > ln -s ../SUMMARY SUMMARY > ln -s ../src/NEWS NEWS > ./txt2c -I../src// < ../src/_README > txt.c > Could not open include file ../src//src/_README.en > make: *** [README] Error 1 fixed, thanks! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.memritv.org http://ffii.org http://www.PetitionOnline.com/tap12009/ http://honestreporting.com http://memri.org http://thereligionofpeace.com To understand recursion, one has to understand recursion first. |
|
From: <don...@is...> - 2017-11-02 18:49:09
|
after: pulling from http://hg.code.sf.net/p/clisp/clisp searching for changes adding changesets adding manifests adding file changes added 4 changesets with 9 changes to 4 files make ends like this: make[1]: Leaving directory '/home/don/hg/clisp/build-dir/po' rm -rf data mkdir data cd data && ln -s ../../utils/unicode/UnicodeDataFull.txt . cd data && ln -s ../../doc/Symbol-Table.text . gcc -m64 -g -O2 -no-integrated-cpp -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -Wno-shift-negative-value -fwrapv -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -Wl,--export-dynamic spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o modules.o libgnu.a -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -lsigsegv -o lisp.run ./lisp.run -marc > marc.out ./lisp.run -B . -N locale -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc -m 2MW -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)' STACK size: 262078 [0x300001ffe00 0x30000000010] READ-FROM-STRING |
|
From: Bruno H. <br...@cl...> - 2017-11-02 23:07:09
|
Hi Don, > after: > pulling from http://hg.code.sf.net/p/clisp/clisp > searching for changes > adding changesets > adding manifests > adding file changes > added 4 changesets with 9 changes to 4 files > > make ends like this: > make[1]: Leaving directory '/home/don/hg/clisp/build-dir/po' > rm -rf data > mkdir data > cd data && ln -s ../../utils/unicode/UnicodeDataFull.txt . > cd data && ln -s ../../doc/Symbol-Table.text . > gcc -m64 -g -O2 -no-integrated-cpp -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -Wno-shift-negative-value -fwrapv -fno-strict-aliasing -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -Wl,--export-dynamic spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o modules.o libgnu.a -lreadline -lncurses -ldl /usr/local/lib/libavcall.a /usr/local/lib/libcallback.a -lsigsegv -o lisp.run > ./lisp.run -marc > marc.out > ./lisp.run -B . -N locale -E UTF-8 -Emisc 1:1 -Epathname 1:1 -norc -m 2MW -lp ../src/ -x '(and (load "../src/init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)' > STACK size: 262078 [0x300001ffe00 0x30000000010] > ... > make: *** [interpreted.mem] Segmentation fault (core dumped) Thanks for the report! It was a major blunder of mine. Fix pushed. And thanks for the rapid feedback. Part of the tests that I've been running since yesterday have been pointless, due to this bug; therefore I am very grateful that your rapid report saved me a number of other useless tests. Bruno |
|
From: Sam S. <sd...@gn...> - 2009-10-29 18:47:49
|
Don Cohen wrote: > Are there cases where you (developers) care about causing incremental > make's to break? not really. > Or should I just start my nightly builds with make clean? when I was running nightly builds on the SF CF, my script started with configure. |
|
From: <don...@is...> - 2009-10-30 15:02:57
|
Sam Steingold writes: > Don Cohen wrote: > > Are there cases where you (developers) care about causing incremental > > make's to break? > not really. > > Or should I just start my nightly builds with make clean? > when I was running nightly builds on the SF CF, my script started > with configure. Ok, I've changed my scripts to do that. Is there some reason you stopped doing nightly builds? How many, which systems, which builds? |
|
From: Sam S. <sd...@gn...> - 2009-10-30 15:23:44
Attachments:
rebuild.sh
|
Don Cohen wrote: > Is there some reason you stopped doing nightly builds? > How many, which systems, which builds? once upon a time, SF offered CF (compile farm). it was a collection of ~10 platforms sharing a file system. the platforms were mostly i386 and amd64 with linux and *bsd. there might have been a sparc and an alpha too. I set up a nightly cron job on the file server which did "cvs up" and a build job on each platform. the script is attached. I did not reconfigure nightly. on failure the stdout of the script was non-empty, so I got an email from cron, logged into the CF and rebuilt the dir from scratch when necessary. |
|
From: <don...@is...> - 2009-10-30 15:54:48
|
Sam Steingold writes: > Don Cohen wrote: > > Is there some reason you stopped doing nightly builds? > > How many, which systems, which builds? > > once upon a time, SF offered CF (compile farm). So I gather the reason you stopped was that the facility disappeared, and that you view the nightly builds as a good thing. For now I'm your nightly build farm. (Or at least one of 'em.) > I did not reconfigure nightly. I am doing so now. That's considerably less time than the build. It also is clearly useful for finding certain problems, On the other hand, I'm not rebuilding libsigsegv, libffcall, etc. I currently get two daily emails, one from each machine. I have to look at the output to decide whether things are working. Currently I look at the tail of the output of each major command. If it doesn't look like what I expect then I get to investigate further and report the problem. |
|
From: Sam S. <sd...@gn...> - 2009-10-30 16:36:28
|
Don Cohen wrote: > So I gather the reason you stopped was that the facility disappeared, > and that you view the nightly builds as a good thing. yes. > For now I'm your nightly build farm. (Or at least one of 'em.) oh, NBF with brains! sweet!!! > > I did not reconfigure nightly. > I am doing so now. That's considerably less time than the build. > It also is clearly useful for finding certain problems, indeed. I was not reconfiguring nightly because the admins there asked to try to reduce the load. > On the other hand, I'm not rebuilding libsigsegv, libffcall, etc. I was not either - I only checked for their presence, and, if not found, built them. > I currently get two daily emails, one from each machine. > I have to look at the output to decide whether things are working. > Currently I look at the tail of the output of each major command. > If it doesn't look like what I expect then I get to investigate > further and report the problem. the exit code from "make check" is a good indicator of success. |
|
From: <don...@is...> - 2009-10-30 17:19:50
|
Sam Steingold writes:
> the exit code from "make check" is a good indicator of success.
I've never done that in the script.
I do check the ability to build ap5, which was my original reason
for doing the nightly build.
My impression is that various tests have failed for long periods.
It would, admittedly, be interesting to find and report when the set
of failures changes.
Currently in the mt build (on the machine where that works)
make check ends with the following. The non-MT branch does not
report such failures.
Is this result interesting? Expected?
====
Test failed:
-rw-r--r--. 1 root root 3045 2009-10-30 10:08 pack11.erg
To see which tests failed, type
cat /root/clisp/build-mt/tests/*.erg
make[1]: *** [compare] Error 1
make[1]: Leaving directory `/root/clisp/build-mt/tests'
make: *** [check-tests-parallel] Error 2
[2009-10-30 10:09:21 root@number11 ~/clisp/build-mt]
$ cat /root/clisp/build-mt/tests/*.erg
Form: (TEST-PACKAGE-ITERATOR :COMMON-LISP)
CORRECT: T
CLISP : ERROR
Symbol COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found as :INTERNAL in package COMMON-LISP [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)]
OUT:
"[SIMPLE-ERROR]: Symbol COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found as :INTERNAL in package COMMON-LISP [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)]
"
Form: (WITH-PACKAGE-ITERATOR-INTERNAL (LIST (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 2
OUT:
"Not same symbol: COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-EXTERNAL (LIST (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 1
OUT:
"Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-INHERITED (LIST (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 1
OUT:
"Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-ALL (LIST (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 2
OUT:
"Not same symbol: COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-INTERNAL (LIST (FIND-PACKAGE "COMMON-LISP-USER") (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 2
OUT:
"Not same symbol: COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-EXTERNAL (LIST (FIND-PACKAGE "COMMON-LISP-USER") (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 1
OUT:
"Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-INHERITED (LIST (FIND-PACKAGE "COMMON-LISP-USER") (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 1
OUT:
"Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
Form: (WITH-PACKAGE-ITERATOR-ALL (LIST (FIND-PACKAGE "COMMON-LISP-USER") (FIND-PACKAGE "COMMON-LISP")))
CORRECT: T
CLISP : 2
OUT:
"Not same symbol: COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
"
|
|
From: Vladimir T. <vtz...@gm...> - 2009-10-30 18:10:05
|
On 10/30/09, Sam Steingold <sd...@gn...> wrote: >> [2009-10-30 10:09:21 root@number11 ~/clisp/build-mt] >> $ cat /root/clisp/build-mt/tests/*.erg >> Form: (TEST-PACKAGE-ITERATOR :COMMON-LISP) >> CORRECT: T >> CLISP : ERROR >> Symbol COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found >> as :INTERNAL in package COMMON-LISP >> [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)] >> OUT: >> "[SIMPLE-ERROR]: Symbol >> COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found as >> :INTERNAL in package COMMON-LISP >> [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)] >> " > ... > OTOH, I think packages have already been made gc-safe. > also, this looks really scary... I've encountered this as well and spent last few days tracking it. The problem is that somehow SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY appears twice in package internal symbols. I still do not know how this happens (all package modification are locked - but apparently something is missing). Vladimir |
|
From: Sam S. <sd...@gn...> - 2009-10-30 17:51:22
|
Don Cohen wrote: > > My impression is that various tests have failed for long periods. this is not my impression. > It would, admittedly, be interesting to find and report when the set > of failures changes. yes. > Currently in the mt build (on the machine where that works) > make check ends with the following. The non-MT branch does not > report such failures. > Is this result interesting? Expected? > > ==== > > Test failed: > -rw-r--r--. 1 root root 3045 2009-10-30 10:08 pack11.erg > To see which tests failed, type > cat /root/clisp/build-mt/tests/*.erg > make[1]: *** [compare] Error 1 > make[1]: Leaving directory `/root/clisp/build-mt/tests' > make: *** [check-tests-parallel] Error 2 this is pretty much expected: MT is not perfect yet. > [2009-10-30 10:09:21 root@number11 ~/clisp/build-mt] > $ cat /root/clisp/build-mt/tests/*.erg > Form: (TEST-PACKAGE-ITERATOR :COMMON-LISP) > CORRECT: T > CLISP : ERROR > Symbol COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found as :INTERNAL in package COMMON-LISP [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)] > OUT: > "[SIMPLE-ERROR]: Symbol COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY not found as :INTERNAL in package COMMON-LISP [(COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY :INTERNAL)] > " > > > Form: (WITH-PACKAGE-ITERATOR-INTERNAL (LIST (FIND-PACKAGE "COMMON-LISP"))) > CORRECT: T > CLISP : 2 > OUT: > "Not same symbol: COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY > Not same symbol (2): COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY COMMON-LISP::SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY > " OTOH, I think packages have already been made gc-safe. also, this looks really scary... |
|
From: Sam S. <sd...@gn...> - 2009-10-30 18:15:06
|
Vladimir Tzankov wrote:
>
> I've encountered this as well and spent last few days tracking it. The
> problem is that somehow SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
> appears twice in package internal symbols. I still do not know how
> this happens (all package modification are locked - but apparently
> something is missing).
do you observe that outside the testing too?
stand alone, not parallel it works fine:
./clisp -K boot -q -norc -i tests/tests -x '(run-test "tests/pack11")'
("tests/pack11" 208 0)
|
|
From: Vladimir T. <vtz...@gm...> - 2009-10-30 18:16:39
|
On 10/30/09, Sam Steingold <sd...@gn...> wrote:
> Vladimir Tzankov wrote:
>>
>> I've encountered this as well and spent last few days tracking it. The
>> problem is that somehow SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY
>> appears twice in package internal symbols. I still do not know how
>> this happens (all package modification are locked - but apparently
>> something is missing).
>
> do you observe that outside the testing too?
> stand alone, not parallel it works fine:
> ./clisp -K boot -q -norc -i tests/tests -x '(run-test "tests/pack11")'
> ("tests/pack11" 208 0)
No, it happens very rarely on check-tests-parallel (excl. mop & clos).
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X