Re: next nightly build problem

Bruno Haible writes:
 > Hi Don,
 > 
 > >  > - If you are interested in a build that works, choose one of those with a
 > >  >   large cbcstep3.log.
 > > 
 > > I'm hoping before long they'll all work.
 > 
 > It's better now: on Linux/x86_64 all pass for me, except for

$ ls -l build-*/cbcstep3.log
-rw-rw-r--. 1 don don 3043905 Mar  5 14:33 build-porting64-gcc-generational_gc-multithread_gc/cbcstep3.log
-rw-rw-r--. 1 don don 3040454 Mar  5 14:31 build-porting64-gcc-generational_gc-old_gc/cbcstep3.log
-rw-rw-r--. 1 don don 3039228 Mar  5 14:09 build-porting64-gcc-generic64_heapcodes/cbcstep3.log
-rw-rw-r--. 1 don don 3034785 Mar  5 14:03 build-porting64-gcc-heapcodes/cbcstep3.log
-rw-rw-r--. 1 don don 3043202 Mar  5 14:18 build-porting64-gcc-heapcodes-spvw_mixed_blocks/cbcstep3.log
-rw-rw-r--. 1 don don 3040171 Mar  5 14:12 build-porting64-gcc-heapcodes-spvw_pages/cbcstep3.log
-rw-rw-r--. 1 don don 3036625 Mar  5 14:28 build-porting64-gcc-multithread_gc/cbcstep3.log
-rw-rw-r--. 1 don don 3033154 Mar  5 14:26 build-porting64-gcc-old_gc/cbcstep3.log
-rw-rw-r--. 1 don don 3035492 Mar  5 13:58 build-porting64-gcc-portability/cbcstep3.log
-rw-rw-r--. 1 don don 3033094 Mar  5 14:36 build-porting64-gcc-safety0/cbcstep3.log
-rw-rw-r--. 1 don don 3037978 Mar  5 14:38 build-porting64-gcc-safety0-optimized/cbcstep3.log
-rw-rw-r--. 1 don don 3033187 Mar  5 14:01 build-porting64-gcc-safety3/cbcstep3.log
-rw-rw-r--. 1 don don 3037636 Mar  5 14:23 build-porting64-gcc-spvw_pure_blocks/cbcstep3.log
-rw-rw-r--. 1 don don 3038762 Mar  5 14:06 build-porting64-gcc-standard_heapcodes/cbcstep3.log
-rw-rw-r--. 1 don don 3042771 Mar  5 14:20 build-porting64-gcc-typecodes-spvw_mixed_blocks/cbcstep3.log
-rw-rw-r--. 1 don don 3039694 Mar  5 14:15 build-porting64-gcc-typecodes-spvw_pages/cbcstep3.log

 > build-porting64-gcc-spvw_pure_blocks, which triggers a Heisenbug:

Does that mean it sometimes appears and sometimes does not?

 >   *** - APPLY: too few arguments for #<STANDARD-GENERIC-FUNCTION COMPUTE-SLOTS>
 > I don't know how to track down this one at the moment.

I don't see that in my output.


 > Yes, you guessed right. I would also revert such a local change before
 > doing "hg pull --update" and then re-apply it.

Currently my nightly build script does a pull.
It wouldn't make much sense to patch and unpatch as part of
that script.

It sounds like for now I should leave the patch in place 
so I've done (after generating the output above)
  hg diff -c d61ff18e7daa | patch -p1

and when that gets fixed so the nightly builds work again,
I'll try adding multibuild port to the script.
It looks like I have to first do
 rm -rf build-*
or make thinks there's nothing to do.

Do you think it's adequate to just look for logs that are smaller than
3 MB as an indicator of failure, or look at tails of the logs as I now
do or something else?

BTW, a sample of what I see there:

  $ tail build-porting64-gcc-standard_heapcodes/cbcstep3.log

  WARNING: SYSTEM::ENSURE-IMPNOTES-MAP: invalid symbol "POSIX:CLIPBOARD" with id
           "clipboard":
           READ from #<INPUT STRING-INPUT-STREAM>: #<PACKAGE POSIX> has no
           external symbol with name "CLIPBOARD"

  662 IDs
  "http://clisp.org/beta/impnotes/"
  Bye.
  make[1]: Leaving directory '/home/don/hg/clisp/build-porting64-gcc-standard_heapcodes'

My normal nightly test creates both a mt and a non-mt clisp and 
then an ap5 image in each.  Since there is some #+/- mt in the
current ap5 code, I do want to test each of those, but I don't
think I have anything that depends on memory models.
I don't even know how to check in lisp what memory model is in use.

I see two appearances of multithread in the multi build port list.
Are those independent of #+MT ?  Using a multi thread gc which is
independent of #+MT ?  Are any or all of the tests above #+MT ?

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel