fasl file version.
changes in sbcl-0.7.0 relative to sbcl-0.6.13:
+* incompatible change: The default fasl file extension has changed
+ to ".fasl", for all architectures. (No longer ".x86f" and ".axpf".)
* There are new compiler optimizations for various functions: FIND,
POSITION, FIND-IF, POSITION-IF, FILL, COERCE, TRUNCATE, FLOOR, and
CEILING. Mostly these should be transparent, but there's one
:SB-PROPAGATE-FUN-TYPE are no longer considered to be optional
features. Instead, the code that they used to control is always
built into the system.
-?? lots of tidying up internally: renaming things so that names are
+* lots of tidying up internally: renaming things so that names are
more systematic and consistent, converting C macros to inline
functions, systematizing indentation
* The fasl file version number changed again, for any number of
instead of the old "5]", "5]]", "5]]]" sequence. (I was motivated
to do this when squabbles between ILISP and SBCL left me
very deeply nested in the debugger.)
-* The fasl file extension may change, perhaps to ".fasl".
* The default output representation for unprintable ASCII characters
which, unlike e.g. #\Newline, don't have names defined in the
ANSI Common Lisp standard, may change to their ASCII symbolic
"SB!EXT" "SB!INT" "SB!KERNEL" "SB!SYS")
:export ("*ASSEMBLER-ROUTINES*"
"+BACKEND-FASL-FILE-IMPLEMENTATION+"
- "*BACKEND-FASL-FILE-TYPE*"
+ "*FASL-FILE-TYPE*"
"CLOSE-FASL-OUTPUT"
"DUMP-ASSEMBLER-ROUTINES"
"DUMP-OBJECT"
;;; 15 = sbcl-0.6.12.33 changed the layout of STREAM
;;; 16 = sbcl-0.pre7.15 changed the layout of PRETTY-STREAM
-;;; the conventional file extension for fasl files on this
-;;; architecture, e.g. "x86f"
-(declaim (type (or simple-string null) *backend-fasl-file-type*))
-(defvar *backend-fasl-file-type* nil)
+;;; the conventional file extension for our fasl files
+(declaim (type simple-string *fasl-file-type*))
+(defvar *fasl-file-type* "fasl")
;;; This is a sort of pun that we inherited from CMU CL. For ordinary,
;;; non-byte-coded fasl files, the "implementation" is basically the
(stream-fresh-line stream))))
(defun write-string (string &optional (stream *standard-output*)
- &key (start 0) (end (length (the vector string))))
+ &key (start 0) (end (length (the string string))))
;; FIXME: These SETFs don't look right to me. Looking at the
;; definition of "bounding indices" in the glossary of the ANSI
(internal-load pathname truename if-does-not-exist verbose print
:binary))
(t
- (when (string= (pathname-type truename) *backend-fasl-file-type*)
+ (when (string= (pathname-type truename) *fasl-file-type*)
(error "File has a fasl file type, but no fasl file header:~% ~S"
(namestring truename)))
(internal-load pathname truename if-does-not-exist verbose print
(multiple-value-bind (src-pn src-tn)
(try-default-type pathname *load-source-default-type*)
(multiple-value-bind (obj-pn obj-tn)
- (try-default-type pathname *backend-fasl-file-type*)
+ (try-default-type pathname *fasl-file-type*)
(cond
((and obj-tn
src-tn
(defvar *host-obj-prefix*)
(defvar *target-obj-prefix*)
-;;; suffixes for filename stems when cross-compiling. Everything should work
-;;; fine for any arbitrary string values here. With more work maybe we
-;;; could cause these automatically to become the traditional extensions for
-;;; whatever host and target architectures (e.g. ".x86f" or ".axpf") we're
-;;; currently doing. That would make it easier for a human looking at the
-;;; temporary files to figure out what they're for, but it's not necessary for
-;;; the compilation process to work, so we haven't bothered.
+;;; suffixes for filename stems when cross-compiling. Everything
+;;; should work fine for any arbitrary string values here. With more
+;;; work maybe we could cause these automatically to become the
+;;; traditional extensions for whatever host and target architectures
+;;; (e.g. ".x86f" or ".axpf") we're currently doing. That would make
+;;; it easier for a human looking at the temporary files to figure out
+;;; what they're for, but it's not necessary for the compilation
+;;; process to work, so we haven't bothered.
(defvar *host-obj-suffix* ".lisp-obj")
(defvar *target-obj-suffix* ".lisp-obj")
\f
;;;; compiler constants
-(setf *backend-fasl-file-type* "axpf")
(defconstant +backend-fasl-file-implementation+ :alpha)
(setf *backend-register-save-penalty* 3)
;;; compiled files.
(defun cfp-output-file-default (input-file)
(let* ((defaults (merge-pathnames input-file *default-pathname-defaults*))
- (retyped (make-pathname :type *backend-fasl-file-type*
- :defaults defaults)))
+ (retyped (make-pathname :type *fasl-file-type* :defaults defaults)))
retyped))
;;; KLUDGE: Part of the ANSI spec for this seems contradictory:
\f
;;;; compiler constants
-(setf *backend-fasl-file-type* "x86f")
(defconstant +backend-fasl-file-implementation+ :x86)
(setf *backend-register-save-penalty* 3)
(load "TEST:$StudlyCapsStem")
(assert (eq *loaded* :yes))
(let ((compiled-file-name (namestring (compile-file "TEST:$StudlyCapsStem")))
- (expected-file-name "$testdir/$testfilestem.x86f"))
+ (expected-file-name "$testdir/$testfilestem.fasl"))
(format t "compiled-file-name=~S~%" compiled-file-name)
(format t "expected-file-name=~S~%" expected-file-name)
(assert (string= compiled-file-name expected-file-name)))
;;; for internal versions, especially for internal versions off the
;;; main CVS branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.pre7.27"
+"0.pre7.28"