;;; datatype trap handler had LEFT and RIGHT reversed
;;; they were both coming from A) but the LEFT had the type bits bahsed to zero ...
;;; the result of a (ALU SETR NOP A0 A0 BW-24 DT-BOTH-FIXNUM) testing a bignum for MINUSP


;;; &KEY handling of entry points was all wrong for MEMBER and probably others compiled ages ago ..

;;; compiler macro expands DO, DO* and friends
;;; but there is no version to run on the K

;; added VECTOR-PUSH-EXTEND  to the PACKAGE-DEFINITIONS ARRAY-IMPORTS list
;; (what a pain in the ass: if this import does not appear in LI:
;; when the file calling VECTOR-PUSH-EXTEND is compiled
;; the K will not array:VECTOR-PUSH-EXTEND when it tries to call it
;; it will be looking for li:VECTOR-PUSH-EXTEND
;; lose lose lose
;; --pfc


;; VECTOR-PUSH-EXTEND does not do an extend


;;; (funcall 'funcall ..) as in MACROEXPAND fails..

;;; there is some mysterious stuff going on with ENTRY-POINTS and number of args passed in 


;;; either FUNCALL-INTERNAL or the compiled code for DO is failing badly ...
;;;   (setq foo (funcall 'funcall (macro-function 'do) '(do ) nil))
;;;     returns (block nil  ( #\) nil tagbody ...)
;;;   actually sending  (DO) to the interpreter  tries to eval the form  ( (do) # # #)
;;; bad news


;;; and when you try to resume the mini-listener
;;; FUNCALL-INTERNAL tries to get a symbol-function for NFRAME 
;;; where did that come from ???
;;; I believe throw and catch are bombing out ...

;;; EVAL-BLOCK  uses an UNWIND-PROTECT and I see an LI:UNWIND-MARKER on the stack ...