[elephant-devel] Elephant 0.6.0 SQL fix on OpenMCL 1.0

[George Khouri]

Ian,

>I've had continuous problems with MCL's type specs.  Do you have any
>idea how and why MCL treats them differently?  I never use MCL so don't
>have a good sense of what standards to use to generate code that works
>under MCL.  This specific problem might be fixed by setting the type to
>(or null integer).

The short of it seems that openMCL chooses to be strict in assigning a slot value when that slot's type is specified in the class definition, where e.g., SBCL either doesn't check or doesn't care.
OpenMCL constructs a type-predicate test when defining a class and it apples that test before assigning a slot value (c.f. source code for %set-std-slot-vector-value in l1-clos-boot.lisp). If the value doesn't meet the type spec, it errors. So in the sql-cursor case it's approximately:
 ...
(if (typep new-val 'integer)
    (setf (%svref slot-vector loc) new-val)
    (error 'bad-slot-type
      ...)) ...

SBCL lets you assign any type to a typed slot:

This is SBCL 0.9.18, an implementation of ANSI Common Lisp. ...
* (defclass foo ()
   ((slot-one :accessor slot-one :initform -1 :type integer)))
#<STANDARD-CLASS FOO>
* (defparameter my-class (make-instance 'foo))
MY-CLASS
* (slot-one my-class)
-1
* (setf (slot-one my-class) nil)
NIL
* (setf (slot-one my-class) "bar")
"bar"
*

The Hyperspec Sec. 7.5.3:
"The contents of a slot will always be of type (and T1 ... Tn) where T1 ...Tn are the values of the :type slot options contained in all of the slot specifiers ... The consequences of attempting to store in a slot a value that does not satisfy the type of the slot are undefined."

>This specific problem might be fixed by setting the type to
>(or null integer).

That works in openMCL.

>
>I'm back hacking on Elephant for a few days so this is a good time to
>chase any remaining issues to ground.  Did you get the 0.6.0, BDB 4.3
>and MCL working together?

Yes, in openMCL 1.0, the test suites all pass.

OpenMCL is well on its way to the 1.1 release.  I think the serializer will have to be modified to work with the new release, in which character and stream handling have been reworked to handle unicode.  I can send along the release notes if you like. Here's the symptom in 1.1 pre-release 061024 with either elephant 6.0/db4.3 or elephant cvs/db4.4 (the ^@'s are unprintables):
CL-USER> (ele:open-store '(:bdb "/Users/gkhouri/db/"))
#<SLEEPYCAT::BDB-STORE-CONTROLLER #x88D894E>
CL-USER> (ELE:add-to-root "my key" "my Val")
"my Val"
CL-USER> (ele:get-from-root "my key")
"^@^@^@m^@^@"
T

Thanks,
George

>
>Ian
>


>George Khouri wrote:
>> Friends,
>> Testing  Elephant 0.6.0 against a postgres db, in OpenMCL 1.0, I found that 
>the close-cursor method fails since it tries to set the value of the sql-cursor 
>slot "curkey" to NIL, while its type spec in the class declaration is INTEGER.  
>Perhaps other lisps allow this.  
>> If I change close-cursor to set curkey to -1 as below, the tests run fine.  I 
>don't know if there are other routines which check for a null value in that 
>cursor slot, in which case my change wouldn't work. Perhaps the type spec should 
>be removed from the slot declaration instead?
>>
>> The code is in elephant/src/db-clsql/sql-collections.lisp.
>>
>> (defclass sql-cursor (cursor)
>>   ((keys :accessor :sql-crsr-ks :initarg :sql-cursor-keys :initform '())
>>    (curkey :accessor :sql-crsr-ck :initarg :sql-cursor-curkey :initform -1 
>:type integer))
>>   (:documentation "A SQL cursor for traversing (primary) BTrees."))
>>
>> ...
>>
>> (defmethod cursor-close ((cursor sql-cursor))
>>   #-openmcl
>>   (setf (:sql-crsr-ck cursor) nil)
>>   #+openmcl 
>>   (setf (:sql-crsr-ck cursor) -1)  ; ** GK  
>>   (setf (cursor-initialized-p cursor) nil))
>>
>> Thanks,
>> George
>> --------
>> George Khouri
>> gk1 at four-four.com
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>