Re: bugs in C::SOURCE-LOCATION and string reversal

Thanks for dealing with these issues.

Regarding:

>> We also found another issue.  If *default-pathname-defaults* is set to
>> some non-default value, the dumped core retains the value.  Not sure
>> what the correct behaviour should be for this.

I did a little test with CCL, LispWorks, and GCL and found that they
retain the value too.  So apparently it's the application's
responsibility (i.e., my responsibility) to deal with this.
Interestingly, SBCL and Allegro CL apparently do not retain the value,
instead setting it at startup to match the current working directory;
and CLISP seems to set it to #P"" at startup.

I'll probably just arrange that when my application starts up, if
(pathname-directory *default-pathname-defaults*) is non-nil, then
*default-pathname-defaults* is assigned the value of (make-pathname).

Regards,
Matt
   From: Raymond Toy <[email protected]>
   Date: Wed, 15 May 2013 20:34:20 -0700

   >>>>> "Matt" == Matt Kaufmann <[email protected]> writes:

       Matt> The first bug pertains to C::SOURCE-LOCATION.  Below is part of the
       Matt> log, showing three errors during compilation followed by a break
       Matt> during load of the resulting compiled file.

       Matt> ; 
       Matt> ; 
       Matt> ; File: /v/filer4b/v11q002/acl2space/acl2/devel/books/centaur/gl/[email protected]

       Matt> ; In: DEFMACRO GL-BDD-MODE => DEFATTACH GL::BFR-MODE

       Matt> ;   (DEFATTACH GL::BFR-MODE GL::BFR-BDD)
       Matt> ; --> DEFPARAMETER PROGN LISP::SET-DEFVAR-SOURCE-LOCATION 
       Matt> ; --> LISP::SET-DEFVAR-SOURCE-LOCATION 
       Matt> ; ==>
       Matt> ;   (C::SOURCE-LOCATION)
       Matt> ; Error: (during macroexpansion)
       Matt> ; Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
       Matt> ;    27574 is not of type (UNSIGNED-BYTE 14)

   With help from Matt, I've been able to reproduce this.  I think the
   issue is that the file [email protected] is a 500 KB source file with
   way too many forms in it and exceeding the limit 14 bits that the
   compiler allocates for the top-level form number and the form number.

   We also found another issue.  If *default-pathname-defaults* is set to
   some non-default value, the dumped core retains the value.  Not sure
   what the correct behaviour should be for this.

   Ray

   _______________________________________________
   cmucl-help mailing list
   [email protected]
   http://lists.zs64.net/mailman/listinfo/cmucl-help

_______________________________________________
cmucl-help mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-help