Re: next nightly build problem

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
build-porting64-gcc-spvw_pure_blocks, which triggers a Heisenbug:
  *** - APPLY: too few arguments for #<STANDARD-GENERIC-FUNCTION COMPUTE-SLOTS>
I don't know how to track down this one at the moment.

>  > Depends on what you want to do.
>  > 
>  > - The set of builds that failed gives you an understanding which features
>  >   caused regressions. In this case it's evident: forcing HEAPCODES worked,
>  >   forcing TYPECODES worked, but the default choice did not work.
>  > 
>  > - If you are interested in continuous integration, you may want to
>  >   set up build scripts that use 'multibuild-porting64-gcc' and
>  >   signal regressions in any of the build configurations. This would
>  >   be useful for Sam and me.
> 
> ok, that seems worth while.
> At the moment I'm only running nightly builds on one linux machine,
> a recent fedora.  Would it be useful to run on other recent linux
> distributions?  I'm guessing a very old one would be less useful.

No, just one machine is enough. The point of these nightly builds would be that
we get we don't introduce regressions for configurations that we don't test
frequently.

The point of these many configurations is that clisp's features depend on
OS features (mmap available or not, process address range) and limitations
(aligned vs. unaligned addresses); therefore it is entirely natural that, say,
an AIX 64-bit machine is using a different configuration than a Linux x86
machine. But the main developers test only 1 or 2 of these configurations
regularly. So far, regressions in the other configurations have gone unnoticed
for a long time and often also made it into releases.

This is where a continuous integration testing provides a great benefit.

>  > - If you want to know about the performance: Since "make check" runs the
>  >   benchmarks, in particular, the log file contains the benchmark results.
>  >   You can compare them:
> 
> This had also occurred to me.
> Does that enter into the default choice?
> What is the current default (and why)?

I've now changed the default choice, with portability in mind. Performance
differences of less than 5% is IMO no longer important in a world where
everyone is crying "clisp does not build for me".

> When I get software updates will the local patch be undone?
> If not, I really should undo it, right?  
> Just guessing, would that be done like this?
>   hg diff -c d61ff18e7daa | patch -p1

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

Bruno


------------------------------------------------------------------------------
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