[Openmcl-devel] 3 questions - TLS the default? global thread-shared vars? .CDB gen broken?

[Gary Byers]

On Sun, 20 Mar 2011, Jason E. Aten wrote:
> I still suspect that there is a bug that is causing the EX_OSERR issue but
> has already been fixed somewhere between the 1.6 release and the current
> trunk. ?Obviously it shouldn't be a priority because it has already been
> fixed by the trunk (at least I don't encounter it at r14684).?

EX_OSERR is the first foreign constant (or foreign type, or foreign
function ...) that's referenced during a call to REBUILD-CCL.  If the #$
reader macro can't find the definition of that constant in the interface
database, it's likely that nothing can be found in the interface database.
That's usually indicative of an installation or configuration problem.
That stuff (interface lookup) has to work in order for the lisp to be able
to compile itself, and a bug that would keep that from working isn't likely
to go unnoticed for very long.

An "installation or configuration problem" usually means that the .cdb files
are missing (or at least aren't where CCL is looking for them.)  This usually
results in a warning to the effect that some .cdb file can't be found (shortly
before the resulting error.)

If the files were missing for some reason, then "svn update" would restore
them.  I don't know for sure if this is what you're seeing or not, but I
don't believe that updating to different versions of CCL will otherwise
fix the problem; that just doesn't make sense.

A couple of other things to remember about 'svn update':

1) If files in the working copy are locally modified, 'svn update' will
    either:
    (a) try to merge changes from the repository with local changes if
        the file is a text file.
    (b) leave the local version alone if the file is a binary file.
        Newer versions of svn may offer a menu of options in this case;
        if you want to replace the local version with the repository
        version, the incantation to use is 'tf' ("theirs full").

2) Because of the way that CCL uses "svn externals", doing

$ cd ccl
$ svn update -r <some-rev>

    will update the contents of the root of CCL tree to the specified revision
    but update all subdirectories to the latest version.  That's generally not
    what you want.   (You can enter each directory and do "svn update -r ..."
    to the same revision and that'll eventually get you to a state where the
    sources and binaries match.)

The compiler bug that you're seeing is pretty much what'd happen if you tried
to compile current sources with a trunk image older than r14408.  Right around
that time, a change was made to the compiler frontend.  That change had to
be bootstrapped carefully, and that meant that images based on r14408 (where
the change was partially completed) had to be used to compile subsequent
versions of the trunk.  We checked appropriate heap images for all platforms
into the trunk; the behavior that you describe is exactly what would happen
if an older image was used to compile current sources.

Moral:
1) Unless you're really sure of what you're doing, always use the latest image
(or something derived from it) to compile current trunk sources.
2) Reporting a bug that's in fact a failure to observe (1) is punishable by a
fine in the amount of 2X the amount of the previous violation, payable to me.

This is intended to help reinforce the need to be aware of these issues and
to enable me to buy an island and enjoy a life of leisure.  It's been fairly
effective at achieving the first goal, but the "islands" that one can buy
for $7 are aesthetically disappointing, to be blunt about it.


> 
> I base that conclusion on the observation that the same EX_OSERR occurs in
> the 1.6 binary when doing (rebuild-ccl :full t) under 1.6-r14471M
> ?(DarwinX8664)?on my mac book pro, running OSX 10.6.3 on x86_64, which has
> completely fine .cdb files, untouched from the 1.6 binary distribution. ?The
> EX_OSERR goes away on the MBP when I build from the trunk at r14684.
> ?Moreover the EX_OSERR also went away on Linux when I went to head of the
> trunk. ? Since trunk development is naturally not expected necessarily to be
> stable yet, so I will only note in passing (see the attached file for
> details if this helps), that my build of the trunk still terminates early
> (on OSX only; Linux built fine), reporting a different kind of compiler
> error, which reads in summary as:
> 
> ;Compiling "/Users/jaten/pkg/ccl-trunk/source/compiler/optimizers.lisp"...
> > Error: Compiler bug or inconsistency:
> > ? ? ? ?x862-form ? (28748)
> > While executing: COMPILER-BUG, in process listener(1).
> > Type :POP to abort, :R for a list of available restarts.
> > Type :? for other options.
> 1 > :b
> ?(1A17CF8) : 0 (COMPILER-BUG "x862-form ? ~s" (28748)) 141
> ?(1A17D18) : 1 (X862-FORM #<DLL-HEADER #x302000C22D1D> #<LREG 2 GPR [7]> NIL
> (28748)) 821
> ... (full details in the attached)
> 
> 
>
>       In those environments,
>       the M-. ("meta-dot" or "meta-point") editor command can be used
>       to find the
>       source to a definition, and other things ("go to source location
>       where error
>       occurred") also use this information.
> 
> 
> Yes, sorry, let me clarify. ?I wondered if the ccl toplevel REPL itself was
> also retaining each function definitions lisp forms, say as typed in
> directly rather than read from file? ?The change logs I happened up when
> googling led me to think that the disassembler required these, so I wondered
> if they are stored somewhere that a command directly at the ccl prompt might
> ferret them out? ?I'm just used to R's system (descended from Scheme and
> Lisp) that makes it easy to determine which version of a possibly
> hot-swapped function is now in effect; typing the name of the function at
> the REPL gives it's current definition.
> 
> ?
>       C-d or :POP should be equivalent and exit the innnermost break
>       loop; :Q
> is supposed to exit all break loops and get back to the toplevel REPL.
> 
> 
> Oh yes, yes. Sorry I wasn't clear. ?I wanted to configure the condition
> system to just skip asking me what restart I wanted. Instead, I would like
> ccl to just print the error and then return me to the top level without
> having to press :Q. ?It might not be doable of course, but if it is, I would
> appreciate any hints on how to do this. ?Perhaps I can define a default top
> level condition handler that says "I got it," but then it does nothing but
> return to the REPL.
> 
> Thank you!
> 
> Best regards,
> Jason
> 
> 
>