[GSLL-devel] Fixing up make-grid-data for clisp (was making copy-to working in clisp+grid: fix to element-type)
Mirko Vukovic
mirko.vukovic at gmail.com
Thu Dec 26 16:23:22 UTC 2013
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 <lhealy at 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.vukovic at 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.vukovic at 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 at common-lisp.net
>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/antik-devel/attachments/20131226/d61ba58b/attachment.html>
More information about the antik-devel
mailing list