[Openmcl-devel] trunk instability

[Gary Byers]

The CCL trunk is nominally stable again.  There are new binaries (kernels and heap
images) for all platforms, and it's necessary to use these new binaries to rebuild
CCL.  The FASL version also changed; FASL files produced by previous versions
won't work with this version and vice-versa.

Recall that "svn update" won't usually overwrite locally-modified binary files
with new versions from the repository; there are several ways of persuading it
to do so, one of which is:

$ cd ccl
$ svn update
$ svn revert -R .

Trying to compile the current sources with older binaries can lead to errors
about the class "ACODE" being undefined (and possibly other problems); if you
get these errors, please make sure that you are indeed using updated binaries.

Most of the changes relative to trunk versions are under the hood and shouldn't
be user-visible (though I think that compilation speed has improved a bit.)  Some
exceptions to that include:

- there are now specialized subtypes of COMPLEX - (COMPLEX SINGLE-FLOAT) and
   (COMPLEX DOUBLE-FLOAT) - and corresponding specialized ARRAY types
- on the ARM (and soon on x8664), AREF (and SETF thereof) of non-simple arrays
   whose element-type is known can be open-coded
- on the ARM (and soom on x8664), variables whose declared/inferred type is
   a subtype of FLOAT (and of (COMPLEX FLOAT)) can be kept in onboxed stack
   locations.

I've generally this version (which I've been using on a development branch)
to be usable, but of course YMMV.  The CCL trunk is often fairly stable in
practice, but the under-the-hood changes are fairly extensive in this case
and you should probably view them with more suspicion than usual.  Please
open tickets for any bugs that you find, and please remember that there's
a standing fine (currently US $4) for anyone who forgets to use updated
binaries to recompile the sources and reports that.


On Tue, 27 May 2014, Gary Byers wrote:

> The CCL trunk will be in flux over the next day or two as changes from a 
> development
> branch are merged into it; it may not build or run correctly until this 
> process
> is complete.
>
> I'll sound the all-clear here when that happens.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://lists.clozure.com/mailman/listinfo/openmcl-devel
>
>