[Gsll-devel] grid:row and grid:column error when used in sequence on the same marray

Mirko Vukovic mirko.vukovic at gmail.com
Tue May 4 14:00:08 UTC 2010


Here is a more succinct example of the same problem:

GSL> (defparameter *data* (make-marray 'double-float :dimensions '(2 2)
				       :initial-contents '((1 2) (3 4))))
*DATA*
GSL> (dimensions *data*)
(2 2)
GSL> (grid:row *data* 0)
#<VECTOR-DOUBLE-FLOAT #(1.0d0 2.0d0)>
GSL> (dimensions *data*)
(1 2)
GSL>

And here is the fix:

After the call to `grid:row', dimensions returns incorrect values.
So, a call to grid:row corrupts a data descriptor.

grid:row eventually invokes a call to a utility function
`set-positions' which setf's a place in a list.  This is where the
corruption occurs.

I uglified `set-position' so that it operates on a list's copy:
(defun set-position (list position value)
  "Set the element at position to the value, and return the list."
  (let ((copy (copy-list list)))
    (setf (nth position copy) value)
    copy))

(this function needs to be renamed and re-documented)

This modification fixes the problem.

I've been bitten once before by this `action at the distance' of setf.
 I thought I was going crazy for quite some time before I figured out
what was going on.

Mirko


On Tue, May 4, 2010 at 7:28 AM, Sumant Oemrawsingh <soemraws at xs4all.nl> wrote:
> Sorry for the typos in the previous e-mail; I was typing it from memory,
> without paying too much attention to detail (bad, I know).  Below is an actual
> SBCL session.
>
> -Sumant
>
> ---START---
>
> * (require :gsll)
>
> ; loading system definition from /usr/share/common-lisp/systems/cffi-grovel.asd
> ; into #<PACKAGE "ASDF2">
> ; registering #<SYSTEM CFFI-GROVEL {10035FEE21}> as CFFI-GROVEL
> ; loading system definition from /usr/share/common-lisp/systems/alexandria.asd
> ; into #<PACKAGE "ASDF2">
> ; registering #<SYSTEM :ALEXANDRIA {1002D20101}> as ALEXANDRIA
> ; loading system definition from /usr/share/common-lisp/systems/cffi.asd into
> ; #<PACKAGE "ASDF2">
> ; registering #<SYSTEM CFFI {10032F20A1}> as CFFI
> ; loading system definition from /usr/share/common-lisp/systems/babel.asd into
> ; #<PACKAGE "ASDF2">
> ; registering #<SYSTEM BABEL {10035DC9B1}> as BABEL
> ; loading system definition from
> ; /usr/share/common-lisp/systems/trivial-features.asd into #<PACKAGE "ASDF2">
> ; registering #<SYSTEM TRIVIAL-FEATURES {1002C48101}> as TRIVIAL-FEATURES
> ; loading system definition from
> ; /usr/share/common-lisp/systems/cl-utilities.asd into #<PACKAGE "ASDF0">
> ; registering #<SYSTEM CL-UTILITIES {10035EB831}> as CL-UTILITIES
> ; loading system definition from
> ; /usr/share/common-lisp/systems/trivial-garbage.asd into #<PACKAGE "ASDF0">
> ; registering #<SYSTEM TRIVIAL-GARBAGE {10031C11B1}> as TRIVIAL-GARBAGE
> ; registering #<SYSTEM TRIVIAL-GARBAGE-TESTS {1003481DF1}> as
> ; TRIVIAL-GARBAGE-TESTS
> ; loading system definition from /home/soemraws/.sbcl/systems/grid.asd into
> ; #<PACKAGE "ASDF0">
> ; registering #<SYSTEM GRID {1003741ED1}> as GRID
> ; loading system definition from /home/soemraws/.sbcl/systems/c-array.asd into
> ; #<PACKAGE "ASDF0">
> ; registering #<SYSTEM C-ARRAY {1003A56591}> as C-ARRAY
> ("SB-ROTATE-BYTE")
> * (defparameter *data* (gsll:make-marray 'double-float :dimensions '(2 2) :initial-contents '((1 2) (3 4))))
>
> *DATA*
> * (grid:row *data* 0)
>
> #<GSLL:VECTOR-DOUBLE-FLOAT #(1.0d0 2.0d0)>
> * (grid:row *data* 1)
>
> #<GSLL:VECTOR-DOUBLE-FLOAT #(3.0d0 4.0d0)>
> * (grid:column *data* 0)
>
> debugger invoked on a GSLL:INVALID-ARGUMENT in thread #<THREAD
>                                                        "initial thread" RUNNING
>                                                        {1002ACB011}>:
>  Invalid argument; vector length n must be positive integer in init_source.c at line 90
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>  0: [ABORT] Exit debugger, returning to top level.
>
> (GSLL::SIGNAL-GSL-ERROR
>  4
>  "vector length n must be positive integer"
>  "init_source.c"
>  90)
> 0] 0
>
> * (defparameter *data* (gsll:make-marray 'double-float :dimensions '(2 2) :initial-contents '((1 2) (3 4))))
>
> *DATA*
> * (grid:column *data* 0)
>
> #<GSLL:VECTOR-DOUBLE-FLOAT #(1.0d0 3.0d0)>
> * (grid:column *data* 1)
>
> #<GSLL:VECTOR-DOUBLE-FLOAT #(2.0d0 4.0d0)>
> * (grid:row *data* 0)
>
> debugger invoked on a GSLL:INVALID-ARGUMENT in thread #<THREAD
>                                                        "initial thread" RUNNING
>                                                        {1002ACB011}>:
>  Invalid argument; vector length n must be positive integer in init_source.c at line 90
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>  0: [ABORT] Exit debugger, returning to top level.
>
> (GSLL::SIGNAL-GSL-ERROR
>  4
>  "vector length n must be positive integer"
>  "init_source.c"
>  90)
> 0] 0
>
> *
>
> ----END----
>
>
>
> On Tue, May 04, 2010 at 12:04:00PM +0200, Sumant Oemrawsingh wrote:
>
>> Lately, I've been playing around a bit with GSL and slicing etc using GSD. I
>> found that grid:row and grid:column don't work as expected:
>>
>> (defparameter *data*
>>   (make-marray double-float :inital-contents '((1 2) (3 4)))
>>
>> ; vector (1,3), works fine
>> (grid:column *data* 0)
>>
>> ; vector (2,4), works fine
>> (grid:column *data* 1)
>>
>> ; Errors
>> (grid:row *data* 0)
>> ; Invalid argument; vector length n must be positive integer in init_source.c at line 90
>>
>> ; Same error
>> (grid:row *data* 1)
>> ; Invalid argument; vector length n must be positive integer in init_source.c at line 90
>>
>> Now, if I rerun the defparameter, and run the grid:row functions first, they
>> succeed, but the grid:column functions afterwards fail. I don't quite
>> understand, because *data* is not modified by these functions.
>>
>> At the moment, I'm too lazy^H^H^H^Hbusy to look into the source code and
>> discover the source of the problem on my own. Maybe I'm just doing it wrong,
>> though. Any help is appreciated.
>
>
> --
> Sumant Oemrawsingh
>
> _______________________________________________
> Gsll-devel mailing list
> Gsll-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>




More information about the gsll-devel mailing list