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

[Gsll-devel] gmane.lisp.gsll
by Leo 20 Feb '10

20 Feb '10

Hello all, If you use gnus and gmane, I have requested the creation of newsgroup gmane.lisp.gsll for this mailing list. Best, Leo

2 2

[Gsll-devel] OT: foreign numeric vector library compilation on sbcl
by Mirko Vukovic 10 Feb '10

10 Feb '10

Hello This does not strictly apply to gsll, but it is not too far afield. After a several month hiatus I tried to load the `foreign-numeric-vector' library on sbcl1.034 on 64-bit linux in order to access some netlib and lapack routines (mainly the amos library for complex bessel functions). (My prior version of sbcl was 1.024) I got the following error when compiling the file `foreign-numeric-vector.lisp': >>> Unexpected offset. [Condition of type SIMPLE-ERROR] Restarts: 0: [TRY-RECOMPILING] Try recompiling foreign-numeric-vector 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {1003F6C941}> on #<ASDF:CL-SOURCE-FILE "foreign-numeric-vector" {1004056AF1}>. 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {1003F6C941}> on #<ASDF:CL-SOURCE-FILE "foreign-numeric-vector" {1004056AF1}> as having been successful. 3: [ABORT] Abort compilation. 4: [RETRY] Retry SLIME REPL evaluation request. 5: [ABORT] Return to SLIME's top level. --more-- >>> The error seems to be during the compilation of: ; compiling (MAKE-FNV-TYPED-VECTOR FLOAT ...) ; compiling (MAKE-FNV-TYPED-VECTOR DOUBLE ...) ; compiling (MAKE-FNV-TYPED-VECTOR COMPLEX-FLOAT ...) <----------------- ; compilation aborted after 0:03:00.518 ; ; compilation unit aborted ; caught 2 fatal ERROR conditions If I comment out (make-fnv-typed-vector complex-float ...) and (make-fnv-typed-vector complex-double ...), the file compiles cleanly. Unfortunately, I do need those routines. I tried this with the latest cffi. Any thoughts on what may be going on? Thanks Mirko

1 0

Re: [Gsll-devel] [iterate-devel] Fwd: iterate form evaluates but does not loadinto sbcl fasl
by Mirko Vukovic 09 Feb '10

09 Feb '10

On Tue, Feb 9, 2010 at 9:30 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Mirko, > > >Are you implying that instead of lambda forms one should define the > >functions and use function names. > No. Just look at the examples in the source code, incl. tests. > The key is to write #'(lambda ...) aka. (function (lambda ...)), not > (lambda ...) > Like this? (defclause-sequence matrix-row matrix-row-index :access-fn #'(lambda (grid index) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (grid:row grid index)) :size-fn #'(lambda (grid) (assert (and (grid:gridp grid) (eql (grid:grid-rank grid) 2)) (grid)) (first (grid:grid-dimensions grid))) :element-type t :sequence-type t :element-doc-string "(copied) rows of a matrix" :index-doc-string "index of the rows in a matrix") Unfortunately, that did not help improve things. Also, the iterate documentation has an example of `defclause-sequence' (bottom of p.26 of the pdf file). There is no #'(lambda ...), just plain (lambda ...) Thank you for your time, Mirko

2 2

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

09 Feb '10

On Mon, Feb 8, 2010 at 9:57 PM, Kalyanov Dmitry <kalyanov.dmitry(a)gmail.com>wrote: > The iterate extension is clearly wrongly written. You cannot insert non- > externalisable value into the compiled file, in this case, functions > compiled > in compilation-environment. The code should be rewritten to use defuns to > declare functions and to use symbols in defclause-sequence. > Dmitry, Yesterday was the first time I encountered this externalisation issue (see emails by Yong). So, I am still wobbly with these concepts. Are you implying that instead of lambda forms one should define the functions and use function names. For example, in the following form (defclause-sequence matrix-row matrix-row-index :access-fn (lambda (marray index) (check-type marray gsl:matrix) (gsll:row marray index)) :size-fn (lambda (marray) (check-type marray gsl:matrix) (c-array:dim0 marray)) :element-type t :sequence-type t :element-doc-string "(copied) rows of a matrix" :index-doc-string "index of the rows in a matrix") all lambda expressions need to be replaced by function symbols. Correct? FWIW, I could not reproduce my problem on clisp. Mirko

1 0

[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