Thank you so much Gary!<div><br></div><div><div><div class="gmail_quote">On Sun, Mar 20, 2011 at 6:49 PM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com">gb@clozure.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The bug caused an error to occur while the .cdb files were being rebuilt,<br>
so you likely have a bunch of empty or partial .cdb files and things<br>
like #$ can't find constant/type/function definitions in them.<br>
<br>
There are two ways to recover working copies:<br>
<br>
1) before trying to create new .cdb files, the interface parser made<br>
backup copies (with extensions like .cdb-BAK or something like that;<br>
I don't remember off the top of my head.) The backup copies are<br>
in (e.g.) .../x86-headers64/libc, right next to the new/empty .cdb<br>
files. It'd be nice if the interface parser did so for you if an<br>
error occurs, but you can manually just recover the .cdb files from<br>
the backup copies.<br>
2) svn essentially maintains a backup copy of the entire CCL tree, so<br>
you can do:<br>
<br>
$ cd ccl/x86-headers64/libc<br>
$ svn revert *.cdb<div class="im"><br></div></blockquote><div><br></div><div>This is really good to know. Thank you. I'm really liking how nice the .CDB system is. It's really making life so much easier to interface with C code!</div>
<div><br></div><div><br></div><div>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). </div>
<div><br></div><div>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:</div>
<div><br></div><div><div>;Compiling "/Users/jaten/pkg/ccl-trunk/source/compiler/optimizers.lisp"...</div><div>> Error: Compiler bug or inconsistency:</div><div>> x862-form ? (28748)</div><div>> While executing: COMPILER-BUG, in process listener(1).</div>
<div>> Type :POP to abort, :R for a list of available restarts.</div><div>> Type :? for other options.</div><div>1 > :b</div><div> (1A17CF8) : 0 (COMPILER-BUG "x862-form ? ~s" (28748)) 141</div><div> (1A17D18) : 1 (X862-FORM #<DLL-HEADER #x302000C22D1D> #<LREG 2 GPR [7]> NIL (28748)) 821</div>
</div><div>... (full details in the attached)</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In those environments,<br>
the M-. ("meta-dot" or "meta-point") editor command can be used to find the<br>
source to a definition, and other things ("go to source location where error<br>
occurred") also use this information.</blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">C-d or :POP should be equivalent and exit the innnermost break loop; :Q</div>
is supposed to exit all break loops and get back to the toplevel REPL.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>Thank you!</div><div><br></div><div>Best regards,</div><div>Jason</div><div><br></div></div>
</div></div>