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

[George Khouri]

Ian,
OpenMCL 1.1-pre-061110  release excerpt:
"About 15-20 character encoding schemes are defined (so far); these
  include UTF-8/16/32 and the big-endian/little-endian variants of
  the latter two and ISO-8859-* 8-bit encodings. "
Unicode support is now "built-in." but only starting with the 1.1 pre-releases. Unfortunelately, there isn't a  *feature* indicatiing unicode support.  The only *features* changing from 1.0 to 1.1 are the "lack of" the :ccl-x" features (:CCL :CCL-2 :CCL-3 :CCL-4) and a few others, so you would have to do something like:
#+(and openmcl (not ccl)) ...(ugh!)
I'll be glad to do any testing on openMCL.
George

>Unicode support should be an easy fix; we've already patched it for SBCL
>and ACL unicode.  Is there a *feature* in MCL that indicates whether
>string types are unicode or not?  Also, what encoding does MCL use? 
>(UTF-8, UTF-16, etc)
>
>Ian
>
>George Khouri wrote:
>> 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
>>>>   
>>>>