[Gsll-devel] grid:row and grid:column error when used in sequence on the same marray
Hi, 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 -- Sumant Oemrawsingh
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
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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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@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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
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@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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
-- Sumant Oemrawsingh
On Tue, May 4, 2010 at 10:31 AM, Sumant Oemrawsingh <soemraws@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@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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
-- Sumant Oemrawsingh
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
Fixed by making set-position non-destructive (list copied). On Tue, May 4, 2010 at 12:54 PM, Mirko Vukovic <mirko.vukovic@gmail.com> wrote:
On Tue, May 4, 2010 at 10:31 AM, Sumant Oemrawsingh <soemraws@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@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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
-- Sumant Oemrawsingh
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
_______________________________________________ Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
participants (3)
-
Liam Healy -
Mirko Vukovic -
Sumant Oemrawsingh