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
On Wed, Dec 10, 2008 at 5:28 PM, Raymond Toy <raymond.toy@...> 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
"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!