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
Mirko,
This appears to be a bug in iterate, or maybe an iterate misuse in grid. I am told that the "#" means print level exceeded. The real error is that the iterate macroexpansion is inserting a function directly in the output. SBCL will accept that "live" but won't write a FASL that way. It isn't interpreted vs. compiled, because SBCL always compiles unless you go out of your way to get it to interpret. The error is: "Objects of type FUNCTION can't be dumped into fasl files."
In CCL, I get the expansion
(macroexpand '(iter:iter (iter:for e :matrix-row *array-3-4-double-float*) (princ e) (princ " "))) (LET* ((#:SEQUENCE8 NIL) (#:LIMIT9 NIL) (E NIL) (#:INDEX7 NIL)) (BLOCK NIL (TAGBODY (SETQ #:SEQUENCE8 *ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT9 (FUNCALL #<Compiled-function (:INTERNAL
ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global) #x30004154224F> #:SEQUENCE8)) (SETQ #:INDEX7 -1) LOOP-TOP-NIL (SETQ #:INDEX7 (+ #:INDEX7 1)) (IF (>= #:INDEX7 #:LIMIT9) (GO LOOP-END-NIL)) (SETQ E (FUNCALL #<Compiled-function (:INTERNAL
ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global) #x30004154283F> #:SEQUENCE8 #:INDEX7)) (PRINC E) (PRINC " ") (GO LOOP-TOP-NIL) LOOP-END-NIL) NIL)) This pretty clearly shows that it is producing a function, not an S-expression as you see, but this is all in the iterate code.
Did you cross-post to the iterate list? I don't belong to that list so maybe you can pass the information on to them and see if the have a suggestion.
Liam
On Fri, Jan 29, 2010 at 3:38 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
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
I will cross-post to the iterate mailing list. Stay tuned ...
On Sun, Feb 7, 2010 at 6:21 PM, Liam Healy lhealy@common-lisp.net wrote:
Mirko,
This appears to be a bug in iterate, or maybe an iterate misuse in grid. I am told that the "#" means print level exceeded. The real error is that the iterate macroexpansion is inserting a function directly in the output. SBCL will accept that "live" but won't write a FASL that way. It isn't interpreted vs. compiled, because SBCL always compiles unless you go out of your way to get it to interpret. The error is: "Objects of type FUNCTION can't be dumped into fasl files."
In CCL, I get the expansion
(macroexpand '(iter:iter (iter:for e :matrix-row *array-3-4-double-float*) (princ e) (princ " "))) (LET* ((#:SEQUENCE8 NIL) (#:LIMIT9 NIL) (E NIL) (#:INDEX7 NIL)) (BLOCK NIL (TAGBODY (SETQ #:SEQUENCE8 *ARRAY-3-4-DOUBLE-FLOAT*) (SETQ #:LIMIT9 (FUNCALL #<Compiled-function (:INTERNAL
ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global) #x30004154224F> #:SEQUENCE8)) (SETQ #:INDEX7 -1) LOOP-TOP-NIL (SETQ #:INDEX7 (+ #:INDEX7 1)) (IF (>= #:INDEX7 #:LIMIT9) (GO LOOP-END-NIL)) (SETQ E (FUNCALL #<Compiled-function (:INTERNAL
ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global) #x30004154283F> #:SEQUENCE8 #:INDEX7)) (PRINC E) (PRINC " ") (GO LOOP-TOP-NIL) LOOP-END-NIL) NIL)) This pretty clearly shows that it is producing a function, not an S-expression as you see, but this is all in the iterate code.
Did you cross-post to the iterate list? I don't belong to that list so maybe you can pass the information on to them and see if the have a suggestion.
Liam
On Fri, Jan 29, 2010 at 3:38 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
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