When attempting to load squirl with asdf in SBCL, an error is raised upon compilation of src/collision.lisp.
The error occurs when compiling the function segment-to-poly, and the error text is:
Searching through the SBCL code, this seems to be a floating point error.
Looking through the squirl code, the error occurs in line 134 of collision.lisp, after calling contact's constructor, make-contact, with an optional hash argument.
make-contact is declaimed inline elsewhere and this compile-time optimisation seems to be the main suspect for the error.
The error can be stopped by:
1. In src/contact.lisp, define a new constructor for the contact struct, called e.g. make-contact2, with the same arguments as make-contact, but not inline.
2. Change src/collision.lisp's segment-to-poly function to use this new constructor.
Git diffs showing the changes:
diff --git a/src/contact.lisp b/src/contact.lisp
index af9e49b..12bd333 100644
@@ -2,7 +2,8 @@
(declaim (inline make-contact))
-(defstruct (contact (:constructor make-contact (point normal distance &optional hash)))
+(defstruct (contact (:constructor make-contact (point normal distance &optional hash))
+ (:constructor make-contact2 (point normal distance &optional hash)))
;; Contact point and normal
(point +zero-vector+ :type vec)
(normal +zero-vector+ :type vec)
diff --git a/src/collision.lisp b/src/collision.lisp
index c2b7082..3877888 100644
@@ -131,7 +131,7 @@
(vec* poly-normal (segment-radius segment)))))
(flet ((try-vertex (vertex i)
(when (poly-contains-vertex-p poly vertex)
- (push (make-contact vertex poly-normal poly-min
+ (push (make-contact2 vertex poly-normal poly-min
(hash-pair (shape-id segment) i))
(try-vertex vertex-a 0)
This may slow down the code for non-SBCL implementations of CL, however, so I haven't submitted it as a patch.
If this is indeed an error introduced by an optimization SBCL does, then it's important that this be brought instead to the attention of the SBCL maintainers themselves so that it might be fixed there and not manifest elsewhere.
I thought this was already fixed by nyef in recent SBCL versions. Try the most recent one sans patch?
I'll report that using 1.0.51 (released Aug 21, 2011) I am still getting low-level SBCL errors regarding make-contact. Presumably this is post patch. These are not identical but I suspect that they are very similar as they involve the same inlined constructor and the above work around resolves the issue.
The error text is:
# is not valid as the second argument to VOP:
Primitive type: T
The primitive type disallows these loadable SCs:
If we think this is a different issue I can open a new one. Or maybe we can discuss a good test case to submit to the sbcl-devel.
Reproduced using SBCL 1.0.57
Cheap hack... commit 25fbbe2 disables the inlining on SBCL
Quick hack for SBCL