Luís Oliveira wrote: > On 2006-maj-20, at 15:37, Lou Vanek wrote: > >> +++ cffi/src/early-types.lisp 2006-05-20 08:47:59.708847000 -0400 >> @@ -266,7 +266,10 @@ >> >> (defmethod canonicalize ((type foreign-type-alias)) >> "Return the built-in type keyword for TYPE." >> - (canonicalize (actual-type type))) >> + (let ((atype (actual-type type))) >> + (if (null atype) >> + (format *standard-error* "WARNING! null base-type.") >> + (canonicalize atype)))) > > > > I'll probably put an (assert (not (null (actual-type type)))) there instead.
I don't think you want an assert here. There is one instance when you actually want this to be null (temporarily). The uffi-array-type class initially does not specify an actual-type until it's "initialize-instance :after" method, so I think canonicalize needs to allow null actual-types, at least until after all of the constructors have finished running. (Canonicalize is called prior to "initialize-instance :after" is invoked.) As a possible work-around, you may want to give uffi-array-type a temporary actual-type until the real actual-type is set. > >> diff -urN --exclude '*.lib' --exclude '*.fas' --exclude files >> cffi.clean/src/utils.lisp cffi/src/utils.lisp >> --- cffi.clean/src/utils.lisp 2006-05-20 08:35:15.130722000 -0400 >> +++ cffi/src/utils.lisp 2006-05-20 09:06:14.990097000 -0400 >> @@ -39,7 +39,8 @@ >> #:let-when >> #:bif >> #:post-incf >> - #:single-bit-p)) >> + #:single-bit-p >> + #:getenv)) > > > > Hmmm why are you moving GETENV into the cffi-utils package? (Hmm, maybe this package should be renamed to cffi-internal-utils). After reviewing my clsql code I think I changed the getenv call in clsql.asd. Yeah, you're right, this getenv move isn't necessary for stock clsql code. > >> +++ cffi/uffi-compat/uffi-compat.lisp 2006-05-20 09:06:27.255722000 -0400 >> @@ -90,7 +90,6 @@ >> #:foreign-library-types >> >> ;; os >> - #:getenv >> #:run-shell-command >> )) > > > > And why are you removing it from uffi-compat? It's part of UFFI 1.5.7 (at least). See above. > >> @@ -135,7 +134,7 @@ >> (:documentation "UFFI's :array type.")) >> >> (defmethod initialize-instance :after ((self uffi-array-type) &key) >> - (setf (cffi::actual-type self) (cffi::find-type :pointer))) >> + (setf (cffi::actual-type self) (cffi::parse-type :pointer))) > > > > Ah ha! Now there's the bug. Well spotted. Thanks. :-) Your welcome. > >> @@ -143,7 +142,7 @@ >> (defmethod cffi::aggregatep ((type uffi-array-type)) >> t) >> >> -(cffi::define-type-spec-parser uffi-array (element-type count) >> +(cffi::define-type-spec-parser uffi-array (element-type &optional count) >> (make-instance 'uffi-array-type :element-type element-type >> :nelems (or count 1))) > > > > What's the rationale behind this change? I'm guessing it has something to do with def-array-pointer, but I think there's more to it. > This change was necessary for those times when you don't know how large the array is going to be. Specifically, for this line in mysql-api.lisp: (uffi:def-array-pointer mysql-row (* :unsigned-char)) Otherwise, since "count" is unknown, lisp will stop with an error because the lamba list takes two arguments (element-type and count) but only element-type is known. >> --- cffi.clean/uffi.asd 1969-12-31 19:00:00.000000000 -0500 >> +++ cffi/uffi.asd 2006-05-20 09:15:36.990097000 -0400 >> @@ -0,0 +1,7 @@ >> +;;;-*- Mode: Lisp; Package: COMMON-LISP-USER -*- >> + >> +(defpackage :asdf-uffi (:use #:asdf #:cl)) >> +(in-package :asdf-uffi) >> +(defsystem uffi :depends-on (:cffi-uffi-compat)) >> + >> +;;; End file uffi.asd > > > > A couple of people have suggested this. I don't think cffi's root directory is a good place for this. Any suggestions? Perhaps inside uffi-compat or a new contrib directoy? It doesn't make any difference to me as long as it isn't buried. I like the idea of putting in in uffi-compat since I would notice it there because that's one of the first places I would look for it. But I would mention this in the README, as well. _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel