gsll-devel April 2008

gsll-devel@common-lisp.net

4 participants
4 discussions

[Gsll-devel] What is needed to fix matrix views?
by Zach 12 Apr '08

12 Apr '08

Liam et. al., OK, tell me if I am wrong. Matrix/vector views are not supported in GSLL. This is due to the fact that we need to recieve a structure by value. This cannot be done due to a weakness of the underlying CFFI. Which in turn (according to their mailing list) is actually a weakness of most Lisp implementations. In order to get this to work there is some C language glue that needs to be written. Is this a correct assessment of the situation? Zach

3 12

Re: [Gsll-devel] What is needed to fix matrix views?
by Liam Healy 11 Apr '08

11 Apr '08

On Thu, Apr 10, 2008 at 12:31 PM, Zach <elzacho(a)gmail.com> wrote: > > So, here is what I don't get: How can (aref mat i j) equal > gsl_matrix_get(mat, i, j) even if mat is somehow the same object? The > functions gsl_matrix_get and aref possibly do two very different things. > Perhaps they do the same thing in SBCL, in which case everything about FFAs > would make sense until someone writes another format for > matrices/vectors/etc. In SBCL (and CMUCL too), there is a function vector-sap which gives the C pointer of a simple array with a declared type. This can be passed to a C program when in a with-pinned-objects macro (to prevent garbage collection while C is working on it). Tamas has some definitions to allow multidimensional arrays, copying etc. I'm pretty sure they won't rewrite the format for arrays to break compatibility with C access, but if they do the fallback is what is done for all non-SBCL implementations now: copying. > > > If we forget about all of the structure slots and go down to the underlying > 1D array that represents matrices we have this. > > gsl_matrix_get(mat, i, j) = mat->data[i * mat->tda + j] > > tda here does not, in general, equal the width of the actual data. I'm not sure what you mean here, but if GSL is happy with the data stored as a standard C array at the heart of it all, then the SBCL vector-sap should do just fine. The trick is to not have GSL do the allocation of that array. It must be allocated by SBCL and in the SBCL address area, and then passed on to GSL. So routines like gsl_vector_alloc are not used anymore. I am manually creating a GSL block (using CFFI) and putting this pointer in it, then using GSL's gsl_vector_alloc_from_block. Liam

1 0

Re: [Gsll-devel] DEFCVAR error
by Tamas K Papp 01 Apr '08

01 Apr '08

Thanks Liam, I overlooked that, and I installed the latest version. Now I get the error: * (require :gsll) ; loading system definition from /usr/share/common-lisp/systems/cffi.asd into ; #<PACKAGE "ASDF0"> ; registering #<SYSTEM CFFI {B0B0CC9}> as CFFI debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" {A8EF661}>: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION (SB-PCL::SLOT-ACCESSOR :GLOBAL CFFI::SPEC SB-PCL::READER) (1)> when called with arguments (((:DARWIN (:OR "/opt/local/lib/libgslcblas.dylib" "/usr/local/lib/libgslcblas.dylib")) (:UNIX (:OR "/usr/lib/libgslcblas.so.0" "/usr/lib/libgslcblas.so")) (T (:DEFAULT "libgslcblas")))). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Try loading the foreign library again. 1: [USE-VALUE] Use another library instead. 2: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {B82B479}> on #<ASDF:CL-SOURCE-FILE "init" {B6881B1}>. 3: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {B82B479}> on #<ASDF:CL-SOURCE-FILE "init" {B6881B1}> as having been successful. 4: [ABORT ] Exit debugger, returning to top level. ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION (SB-PCL::SLOT-ACCESSOR :GLOBAL CFFI::SPEC SB-PCL::READER) (1)>) 0] Note that I installed libgsl0-dev which apparently contains libgslcblas (this was not mentioned on the GSLL page), but still could not get it working. Using SBCL 1.0.14.debian. Tamas On Tue, Apr 01, 2008 at 11:46:40AM -0400, Liam Healy wrote: > Hi Tamas- > > You need to get the latest version (not the current) version of CFFI. > There are actually only three places where this is used, so it's not > hard to change it, but I coded against the latest version figuring > they were about to release a new version (and so far they haven't), > and because one of my computers is on Debian unstable and uses the > latest. > > Liam > > > Requirements and Platforms > > GSLL should work in any Common Lisp implementation and platform > combination that has CFFI with callbacks and foreign-funcall support. > You will need > > * GSL > * CFFI (Note: you will need a version newer than the current > version 0.9.2. Use the darcs repository, a newer tarball, or Debian > testing/unstable.) > * ASDF ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > On Tue, Apr 1, 2008 at 10:27 AM, Tamas K Papp <tpapp(a)princeton.edu> wrote: > > Hi, > > > > I checked out GSLL using svn, registered the package and tried to load > > it. But I am getting errors like this: > > > > Execution of a form compiled with errors. > > Form: > > (DEFCVAR (gsl_version *GSL-VERSION* READ-ONLY T) STRING > > The version of the GSL library being used.) > > Compile-time error: > > (during macroexpansion of (DEFCVAR ("gsl_version" *GSL-VERSION* ...) ...)) > > error while parsing arguments to DEFMACRO DEFCVAR: > > odd number of elements in keyword/value list: ("The version of the GSL library being used.") > > [Condition of type SB-INT:COMPILED-PROGRAM-ERROR] > > > > When I looked up cffi:defcvar, I found that its syntax is > > (defcvar name type &key read-only) > > > > but the code has > > > > (cffi:defcvar ("gsl_version" *gsl-version* :read-only t) :string > > "The version of the GSL library being used.") > > > > I am confused, am I supposed to use a different version of CFFI? > > > > Thanks, > > > > Tamas > > _______________________________________________ > > Gsll-devel mailing list > > Gsll-devel(a)common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel > >

3 4

[Gsll-devel] DEFCVAR error
by Tamas K Papp 01 Apr '08

01 Apr '08

Hi, I checked out GSLL using svn, registered the package and tried to load it. But I am getting errors like this: Execution of a form compiled with errors. Form: (DEFCVAR (gsl_version *GSL-VERSION* READ-ONLY T) STRING The version of the GSL library being used.) Compile-time error: (during macroexpansion of (DEFCVAR ("gsl_version" *GSL-VERSION* ...) ...)) error while parsing arguments to DEFMACRO DEFCVAR: odd number of elements in keyword/value list: ("The version of the GSL library being used.") [Condition of type SB-INT:COMPILED-PROGRAM-ERROR] When I looked up cffi:defcvar, I found that its syntax is (defcvar name type &key read-only) but the code has (cffi:defcvar ("gsl_version" *gsl-version* :read-only t) :string "The version of the GSL library being used.") I am confused, am I supposed to use a different version of CFFI? Thanks, Tamas

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel April 2008