[Openmcl-devel] The MAX-1-BIT-CONSTANT-INDEX error

[R. Matthew Emerson]

On Jan 28, 2010, at 6:23 AM, Tim Bradshaw wrote:

> I get this when trying to rebuild CCL.  Just telling it to continue is  
> fine, obviously.

From time to time, constants do get redefined (especially in the trunk).

From the point of view of a user rebuilding ccl to pick up the latest fixes, just continuing from the CERROR is the right thing to do.

> I assumed this was because things were getting  
> redefined, and once I'd rebuilt once it would not complain again.  But  
> it does seem to do so sometimes.
> 
> My rebuild script basically ends up doing a
> 
> 	ccl64 -n -e '(progn (ccl:rebuild-ccl :full t) (quit))'
> 
> Which I think is standard.
> 
> I think the problem is that when I do an svn update, I blow away the  
> various images to force svn to refetch them, to prevent the svn-not- 
> overwriting-the-image-causing-lossage problem, but the images in the  
> repository have the old value of MAX-1-BIT-CONSTANT-INDEX in them,  
> causing the next rebuild to run into the error again.

Binding ccl::*cerror-on-constant-redefinition* to nil should suppress these CERRORs, so if you make your script look something like

(let ((ccl::*cerror-on-constant-redefinition* nil))
  (rebuild-ccl :full t))

then your build should succeed.

My (perhaps incorrect) assumption is that this problem is peculiar to your method of rebuilding;  if I'm wrong about that, then maybe it would make sense to provide another keyword argument to REBUILD-CCL to do this, rather than relying on binding a magic internal special variable.

> If that's a correct diagnosis, could someone commit new images?  It's  
> hardly a crippling problem of course, but it would be nice for the  
> update/rebuild process to not require manual intervention.

I'm not very excited about building and checking in 14 new heap images for minor changes like this...maybe it wouldn't be so bad if we had an automated process to build images for all the platforms, but we don't.