Menu
▾
▴
matlisp-users
|
From: Nicolas N. <ne...@ma...> - 2008-12-10 13:38:39
|
Hello,
I have troubles with interfacing to Fortran using Allegro and I think that
maybe the experience of the people here might help me with this problem.
The following code using SBCL works fine and returns sqrt(10).
(sb-alien:load-shared-object #p"/usr/lib/libblas.so")
(SB-ALIEN:DEFINE-ALIEN-ROUTINE "dnrm2_" SB-ALIEN:DOUBLE
(N SB-ALIEN:INT :COPY)
(X (* SB-ALIEN:DOUBLE) :IN)
(INCX SB-ALIEN:INT :COPY))
(dnrm2- 10 (sb-sys:vector-sap
(make-array 10 :element-type 'double-float
:initial-element 1.0d0))
1)
works fine. But when I try the same thing with Allegro (ACL 8.1, trial
edition), I get:
CL-USER(1): (cl:load #p"/usr/lib/libblas.so")
(foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
((n :int) (x (:array :double)) (incx :int))
:convention :fortran
:returning :double)
(dnrm2- 10 (make-array 10 :element-type 'double-float :initial-element 1.0d0) 1)
; Foreign loading /usr/lib/libblas.so.
T
CL-USER(2): CL-USER(2): DNRM2-
CL-USER(3): CL-USER(3): Error: Attempt to do an array operation on -269087380 which is not an
array.
[condition type: TYPE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart).
1: Abort entirely from this (lisp) process.
[1] CL-USER(4): :bt
Evaluation stack:
DNRM2- <-
EVAL <- TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <-
TPL:START-INTERACTIVE-TOP-LEVEL
[1] CL-USER(5): :local
Interpreted lexical environment:
INCX: 1
X: #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
N: 10
Compiled lexical environment:
0(REQUIRED): N: 10
1(REQUIRED): X:
#(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
2(REQUIRED): INCX: 1
[1] CL-USER(6):
Does anyone have an idea what happens here?
Thanks, Nicolas
|
|
From: A.J. R. <bli...@gm...> - 2008-12-10 14:42:31
|
My "right answer" to the "wrong question" (that you didn't ask). If you don't mind the potential overhead of CFFI, take a look at the cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages (concepts and code) for Fortran linking with CFFI. On Wed, Dec 10, 2008 at 2:20 PM, Nicolas Neuss <ne...@ma...> wrote: > Hello, > > I have troubles with interfacing to Fortran using Allegro and I think that > maybe the experience of the people here might help me with this problem. > > The following code using SBCL works fine and returns sqrt(10). > > (sb-alien:load-shared-object #p"/usr/lib/libblas.so") > (SB-ALIEN:DEFINE-ALIEN-ROUTINE "dnrm2_" SB-ALIEN:DOUBLE > (N SB-ALIEN:INT :COPY) > (X (* SB-ALIEN:DOUBLE) :IN) > (INCX SB-ALIEN:INT :COPY)) > > (dnrm2- 10 (sb-sys:vector-sap > (make-array 10 :element-type 'double-float > :initial-element 1.0d0)) > 1) > > works fine. But when I try the same thing with Allegro (ACL 8.1, trial > edition), I get: > > CL-USER(1): (cl:load #p"/usr/lib/libblas.so") > > (foreign-functions:def-foreign-call (dnrm2- "dnrm2_") > ((n :int) (x (:array :double)) (incx :int)) > :convention :fortran > :returning :double) > > (dnrm2- 10 (make-array 10 :element-type 'double-float :initial-element 1.0d0) 1) > > ; Foreign loading /usr/lib/libblas.so. > T > CL-USER(2): CL-USER(2): DNRM2- > CL-USER(3): CL-USER(3): Error: Attempt to do an array operation on -269087380 which is not an > array. > [condition type: TYPE-ERROR] > > Restart actions (select using :continue): > 0: Return to Top Level (an "abort" restart). > 1: Abort entirely from this (lisp) process. > [1] CL-USER(4): :bt > Evaluation stack: > > DNRM2- <- > EVAL <- TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <- > TPL:START-INTERACTIVE-TOP-LEVEL > > [1] CL-USER(5): :local > Interpreted lexical environment: > INCX: 1 > X: #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0) > N: 10 > Compiled lexical environment: > 0(REQUIRED): N: 10 > 1(REQUIRED): X: > #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0) > 2(REQUIRED): INCX: 1 > [1] CL-USER(6): > > Does anyone have an idea what happens here? > > Thanks, Nicolas > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matlisp-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlisp-users > -- best, -tony bli...@gm... Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). Drink Coffee: Do stupid things faster with more energy! |
|
From: Raymond T. <ray...@er...> - 2008-12-10 16:29:06
|
>>>>> "AJ" == A J Rossini <A.J.> writes:
AJ> My "right answer" to the "wrong question" (that you didn't ask).
AJ> If you don't mind the potential overhead of CFFI, take a look at the
AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
AJ> (concepts and code) for Fortran linking with CFFI.
On my list of things to do is replacing the existing FFI in matlisp
with a new version that calls CFFI instead.
And, I think, for the the existing supported Lisps, CFFI has no
additional overhead. And then matlisp will be automagically support
more lisps than sbcl, cmucl, and Allegro.
I can't really debug the Allegro issue since I don't have Allegro.
Will the free Allegro version compile enough of matlisp for me to test
it?
Ray
|
|
From: Nicolas N. <ne...@ma...> - 2008-12-10 16:55:22
|
Raymond Toy <ray...@er...> writes: > I can't really debug the Allegro issue since I don't have Allegro. > Will the free Allegro version compile enough of matlisp for me to test > it? > > Ray I think, yes, because it should be sufficient to compile only blas.lisp. At least that worked for me. But I've found the problem already - see my other post. Nicolas |
|
From: A.J. R. <bli...@gm...> - 2008-12-10 22:31:36
|
I have some code which goes part way towards that (using the cl-blapack links to BLAS and LAPACK, which are auto-generated and use CFFI), but got seduced by lisp-matrix's duality for either lisp-centric or foriegn-centric storage. So much for getting sold on hype. On the other hand, it's been a fun project (as per another post, you can see the lisp-matrix/cl-blapack work I'm doing at github, and I probably should return by matlisp hacks back there for posterity, though unfortunately not for reuse, I'm just not that good at lisp right now...). On Wed, Dec 10, 2008 at 5:28 PM, Raymond Toy <ray...@er...> wrote: >>>>>> "AJ" == A J Rossini <A.J.> writes: > > AJ> My "right answer" to the "wrong question" (that you didn't ask). > AJ> If you don't mind the potential overhead of CFFI, take a look at the > AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages > AJ> (concepts and code) for Fortran linking with CFFI. > > On my list of things to do is replacing the existing FFI in matlisp > with a new version that calls CFFI instead. > > And, I think, for the the existing supported Lisps, CFFI has no > additional overhead. And then matlisp will be automagically support > more lisps than sbcl, cmucl, and Allegro. > > I can't really debug the Allegro issue since I don't have Allegro. > Will the free Allegro version compile enough of matlisp for me to test > it? > > Ray > -- best, -tony bli...@gm... Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). Drink Coffee: Do stupid things faster with more energy! |
|
From: Nicolas N. <ne...@ma...> - 2008-12-10 16:59:59
|
Comparing with Matlisp, I have found my bug.
Nicolas Neuss <ne...@ma...> writes:
> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
"dnrm2" is correct
> ((n :int) (x (:array :double)) (incx :int))
> :convention :fortran
> :returning :double)
To make sure I understand this correctly: dnrm2_ is probably a routine
suitable for calling from C (passing arrays as a pointer to values) while
Allegro with convention :fortran passes arrays pointing to values-1 as is
suitable for the Fortran "dnrm2".
Is this correct?
Thanks, Nicolas
|
|
From: Raymond T. <ray...@er...> - 2008-12-10 17:21:21
|
>>>>> "Nicolas" == Nicolas Neuss <ne...@ma...> writes:
Nicolas> Comparing with Matlisp, I have found my bug.
Nicolas> Nicolas Neuss <ne...@ma...> writes:
>> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
Nicolas> "dnrm2" is correct
>> ((n :int) (x (:array :double)) (incx :int))
>> :convention :fortran
>> :returning :double)
Nicolas> To make sure I understand this correctly: dnrm2_ is probably a routine
Nicolas> suitable for calling from C (passing arrays as a pointer to values) while
Nicolas> Allegro with convention :fortran passes arrays pointing to values-1 as is
Nicolas> suitable for the Fortran "dnrm2".
I don't know what the :fortran convention means, but your explanation
sounds plausible. It seems a little odd to me. For n and incx, I can
see the :fortran convention to mean pass the address of the location
of n and incx to the routine, since that's what Fortran does
(everything is pass by reference). Arrays are a bit trickier. I
don't see why you want to pass the address of x-1 instead of just x.
After all, Fortran x(1) is the first element of the array, however
that array might be arranged in memory.
Ray
|
|
From: Nicolas N. <ne...@ma...> - 2008-12-10 17:00:44
|
"A.J. Rossini" <bli...@gm...> writes: > My "right answer" to the "wrong question" (that you didn't ask). > > If you don't mind the potential overhead of CFFI, take a look at the > cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages > (concepts and code) for Fortran linking with CFFI. OK, thanks for the pointer. I will have a look. Nicolas |
|
From: Nicolas N. <ne...@ma...> - 2008-12-10 17:20:01
|
Nicolas Neuss <ne...@ma...> writes: > "A.J. Rossini" <bli...@gm...> writes: > >> My "right answer" to the "wrong question" (that you didn't ask). >> >> If you don't mind the potential overhead of CFFI, take a look at the >> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages >> (concepts and code) for Fortran linking with CFFI. > > OK, thanks for the pointer. I will have a look. > > Nicolas Stupid question: How can I get those (cl-blapack, lisp-matrix)? Are there homepages or official download sites for those projects? Thanks, Nicolas |
|
From: A.J. R. <bli...@gm...> - 2008-12-10 22:16:40
|
Unofficial site for cl-blapack and lisp-matrix (if you can "git") is On Wed, Dec 10, 2008 at 6:19 PM, Nicolas Neuss <ne...@ma...> wrote: > Nicolas Neuss <ne...@ma...> writes: > >> "A.J. Rossini" <bli...@gm...> writes: >> >>> My "right answer" to the "wrong question" (that you didn't ask). >>> >>> If you don't mind the potential overhead of CFFI, take a look at the >>> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages >>> (concepts and code) for Fortran linking with CFFI. >> >> OK, thanks for the pointer. I will have a look. >> >> Nicolas > > Stupid question: How can I get those (cl-blapack, lisp-matrix)? Are there > homepages or official download sites for those projects? > > Thanks, Nicolas > -- best, -tony bli...@gm... Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). Drink Coffee: Do stupid things faster with more energy! |
Thanks for helping keep SourceForge clean.
X