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") >> "[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@" >> 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 >>>> [EMAIL PROTECTED] >>>> _______________________________________________ >>>> elephant-devel site list >>>> elephant-devel@common-lisp.net >>>> http://common-lisp.net/mailman/listinfo/elephant-devel >>>> >>>> _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
