From: vrotaru <ro...@ce...> - 2005-09-11 00:52:32
|
Hi, all A few hours early, with some rather convoluted code (doing a problem from SPOJ), I have run into this: propmpt> sbcl [..] * (compile-file "sbcl-bug") ; compiling file "/home/rv/lisp/homework/sbcl-buf/sbcl-bug.lisp" (written 11 SEP 2005 02:04:38 AM): ; compiling (LET* (# # ...) ...) debugger invoked on a SB-INT:BUG in thread #<THREAD "initial thread" {9003439}>: failed AVER: "(EQ PHYSENV (LAMBDA-PHYSENV (LAMBDA-VAR-HOME THING)))" This is probably a bug in SBCL itself. (Alternatively, SBCL might have been corrupted by bad user code, e.g. by an undefined Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers from alien code or from unsafe Lisp code; or there might be a bug in the OS or hardware that SBCL is running on.) If it seems to be a bug in SBCL itself, the maintainers would like to know about it. Bug reports are welcome on the SBCL mailing lists, which you can find at <http://sbcl.sourceforge.net/>. Offending file follows ;;;; -*- Mode: Lisp; Syntax: ANSI-COMMON-LISP; -*- (let* ((initial-size (expt 2 16)) (prime-table (make-array initial-size :element-type 'integer)) (first-primes #(5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281)) (count 0) (increment 2)) (defun largest-prime-so-far () (aref prime-table (1- count))) (defun add-prime (prime) (setf (aref prime-table count) prime) (incf count)) (defun init-table () (map 'nil #'add-prime first-primes)) (defun next-candidate (candidate) (prog1 (+ candidate increment) (ecase increment (2 (setf increment 4)) (4 (setf increment 2))))) (defun prime-p (n) (let ((sqrt-n (truncate (sqrt n)))) (dotimes (i count) (let ((prime (aref prime-table i))) (when (> prime sqrt-n) (return-from prime-p t)) (when (zerop (mod n prime)) (return-from prime-p nil)))) (error "~&prime-table too small: ~A ~A~%" n (largest-prime-so-far)))) (defun generate-primes (required) (do ((candidate (next-candidate (largest-prime-so-far)) (next-candidate candidate))) ((> candidate required)) (when (prime-p candidate) (add-prime candidate)))) ;; (init-table)) An interesting data point is that from Emacs (via C-c C-c) this form compiles O.K. -- If in doubt, enjoy it. |
From: vrotaru <ro...@ce...> - 2005-09-11 01:13:07
|
On Sun, 11 Sep 2005 02:28:41 +0200, vrotaru wrote: > Hi, all > I have somehow forgotten about "bugetiquette", so: system: Lunux-i386-2.6.12 sbcl: 0.9.3 -- If in doubt, enjoy it. |
From: Brian M. <br...@ma...> - 2005-09-11 01:19:35
|
On Sep 10, 2005, at 8:11 PM, vrotaru wrote: > On Sun, 11 Sep 2005 02:28:41 +0200, vrotaru wrote: > > >> Hi, all >> >> > > I have somehow forgotten about "bugetiquette", so: > > system: Lunux-i386-2.6.12 > sbcl: 0.9.3 Thanks. But it reproduces fine for me with 0.9.4 on PPC/Darwin too. And it seems that WHN has preceded me: ;; I think that a failure of this assertion means that we're ;; trying to access a variable which was improperly closed ;; over. The PHYSENV describes a physical environment. Every ;; variable that a form refers to should either be in its ;; physical environment directly, or grabbed from a ;; surrounding physical environment when it was closed over. ;; The ASSOC expression above finds closed-over variables, so ;; if we fell through the ASSOC expression, it wasn't closed ;; over. Therefore, it must be in our physical environment ;; directly. If instead it is in some other physical ;; environment, then it's bogus for us to reference it here ;; without it being closed over. -- WHN 2001-09-29 -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |