[Ecls-list] RUN-PROGRAM/FFI

Nicolas Neuss Nicolas.Neuss at iwr.uni-heidelberg.de
Wed Nov 16 06:41:01 UTC 2005


Juan Jose Garcia Ripoll <lisp at arrakis.es> writes:

> No, you also have RUN-PROGRAM, much like in CMUCL. From
> ecls/src/c/unixsys.d:
>
> @(defun ext::run-program (command argv &key (input @':stream')
> 			 (output @':stream') (error @'t'))

OK, this works nicely.

>> 2. I want to call a C function and to pass it an array.  How is that
>> done?
>>    Is there some conversion routine like VECTOR-SAP in CMUCL/SBCL?
>> Where
>>    could I find information about ECL's FFI?
>
> This is not really supported, because such pointers are unsafe. However,
> you can do it with a simple c-inline statement:
>
> 	(c-inline (my-array) (:object) :pointer-void
> 		"(#0)->array.self.char" :one-liner t)

Sorry, I do not understand.  In particular, I want to interface to SuperLU.
Thus, I have the following code:

(ffi:def-function ("c_superlu" c-superlu)
    ((m :int) (n :int) (nnz :int)
     (colptr (* :int))
     (rowind (* :int))
     (nzval (* :double))
     (nrhs :int)
     (rhs (* :double))
     (sol (* :double)))
  :returning :int)

(defun superlu (m n nnz cs ri store nrhs rhs sol)
  (c-superlu m n nnz (vector-sap cs) (vector-sap ri)
	        (vector-sap store) nrhs (vector-sap rhs)
	        (vector-sap sol)))

What can I insert for vector-sap here?  Or how should I write SUPERLU?

And a further question: How can I change the package at startup?  I have
found that the code

ecl -eval "(in-package :SI)"

does not work.  (I dimly remember reading something about this question
recently, but cannot find the mail anymore.)

Thank you,

Nicolas

P.S.: I have been bitten earlier by the fact that ECL returns LONG-FLOAT
when asked for the array-element-type of a uniform DOUBLE-FLOAT array.
This is allowed by the spec, however I think that the name DOUBLE-FLOAT is
more meaningful (relating to what is the actual length of the number).  It
is also used by Allegro and CMUCL (as much as I see only GCL uses
LONG-FLOAT).  Probably, a change would be problematic, but nevertheless I
would be interested in opinions about this issue.





More information about the ecl-devel mailing list