[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 16:54:21 UTC 2010
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
>
More information about the gsll-devel
mailing list