February 2010 - gsll-devel - mailman3.common-lisp.net

[Gsll-devel] iterate form evaluates but does not load into sbcl fasl
by Mirko Vukovic 08 Feb '10

08 Feb '10

Hello, (I apologize for the wide email distribution. There is a small probability the issue described here is due to a mismatch between iterate or sbcl). The package gsd <http://repo.or.cz/w/gsd.git>, part of gsll<http://common-lisp.net/project/gsll/>uses iterate to loop over elements of vectors and matrices. I have attached the part of the package that extends iterate to this email. I am having the following issue on sbcl1.034 on RHEL5 64-bit linux, via slime. The following form evaluates OK at the REPL. (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float* ) (print c)) But, if I embed it into a function: (defun foo () (iter:iter (iter:for c :matrix-row grid::*array-3-4-double-float*) (print c))) it will evaluate OK in slime (C-x C-e), but will not compile (C-c C-c). The returned error is: >>> post-processing/xpdp-post-processing.lisp:75:3: error: Objects of type FUNCTION can't be dumped into fasl files. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN ==> #<FUNCTION (LAMBDA #) {1002DD7AD9}> note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {1002DD7AD9}>) ... more stuff >>> So, it seems that sbcl can digest it, but for some reason cannot write it to a fasl. The macroexpansion of the code above is: (LET* ((#:SEQUENCE120 NIL) (#:LIMIT121 NIL) (C NIL) (#:INDEX119 NIL)) (BLOCK NIL (TAGBODY (PROGN (SETQ #:SEQUENCE120 GRID::*ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT121 (FUNCALL # #:SEQUENCE120)) (SETQ #:INDEX119 -1)) LOOP-TOP-NIL (PROGN (SETQ #:INDEX119 (+ #:INDEX119 1)) (IF (>= #:INDEX119 #:LIMIT121) (GO LOOP-END-NIL)) (SETQ C (FUNCALL # #:SEQUENCE120 #:INDEX119)) (PRINT C)) (PROGN) (GO LOOP-TOP-NIL) LOOP-END-NIL (PROGN)) NIL)) Is this issue due to a malformed extension of iterate, or some misalignment between iterate and sbcl? Thank you, Mirko

1 0

[Gsll-devel] bug in grid/iterate?
by Mirko Vukovic 08 Feb '10

08 Feb '10

Apologies for cross posting, but I am not sure where this problem belongs (iterage or gsll). I use slime (updated a few days ago) on sbcl 1.031 on linux. I have problems compiling the following file: >>> (in-package :grid) (defun foo () (iter:iter (iter:for e :Matrix-row grid::*array-3-4-double-float*) (princ e) (princ " "))) <<< (the code is from the iterate.lisp file of the distribution) Now in slime, I have problems. Evaluation works: I can do C-x C-e to compile `foo' I can also do C-M-x But compilation does not. Both C-c C-c and C-c C-k will flag a compiler error: note: The first argument never returns a value. --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE ==> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {10030285A9}>) Same story in raw sbcl. I looked at the iterate.lisp source code and see nothing obvious. But, I am not sure what to make of the following: If I macro-expand the above code (iter:iter ... (iter:for ... :matrix-row ...(...))) I get the following expansion. The puzzling thing is thta the first argument to `funcall' is a single hash character `#': (let* ((#:sequence208 nil) (#:limit209 nil) (e nil) (#:index207 nil)) (block nil (tagbody (progn (setq #:sequence208 *array-3-4-double-float*) (setq #:limit209 (funcall # #:sequence208)) ;; <----- (setq #:index207 -1)) loop-top-nil (progn (setq #:index207 (+ #:index207 1)) (if (>= #:index207 #:limit209) (go loop-end-nil)) (setq e (funcall # #:sequence208 #:index207)) ;; <----- (princ e) (princ " ")) (progn) (go loop-top-nil) loop-end-nil (progn)) nil)) Instead of the single hash mark, I would have expected the :access-fn and :size-fn `lambda's from the (defclause-sequence matrix-row matrix-row-index ...) in iterate.lisp. So, lots of puzzles. Not sure where this bug belongs: iterate or grid? Thanks, Mirko

2 2

[Gsll-devel] GSLL on CCL
by Leo 07 Feb '10

07 Feb '10

Hello, When I run (make-multi-dimensional-root-solver-f +powells-hybrid+ 3 #m(0 0 0)), CCL enters debug mode with the following msg on the terminal it runs in. ? Unhandled exception 10 at 0x0, context->regs at #xb0e30b1c Exception occurred while executing foreign code ? for help [57048] Clozure CL kernel debugger: More debug info are attached. Any idea how to fix this? I am running Clozure Common Lisp Version 1.4-r13357M (DarwinX8632). Thanks. Leo

2 2

[Gsll-devel] Bug? Conflict between grid & gsll: iterate.lisp present in both systems
by Mirko Vukovic 07 Feb '10

07 Feb '10

The latest versions of gsd and gsll both contain a file iterate.lisp gsll's iterate.lisp will cause grid's iterate macros to fail on cl-arrays as it uses c-array:dim0 and c-array:dim1 The iteration on cl-arrays problem is resolved if on recompiles grid's iterate.lisp after loading gsll. Mirko

2 1

[Gsll-devel] grid tranpose & diagonal compatibility with marray's
by Mirko Vukovic 07 Feb '10

07 Feb '10

I am converting some of my code to use grid. The following is on clisp & cygwin (my sbcl & linux is behind a firewall, so it takes a bit for me to transfer stuff to them) It seems that while `transpose' can handle both arrays and marrays, diagonal can handle only arrays. I traced the execution to `make-specification' in specification.lisp: SYSTEM::LIST-ACCESS: NIL is not a pair. GSL> #m(1 2 3 ^ 4 5 6 ^ 7 8 9) #<MATRIX-DOUBLE-FLOAT #2A((1.0d0 2.0d0 3.0d0) (4.0d0 5.0d0 6.0d0) (7.0d0 8.0d0 9.0d0))> GSL> (grid:transpose #m(1 2 3 ^ 4 5 6 ^ 7 8 9)) #<MATRIX-DOUBLE-FLOAT #2A((1.0d0 4.0d0 7.0d0) (2.0d0 5.0d0 8.0d0) (3.0d0 6.0d0 9.0d0))> GSL> (grid:diagonal #m(1 2 3 ^ 4 5 6 ^ 7 8 9)) ; Evaluation aborted. GSL> (grid:transpose (cl-array #m(1 2 3 ^ 4 5 6 ^ 7 8 9))) #2A((1.0d0 4.0d0 7.0d0) (2.0d0 5.0d0 8.0d0) (3.0d0 6.0d0 9.0d0)) GSL> (grid:diagonal (cl-array #m(1 2 3 ^ 4 5 6 ^ 7 8 9))) #(1.0d0 5.0d0 9.0d0) GSL> FWIW, in the test suite (tests/compose.lisp), the diagonal tests are on arrays, and not marrays. Thanks, Mirko

2 2

[Gsll-devel] How to install grid to use the iterate feature?
by Mirko Vukovic 07 Feb '10

07 Feb '10

On my slime+sbcl, I have to explicitly asdf-load `alexandria' and `iterate' before `grid', in order for the `iteration' feature to be included. Is that the intended behavior? Thanks, Mirko

2 1