[Openmcl-devel] trunk changes

Gary Byers gb at clozure.com
Tue Sep 22 04:30:23 UTC 2009

I checked in some changes to the compiler frontend a little while ago (r12861
and r12869).  These changes are a bit hard to bootstrap, so I also checked
in new .image files for all platforms; you'll need the new images to compile
those changes.

Please remember that "svn update" will not generally overwrite locally
modified binary files; if you've used REBUILD-CCL to rebuild your copy
of the lisp, the .image files count as being "locally modified".  There
are several ways to work around this, including:

If you use svn 1.5 or later, "svn update" will generally ask you what
to do when a binary file has been updated in the repository and the local
copy appears to be modified (if it thinks that it's running interactively.)
The appropriate response in this case is 'tf' ("theirs full") to replace
the local copy with the repository version.
(The version of svn that ships with Snow Leopard seems to be 1.6.2; other
platforms distribute 1.5 or later in relatively recent releases.)

With any version of svn, you can do:

$ svn revert -R .
(note the trailing ".")

in the CCL directory after an "svn update" to replace conflicting
local files with the repository versions (which "svn update"
downloaded and is keeping in some hidden .svn directory for you.)

On an unrelated note, the images that I committed are a few MB larger than
they'd ordinarily be; that's because some settings in my init file cause
the build process to retain some extra source-location information.  Those
extra few MB affect disk size (and transmission time), but that information's
usually not loaded into memory and doesn't cost much VM-wise when it is.

On another unrelated note: there's at least one warning that occurs
while recompiling the lisp on the PPC (something having to do with
%UNWATCH being called with the wrong number of arguments.)  Matt's
been working on this code and he probably has a better idea than I do
of what the fix is; it's fair to consider the warning to be harmless
until Matt's work on that is finished.

As far as the conflicting binary file issue goes: I find that it's not too
hard to understand the issue but it may be hard to remember the possibility
and recognize the situation when it occurs.  If that's true, then a simple
way of reminding everyone of the issue is to declare that the first person
who reports that the trunk won't compile as a result of these changes owes
me US$1, the next person to do so would owe me $2, then $4, etc.  If a few
dozen people report that, then I guess that I'm mistaken in thinking that
this issue really isn't hard to deal with, and I promise to feel really bad
about that while laying on the beach on my new private island.

On a last note: it's certainly possible that I broke something in the
compiler frontend as a result of these changes; all that I really know
for sure is that the lisp does bootstrap itself (and therefore I don't
owe myself any money.)  If you run across a problem compiling other
code, please report it as soon as possible (before I become too
fabulously wealthy to want to work on fixing it.)

More information about the Openmcl-devel mailing list