[Openmcl-devel] 0.14 darwin build procedure?

[Jon Buffington]

Gary,

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. :-)

Cheers,
Jon

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 
> UNSIGNED-BYTE
> index (instead of simply assuming that any valid list index must be a 
> fixnum)
> when the index was 0.  The unsigned-fixnum and the UNSIGNED-BYTE case 
> should
> be entirely equivalent, but very early in the loading sequence the
> predicate UNSIGNED-BYTE-P is undefined; NTHCDR should have realized 
> that
> 0 is a fixnum and never reached this point.
>
> The code that triggered the buglet for you was trying to update a 
> method
> 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 
> you've
> been running into this more because of bad luck than for any other 
> reason.
>
> 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
>> -noinit?)
>
> -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 
> minutes
> 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 
>> I
>> 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.
>
>>
>> Cheers,
>> Jon


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel