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

Liam Healy lhealy at common-lisp.net
Sun May 23 14:28:29 UTC 2010 

Fixed by making set-position non-destructive (list copied).

On Tue, May 4, 2010 at 12:54 PM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> On Tue, May 4, 2010 at 10:31 AM, Sumant Oemrawsingh <soemraws at xs4all.nl> wrote:
>> Thanks!
>>
>> I haven't looked at all into any of gsd's internals, so I don't know: could
>> this be considered a permanent fix, or is it a hack until the underlying
>> problem (if any) is resolved?
>>
>> S
>
> That is up to the grand wizard himself :-)
>
>
>>
>> On Tue, May 04, 2010 at 10:12:00AM -0400, Mirko Vukovic wrote:
>>> I neglected to say that `set-position' is grid's gsd/grid/util.lisp file.
>>>
>>> On Tue, May 4, 2010 at 10:00 AM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
>>> > 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
>>> >>
>>> >
>>>
>>> _______________________________________________
>>> Gsll-devel mailing list
>>> Gsll-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>>>
>>
>> --
>> Sumant Oemrawsingh
>>
>> _______________________________________________
>> Gsll-devel mailing list
>> Gsll-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>>
>
> _______________________________________________
> 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