[Openmcl-devel] 0.14 darwin build procedure?
jcbuffington at mac.com
Sat Jul 5 16:19:24 EDT 2003
Thanks for locating and fixing the NTHCDR problem. I was able to
successfully build OpenMCL "Pre_0_14" from cvs. I seem to be
consistently luckier than others in locating problems. :-)
On Saturday, July 5, 2003, at 12:43 AM, Gary Byers wrote:
> There was a bug(let) introduced in NTHCDR a couple of days ago, which
> caused it (and NTH) to try to handle the general case of an
> index (instead of simply assuming that any valid list index must be a
> when the index was 0. The unsigned-fixnum and the UNSIGNED-BYTE case
> be entirely equivalent, but very early in the loading sequence the
> predicate UNSIGNED-BYTE-P is undefined; NTHCDR should have realized
> 0 is a fixnum and never reached this point.
> The code that triggered the buglet for you was trying to update a
> cache; those caches are sort of simple hash tables whose layout depends
> at least partly on the random-number generator (and may depend on other
> not-entirely deterministic factors.) I think that this means that
> been running into this more because of bad luck than for any other
> On Fri, 4 Jul 2003, Jon Buffington wrote:
>> I disabled my init file and rebuilt. (BTW, Is there a switch in
>> ./dppccl that disables init file loading? If not, can I put a request
> -n or --no-init will suppress loading the init file; -h or --help will
> show this and other command-line arguments.
>> Below is the output from the debugger that you requested. I
>> will also re-download the binaries and source to re-build the image
>> before doing a cvs update.
> In this particular case, that'd have told us that it was a recent CVS
> change that was causing the problem. (I stared at NTHCDR for 10
> before seeing the problem and another 10 minutes before seeing that the
> bignum case didn't work and was grossly inefficient as well, so it's
> not clear that that would have helped as much as the backtrace/register
> info did.)
>> I was trying to make sure I included your
>> recent fixes prompted by Kevin's tests. Is there a particular cvs tag
>> should use to receive blessed fixes? For example, in PLT scheme the
>> 'exp' tag is guaranteed to build the latest source.
> Not having run into the NTHCDR problem or having heard of it, I would
> have said that the latest and greatest stuff on the Pre_0_14 tag would
> have built cleanly (and that this should generally be true most of the
> time); if there were some scheme to have blessed the CVS sources as of
> an hour ago, I would have blessed them.
> There clearly has to be -some- scheme to keep the "so-bleeding-edge-
> it's-not-even-parenthesized-right" (or, more likely, "very-hard-to-
> bootstrap-from-latest-binaries") stuff separate from the "latest-
> believed-to-be-mostly-working-please-test-it" stuff. At the moment,
> the Pre_0_14 CVS head is supposed to be in the in the latter category,
> and it seems that you just wound up unexpectedly testing NTHCDR.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel