I am attached to clisp on windows for some unfathomable reason - for me it has been very robust (I use sbcl on linux)
However, I will stop reporting clisp related issues unless I convince myself that they are related to ansi-spec conformance and portability. On Wed, Dec 25, 2013 at 8:14 PM, Liam Healy <lhe...@common-lisp.net> wrote: > My fix (as opposed to your fix) to the problem you reported in your > previous email should not exhibit this problem, see my previous email. A > better summary is CLISP is not a preferred platform for anything. There is > a Windows port of SBCL, and has been for quite some time. A better > cross-check on portability would be CCL. > > Liam > > > On Fri, Jan 4, 2013 at 11:47 AM, Mirko Vukovic <mirko.vuko...@gmail.com>wrote: > >> This is a follow up on my posted fix to copy-to. For some reason this >> has triggered another >> error. I do not understand how that other error is triggered. The error >> and the fix are discussed >> at the bottom of the email >> >> On Fri, Jan 4, 2013 at 10:39 AM, Mirko Vukovic >> <mirko.vuko...@gmail.com>wrote: >> >>> The following works in sbcl+grid: >>> >>> (copy-to (make-array 2 :element-type 'double-float :initial-contents >>> '(1.0d0 2.0d0)) 'grid:foreign-array) >>> >>> But it does not work in clisp+grid. >>> >>> The root cause lies in the function grid/array.lisp/element-type. It >>> uses `(array-element-type grid)'. >>> >>> But this can present a problem. Quoting hyperspec: >>> >>> (Because of *array* <http://26_glo_a.htm#array> *upgrading*, this *type >>> specifier* <http://26_glo_t.htm#type_specifier> can in some cases >>> denote a *supertype* <http://26_glo_s.htm#supertype> of the *expressed >>> array element type* <http://26_glo_e.htm#expressed_array_element_type>of the >>> *array*.) >>> >>> In CLISP, array-element-type returns `T' when passed #(1d0 2d0) >>> >>> It returns T even when passed a simple array: >>> >>> (array-element-type (make-array 2 :element-type 'double-float >>> :initial-contents >>> '(1.0d0 2.0d0) >>> :adjustable nil >>> :fill-pointer nil >>> :displaced-to nil) ) >>> >>> The proposed fix is >>> >>> (defmethod element-type ((grid array)) >>> (type-of (row-major-aref grid 0)) >>> #+skip(array-element-type grid)) >>> >>> Now copy-to works in clisp as well. >>> >>> Mirko >>> >>> >>> After finishing this, I recompiled afresh, and got another error that I >> traced to make-grid-data and make-array >> >> In clisp, make-array will return an array of NIL's even if the >> element-type is specified as double float. In SBCL make-array >> will return an array filled with 1d0. >> >> I had to add some clisp specific code to make-grid-data in order for it >> to initialize properly. >> >> First, a helper function: >> (defun default-element (element-type) >> "Return a default element depending on element-type >> " >> (let ((a-list '((double-float . 1d0) >> (symbol . T)))) >> (let ((match (cdr (assoc element-type a-list)))) >> (assert match () >> "Default element type undefined for element-type ~a" >> element-type) >> match))) >> >> And second, a bit of set-up code in make-grid-data. I broke apart the >> (let* statement >> to provide an explicit initial element if it has not been specified >> already: >> >> (defmethod make-grid-data >> ((type (eql 'array)) dimensions rest-spec >> &key (initial-element nil initial-element-p) >> (initial-contents nil initial-contents-p)) >> (let ((element-type (top-spec-type rest-spec))) >> #+clisp >> (unless (or initial-element-p >> initial-contents-p) >> (setf initial-element (default-element element-type) >> initial-element-p t)) >> (let ((array ... UNCHANGED >> >> >> Summary: To fix to copy-to, I modified (defmethod element-type ((grid >> array)) >> For some unknown reason, that triggered an error in the array >> initialization routine. >> To fix that, I had to add code to make-grid-data, so that it fills >> double-float arrays with 0d0 >> instead of NIL's >> >> I will continue using this code to see if there are additional problems. >> >> BTW, I realize that CLISP is not a preferred platform for speedy >> computation, but that is what I use >> on Windows, until SBCL gets officially ported to it. And in addition, it >> is a nice cross-check on portability. >> >> Mirko >> >> >> >> _______________________________________________ >> GSLL-devel mailing list >> GSLL-devel@common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> >> >
