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

Sumant Oemrawsingh soemraws at xs4all.nl
Tue May 4 14:31:35 UTC 2010


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

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




More information about the gsll-devel mailing list