Custom Query (1030 matches)

When we save source information about a function defined via COMPILE-FILE, we usually save information about the source file and the character (or octet ?) range from which the defining form was read. (We can optionally save a string which matches the sequence of characters read form this range, but this adds to image size and is often redundant.)

If we don't save the string, we currently don't know (or have any way of knowing) whether the file has been modified since it was compiled to produce the current definitions. (If it has been modified, it's certainly reasonable to claim that source information associated with a definition may be inaccurate, possibly grossly so; in that case, we could either refuse to present it or present that source info with a disclaimer.)

Unfortuantely, I don't think that we track any information that'd enable us to detect modifications. Storing the modification date of the file might be at least somewhat reliable, but there are many scenarios (svn co ...) where the modification date will change but the contents would not, and this could unfortunately yield many false-positive claims of modification.)

I wonder if it's possible/practical to generate some sort of checksum for the (octets? characters?) in the range associated with a definition, and to have DISASSEMBLE (and error-reporting functions, and other things) compare this checksum to what would be obtained by reading the same sequence from the file ?

There may be a better way of doing this, but it'd be good to be able to distinguish between "source text in which we have very high confidence" and "stuff that was in the recorded file position in the relatively recent past."

the function initGlut() must be called with a pointer to a variable containing argc and a pointer to argv. Instead, it is being called with a pointer to a pointer to argv (line 45 in examples/opengl-ffi.lisp). Simplest fix is to remove the creation and initialization of argvp, and to change line 45 to read (#_glutInit argcp argv)))

Cheers, Hans-Martin

The bug is exhibited in the following test code. To run it save it to a file, load it and then evaluate the TEST-IT function. I have tested this with the binary x8664 version for 1.2-rc1.

Basically I am generating a class called BAR with 600 direct slots which derives from FOO with the BAR-GENERATOR macro. If BAR has 6 slots, then the test case works as it should.

;;; Start of test case

(in-package :cl-user)

(defclass foo ()

((foo-slot :accessor foo-slot)))

(defmacro bar-generator ()

`(defclass bar (foo)

,(loop for i from 0 to 600

for slot = (intern (format nil "BAR-SLOT-~A" i)) collect `(,slot :initform ,i))))

(bar-generator)

(defmethod initialize-instance :after ((x foo) &key)

(setf (foo-slot x) 42))

(defun test-it ()

(make-instance 'bar))

;;; End of test case