gsll-devel

gsll-devel@common-lisp.net

246 discussions

[Gsll-devel] Problem with building gsll
by Jorge Tavares 28 Aug '09

28 Aug '09

Hello, I am having some problems in building GSLL on my system. I've decided to install it using clbuild, with sbcl 1.0.30 on a Mac OS X 10.5.8. I've installed GSL through macports (1.12) and it's working (compile some basic examples). I've also checked for the last versions of all the required libraries, specifically CFFI. However, every time I try to load GSLL it always gives the error pasted at the end of this message. I think it is related to the fact that it can't find the header files for GSL. If I directly compile a C file, I need to indicate the correct path: -I/opt/local/include -L/opt/local/lib. I have the impression that this is somehow missing on the automated build process of gsll but I am not sure where/how to correct it. Or it's simply an easy mistake on my part or something very obvious that I am missing... If someone could provide me some hints in how to install, build and use correctly gsll I would be very grateful. Best wishes, Jorge Output with the error messages: ; /Users/jast/devel/lisp/clbuild/source/gsll/init/init.fasl written ; compilation finished in 0:00:00.006 ; cc -m32 -I/Users/jast/devel/lisp/clbuild/source/cffi/ -fPIC -o / Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix /Users/jast/ devel/lisp/clbuild/source/gsll/init/libgsl-unix.c External process exited with code 1. Command was: "cc" "-m32" "-I/Users/jast/devel/lisp/clbuild/source/ cffi/" "-fPIC" "-o" "/Users/jast/devel/lisp/clbuild/source/gsll/init/ li..." "/Users/jast/devel/lisp/clbuild/source/gsll/init/li..." Output was: /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:6:33: error: gsl/gsl_integration.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:7:27: error: gsl/gsl_eigen.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:8:27: error: gsl/gsl_cblas.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:9:27: error: gsl/gsl_odeiv.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:10:32: error: gsl/gsl_ieee_utils.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:11:26: error: gsl/gsl_mode.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:12:27: error: gsl/gsl_errno.h: No such file or directory /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c: In function 'main': /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:29: error: 'GSL_INTEG_COSINE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:29: error: (Each undeclared identifier is reported only once /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:29: error: for each function it appears in.) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:34: error: 'GSL_INTEG_SINE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:45: error: 'GSL_INTEG_GAUSS15' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:50: error: 'GSL_INTEG_GAUSS21' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:55: error: 'GSL_INTEG_GAUSS31' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:60: error: 'GSL_INTEG_GAUSS41' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:65: error: 'GSL_INTEG_GAUSS51' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:70: error: 'GSL_INTEG_GAUSS61' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:81: error: 'GSL_EIGEN_SORT_VAL_ASC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:86: error: 'GSL_EIGEN_SORT_VAL_DESC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:91: error: 'GSL_EIGEN_SORT_ABS_ASC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:96: error: 'GSL_EIGEN_SORT_ABS_DESC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:107: error: 'CblasNoTrans' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:112: error: 'CblasTrans' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:117: error: 'CblasConjTrans' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:128: error: 'CblasUpper' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:133: error: 'CblasLower' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:144: error: 'CblasNonUnit' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:149: error: 'CblasUnit' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:160: error: 'CblasLeft' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:165: error: 'CblasRight' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:176: error: 'GSL_ODEIV_HADJ_DEC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:181: error: 'GSL_ODEIV_HADJ_NIL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:186: error: 'GSL_ODEIV_HADJ_INC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:197: error: 'GSL_IEEE_TYPE_NAN' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:202: error: 'GSL_IEEE_TYPE_INF' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:207: error: 'GSL_IEEE_TYPE_NORMAL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:212: error: 'GSL_IEEE_TYPE_DENORMAL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:217: error: 'GSL_IEEE_TYPE_ZERO' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:228: error: 'GSL_IEEE_SINGLE_PRECISION' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:233: error: 'GSL_IEEE_DOUBLE_PRECISION' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:238: error: 'GSL_IEEE_EXTENDED_PRECISION' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:249: error: 'GSL_IEEE_ROUND_TO_NEAREST' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:254: error: 'GSL_IEEE_ROUND_DOWN' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:259: error: 'GSL_IEEE_ROUND_UP' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:264: error: 'GSL_IEEE_ROUND_TO_ZERO' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:275: error: 'GSL_IEEE_MASK_INVALID' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:280: error: 'GSL_IEEE_MASK_DENORMALIZED' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:285: error: 'GSL_IEEE_MASK_DIVISION_BY_ZERO' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:290: error: 'GSL_IEEE_MASK_OVERFLOW' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:295: error: 'GSL_IEEE_MASK_UNDERFLOW' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:300: error: 'GSL_IEEE_MASK_ALL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:305: error: 'GSL_IEEE_TRAP_INEXACT' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:316: error: 'GSL_PREC_DOUBLE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:321: error: 'GSL_PREC_SINGLE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:326: error: 'GSL_PREC_APPROX' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:337: error: 'GSL_CONTINUE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:342: error: 'GSL_FAILURE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:347: error: 'GSL_SUCCESS' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:352: error: 'GSL_EDOM' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:357: error: 'GSL_ERANGE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:362: error: 'GSL_EFAULT' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:367: error: 'GSL_EINVAL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:372: error: 'GSL_EFAILED' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:377: error: 'GSL_EFACTOR' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:382: error: 'GSL_ESANITY' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:387: error: 'GSL_ENOMEM' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:392: error: 'GSL_EBADFUNC' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:397: error: 'GSL_ERUNAWAY' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:402: error: 'GSL_EMAXITER' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:407: error: 'GSL_EZERODIV' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:412: error: 'GSL_EBADTOL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:417: error: 'GSL_ETOL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:422: error: 'GSL_EUNDRFLW' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:427: error: 'GSL_EOVRFLW' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:432: error: 'GSL_ELOSS' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:437: error: 'GSL_EROUND' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:442: error: 'GSL_EBADLEN' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:447: error: 'GSL_ENOTSQR' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:452: error: 'GSL_ESING' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:457: error: 'GSL_EDIVERGE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:462: error: 'GSL_EUNSUP' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:467: error: 'GSL_EUNIMPL' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:472: error: 'GSL_ECACHE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:477: error: 'GSL_ETABLE' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:482: error: 'GSL_ENOPROG' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:487: error: 'GSL_ENOPROGJ' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:492: error: 'GSL_ETOLF' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:497: error: 'GSL_ETOLX' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:502: error: 'GSL_ETOLG' undeclared (first use in this function) /Users/jast/devel/lisp/clbuild/source/gsll/init/libgsl-unix.c:507: error: 'GSL_EOF' undeclared (first use in this function) [Condition of type SIMPLE-ERROR] Restarts: 0: [TRY-RECOMPILING] Try recompiling libgsl 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {12F3FFC9}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {12EF6CD1}>. 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {12F3FFC9}> on #<CFFI-GROVEL:GROVEL-FILE "libgsl" {12EF6CD1}> as having been successful. 3: [RETRY] Retry SLIME REPL evaluation request. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (CFFI-GROVEL::INVOKE "cc")[:EXTERNAL] 1: ((LAMBDA ())) 2: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA #) {13953B95}>) 3: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP CFFI- GROVEL:GROVEL-FILE)) ..) 4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB- PCL::.ARG1.)) ..) 5: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP CFFI- GROVEL::CC-FLAGS-MIXIN)) ..) 6: ((SB-PCL::FAST-METHOD ASDF:PERFORM ASDF:AROUND (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..) 7: ((LAMBDA ())) 8: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 9: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {13837E65}>) [:EXTERNAL] 10: (ASDF:OPERATE ASDF:LOAD-OP :GSLL)[:EXTERNAL] 11: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OPERATE 'ASDF:LOAD-OP :GSLL) #<NULL-LEXENV>) --more--

3 8

[Gsll-devel] Wrong argument names in set-minimizer-with-values function.
by Liam Healy 25 Aug '09

25 Aug '09

Thanks, I've applied the patch and added the tests. On Mon, Aug 24, 2009 at 1:45 PM, Evgeniy Zhemchugov<jini.zh(a)gmail.com> wrote: > It works fine. A patch for the testsuite is in the attachement. The > order of arguments is still different from GSL but I'm happy as long > as their names correspond to their meaning. > > Thank you for your cooperation. >

1 0

[Gsll-devel] Wrong argument names in set-minimizer-with-values function.
by Evgeniy Zhemchugov 24 Aug '09

24 Aug '09

According to GSL documentation at http://www.gnu.org/software/gsl/manual/html_node/Initializing-the-Minimizer…, gsl_min_fminimizer_set_with_values has the following signature: int gsl_min_fminimizer_set_with_values (gsl_min_fminimizer * s, gsl_function * f, double x_minimum, double f_minimum, double x_lower, double f_lower, double x_upper, double f_upper) GSLL set-fminimizer-with-values is defined as follows: (defmfun set-fminimizer-with-values (minimizer function x-minimum x-lower x-upper f-minimum f-lower f-upper) "gsl_min_fminimizer_set_with_values" (((mpointer minimizer) :pointer) (function :pointer) (x-minimum :double) (x-lower :double) (x-upper :double) (f-minimum :double) (f-lower :double) (f-upper :double)) :documentation ; FDL "Set, or reset, an existing minimizer to use the function and the initial search interval [lower, upper], with a guess for the location of the minimum, using supplied rather than computed values of the function.") Note the different order of argument names. I often use #'describe to see function argument list and this discrepancy confuses me. Please, apply the patch in the attachement. Also, can you advice me on how to create a callback for this function? The simplest solution I can come up with is the following: (cffi:defcallback test :double ((x :double) (parameters :pointer)) (1+ (cos x))) (cffi:with-foreign-object (callback 'gsl::fnstruct) (setf (cffi:foreign-slot-value callback 'gsl::fnstruct 'function) (cffi:callback test)) (let ((minimizer (gsl:make-one-dimensional-minimizer gsl:+brent-fminimizer+))) (gsl:set-fminimizer-with-values minimizer callback ...) ...)) But I don't like that the fnstruct symbol is not exported. What is the supposed way? It would be nice to be able to provide ordinary Lisp function as callback for set-fminimizer-with-values instead of foreign pointer to gsl_function. I do understand why it is difficult to make though. Maybe you should use gsl_min_fminimizer_set_with_values instead of gsl_min_fminimizer_set as is suggested by the comment in the definition of one-dimensional-minimizer. GSL uses the latter function as conventional interface for the former. In Lisp this can be handled better via key arguments.

2 2

[Gsll-devel] Best way to concatenate matrices?
by Malcolm Reynolds 19 Aug '09

19 Aug '09

Hi I'm wondering what the preferred way of concatenating matrices vertically is with GSLL? I can't seem to find any references to any built-in function which does this, and what seems like the best way using C gsl: http://www.mail-archive.com/help-gsl@gnu.org/msg00233.html requires gsl_matrix_submatrix, which doesn't seem to be included in gsll. Obviously it's not hard to write a pair of loops for this task in general, but I was wondering if there was a smart way already that I have missed? Cheers, Malcolm

2 1

[Gsll-devel] Execution errors?
by Jason Nielsen 16 Aug '09

16 Aug '09

Hi Liam, I've just updated to the latest version of gsll and am getting execution errors that I do not recall getting previously when running the test suite (it has been however a bit of time since I git pulled). Here is the result: TOTAL: 1483 assertions passed, 1 failed, 9 execution errors. the execution errors are all of the form: SCALE: Unhandled memory fault at #x1B3BA55C. VECTOR-SET-ALL: Unhandled memory fault at #xA7C1C475. etc. I'm not sure if this is cause for concern as it doesn't seem to change the results of my code... but memory fault warnings give make me a little uncomfortable! I'm running Ubuntu 8.10 on an x86-64 machine with sbcl 1.30. Cheers, Jason

2 2

[Gsll-devel] cffi-grovel
by Jim 16 Aug '09

16 Aug '09

Hello everyone, This is my first post to this list. I've just installed gsll and I'm very much looking forward to using it for numeric programming in Common Lisp. Thanks in advance for gsll! However, I can't seem to get it going. I'm somewhat new to Common Lisp, and very new to asdf. And I find that much Common Lisp documentation attempts to be so general that it is mostly useful for people who already know the answers. I suspect I am missing something very simple, and has nothing to do with gsll so much as setting up packages in Common Lisp. Nevertheless, I'm not sure whom to ask. I'm running SBCL with SLIME under Ubuntu 8.10. I followed the gsll installation instructions under "With Debian or Ubuntu", and had no apparent errors. I started SLIME and entered "(asdf:operate 'asdf:load-op :gsll)" and obtained the error "component "cffi-grovel" not found". It appears that I do have cffi, and all the information I can find about cffi-grovel indicates that it is now integrated with cffi. So I can't add a package but I can't seem to use what I have. What should I do? Once again, please keep in mind that I am just a beginner regarding asdf and cffi. Thank you! Jim Garrett Baltimore, Maryland, USA

5 5

[Gsll-devel] loading/compiling error: destructuring bind in mksa
by Mirko Vukovic 13 Jul '09

13 Jul '09

Hello, Here is an error report while loading the latest gsll (with all fasl's removed) on a 64-bit linux with sbcl: error while parsing arguments to DESTRUCTURING-BIND: unknown keyword: :TYPE; expected one of :OPTIONAL, :DOCUMENTATION [Condition of type SB-KERNEL::DEFMACRO-LAMBDA-LIST-BROKEN-KEY-LIST-ERROR] Restarts: 0: [TRY-RECOMPILING] Try recompiling mksa 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {1005EEFEF1}> on #<CFFI-GROVEL:GROVEL-FILE "mksa" {10069A0561}>. 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {1005EEFEF1}> on #<CFFI-GROVEL:GROVEL-FILE "mksa" {10069A0561}> as having been successful. 3: [RETRY] Retry SLIME REPL evaluation request. 4: [ABORT] Return to SLIME's top level. 5: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ((SB-PCL::FAST-METHOD CFFI-GROVEL::%PROCESS-GROVEL-FORM ((EQL 'CFFI-GROVEL::CONSTANT) T T)) ..) 1: (CFFI-GROVEL::GENERATE-C-FILE ..) 2: (CFFI-GROVEL:PROCESS-GROVEL-FILE ..) 3: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP CFFI-GROVEL:GROVEL-FILE)) ..) 4: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) ..) 5: ((SB-PCL::FAST-METHOD ASDF:PERFORM :AROUND (ASDF:COMPILE-OP CFFI-GROVEL::CC-FLAGS-MIXIN)) ..) 6: ((SB-PCL::FAST-METHOD ASDF:PERFORM ASDF:AROUND (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..) 7: ((LAMBDA ())) 8: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK)) 9: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {1002DB71C9}>)[:EXTERNAL] 10: (ASDF:OPERATE ASDF:LOAD-OP "gsll")[:EXTERNAL] 11: ((LAMBDA (FUNCTION)) #<CLOSURE (LAMBDA #) {10046565D9}>) 12: ((LAMBDA ())) It seems that I can safely skip this file (option 2). I looked in the physical constants directory, and could not find anything meaningful to me. Cheers, Mirko

2 1

[Gsll-devel] Common approach to scientific/mathematical/engineering software
by Liam Healy 06 Jul '09

06 Jul '09

I'm changing the subject line here... On Sat, Jul 4, 2009 at 3:50 PM, A.J. Rossini<blindglobe(a)gmail.com> wrote: > On Sat, Jun 27, 2009 at 7:23 PM, Liam Healy<lhealy(a)common-lisp.net> wrote: > >> On another subject, I notice you have been doing a lot of work on Lisp >> interfaces to other science/engineering/math libraries, like R. My >> intent in building GSLL was that it would become part of a collection >> of systems that would have consistent use and interchange of data >> between different libraries. So for example, you would be able to >> make an object representing an array, call a GSLL function, then pass >> the resulting array to R. There are a lot of aspects of this problem, >> but I'm thinking about array standardization as a start. Do you have >> any thoughts on this? > > The RCLG package has some stuff in the right direction (Rif wrote it, > I'm maintaining it). RCL and CLSR, 2 others, have respectively, > better lispy interfaces and some better internals (roundtrip and > better object mapping). I'd look at Cyrus Harmon's CLSR as a start, > as much as I'd love to have you contribute to RCLG. My idea at this point was less to contribute to a specific project than it was to try to find a common approach to dealing with e.g. arrays and similar structures. However, discussions can only go so far without actual code, so the specific projects are important. It would take me a long time to crack the R packages to see how they deal with arrays (I haven't used them) than it would be to describe what I did with GSLL in this regard and let others who know better about other packages see what common elements are there. > > We ought to be able to seemlessly use R's S4 object systems right out > of CL, it's just CLOS reinvented poorly (so have to add some bugs to > get the proper mapping, but sigh, you get the point). Interesting. I hadn't heard about S4. It seems like that might be a major task to integrate with CLOS. But, do people really need that? My goal isn't so much to re-implement another programming language but to make library functions available in CL. I realize that it's not easy to divide something R up like that. > > So yes, I've got lots of thoughts on this, but I'm not nearly a good > enough lisp programmer to make enough progress on what I want to do, > and I need to get a few working pieces before heading back to > integration. > > And BTW, I am working to see about using GSLL as a feasible backend > for the lisp-matrix stuff, as you've done a fine job on the overall > system development and internals, as well as for some of the other > numerical stuff -- however, it would be great to have a robust and > consistent front end to many different numerical libraries for testing > numerical stability and comparability. > > All this just to be able to wrap a sensible statistical DSL directly > on top of CL, keeping all of CL around, so that I can once and for all > forget about R's annoying syntax burps. > > (I do like R, having been responsible for many user-level innovations > and demonstrations with it, but it truly sucks as a platform for > statistical computing research; it's great for just "computing > statistical stuff"). > > Let me know if there is anything I can do to help out (I don't have > much time, but it'll help me in the long run). > > best, > -tony I think not much time is a common problem for all of us. I will be essentially without network access starting next week through mid-August, so I can't do anything until at least then. But at some point after that I will write something short on how GSLL deals with arrays, why I did it that way, and what I would like to see added. Perhaps that will spur a discussion of these ideas. In the meantime, Tom Hermann has been thinking about some of these issues. I think he is now subscribed to this mailing list, but just in case I have cc'ed him here. I don't know what the release state of his work is, but when he feels comfortable with it he can post it somewhere for discussion. Thanks for your feedback. Liam

3 2

[Gsll-devel] Build error (fsbv)
by Jason Nielsen 04 Jul '09

04 Jul '09

Hello all, I just git pulled all the new goodness in gsll, fsbv etc. but am getting error messages building fsbv: ; /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/init.fasl written ; compilation finished in 0:00:00.004 ; cc -m64 -fPIC -o /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "initial thread" RUNNING {10029DDD71}>: External process exited with code 1. Command was: "cc" "-m64" "-fPIC" "-o" "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix" "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c" Output was: "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 7: cannot find include file: <ffi.h> "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 40: undefined symbol: FFI_OK "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 45: undefined symbol: FFI_BAD_TYPEDEF "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 50: undefined symbol: FFI_BAD_ABI "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 61: undefined symbol: FFI_DEFAULT_ABI "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 66: undefined symbol: FFI_SYSV "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 71: undefined symbol: FFI_UNIX64 "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 79: undefined symbol: ffi_abi "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 126: incomplete struct/union/enum _ffi_type: sizeof() "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 131: undefined struct/union member: size "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 136: undefined struct/union member: alignment "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 141: undefined struct/union member: type "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 146: undefined struct/union member: elements "/var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c", line 397: warning: implicit function declaration: memset cc: acomp failed for /var/cache/common-lisp-controller/1000/sbcl/local/home/jdn/work/lisp/fsbv/libffi-unix.c I have cffi 0.10.5 installed and its test suite passes. I also have libffi-dev installed in the usual place so I'm a bit confused. Cheers, Jason

4 8

Re: [Gsll-devel] Build problems
by Liam Healy 25 Jun '09

25 Jun '09

On Wed, Jun 24, 2009 at 2:52 PM, Zach<elzacho(a)gmail.com> wrote: > > > On Tue, Jun 23, 2009 at 8:05 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: > >> Simply put, CFFI-grovel doesn't "think to look" anywhere, it looks >> where the application author (me, in the case of GSLL) tells it. > > I think that maybe it (CFFI-grovel) should. I'll try to justify this at the > end. > >> >> I >> put the #+darwin conditional in libffi-unix.lisp based on a Mac-using >> colleague's report that he found ffi.h in ffi/ffi.h (sorry I don't >> know the full path). That clause works for him. I understand that >> people can install from Darwin ports, fink, etc., but libffi in >> particular is an Apple standard library so I used the location Apple >> seems to use. > > That is weird. Is this something new in, maybe in 10.5? I want to emphasize: I have utterly no idea. All I know is my colleague claims he didn't install libffi from anywhere, it seemed to be there in his Mac by itself, so I inferred that to mean OS X itself put it there (it is a common package used by many things like python etc., so I figured they automatically include it in OS X). The change I made allowed him to run just fine. So I literally have a sample space of 1. I'd like a Mac expert to take up the reins here so that we'll have a larger sample space. > > smithzv@belial:[0]:~/$ locate ffi/ffi.h > > This is from MacPorts (they changed there name a while back). Yup, I knew that but forgot it. This is proof of my lack of Mac expertise :-). > > smithzv@belial:[0]:~/$ ls /opt/local/include/ffi.h > /opt/local/include/ffi.h > >> >> So I'm going to rely on your Mac expertise here (because I have none) > > Neither do I really, just GNU/Linux experience that I am trying to use on OS > X. Then I think until a Mac expert steps up and enlightens us with the Mac Way to solve this, I think I'll leave my code as it is. > >> >> but can you answer the questions I asked of Jason? (modified suitably >> for OS X). What was the path you gave it? Why isn't ffi.h in the >> Apple-defined place? etc. You say in your other message "...I have >> for a long time had to do this for any system that uses cffi-grovel, >> since I often have libraries in only somewhat standard places under OS >> X." > > >> >> If they are in different places because of the semi-standard >> install (e.g. Darwin ports), arguably we should have that in GSLL. > > I am leaving all of my package managed files in the default directories that > the package managers use. For MacPorts that is /opt/local, and for Fink > that is /sw. I would say that these are absolutely standard places for > people who use MacPorts and Fink. I will say that if you want to build > software outside of these package managers, basically no one looks there by > default. If you want to support builds for people using MacPorts or Fink, > you could have the user push an appropriate symbol onto *FEATURES* and use > something like... > > (cffi-grovel:grovel-file .... #+(or gsll:macports gsll:darwinports > gsll:fink) :cc-flags #+(or macports darwinports)"-I/opt/local/include" > #+fink"-I/sw/include") I'm unclear on who/what put gsll:macports onto *features*. That's not anything I do, nor could I. Therefore I couldn't put it into my source code. > > For FSBV, unfortunately, it seems that sometimes ffi is in a path like > ffi/ffi.h, which means that a simple include flag will not work, instead you > may have to do something like > > #+(and gsll:darwin (not (or gsll:macports gsll:darwinports))) (include > "ffi/ffi.h") > #+(or (not darwin) (and gsll:darwin (or gsll:macports gsll:darwinports))) > (include "ffi.h") > > Not sure about fink here, since I use Macports for ffi. Sorry for typos, I > am typing this straight into the email. Macports and fink typically use > Linux like locations (i.e. they are not going to put a header in an extra > subdirectory since it would break many packages). > >> If on the other hand you have a unique organization, you're going to have >> to make your own modifications to each system. I don't know of a way >> to supply a list of possibilities to search in cffi-grovel, but even >> if that's possible, I'd only make use of it for semi-standard >> locations. > > > Right. So if I am building a C library like GSL, I typically define a build > environment. This includes a location of where header files are found and > where libraries are found. These locations are not carried in the source of > the program because, quite frankly, it isn't the responsibility of the > developer to know what loopy places a user might put his/her files. But > since every build system I know of that handles C like builds (GNU > autotools, CMake, SCons, whatever that thing is you use on OS X) allows you > to specify the location of headers and libraries, I am allowed to build > packages without keeping my own set of patches to someone else's source > tree. Quite often these locations are by default read from environment > variables like CFLAGS and LDFLAGS. > > It makes sense to me that this shouldn't happen at the GSLL level. I think > I am more sure of that now. CFFI deals with libraries, like a linker, and > it offers a special variable CFFI:*FOREIGN-LIBRARY-DIRECTORIES* that acts a > lot like the environment variable LDFLAGS. Since CFFI-grovel deals with > (primarily) header files, should offer such a analog for the environment > variable CFLAGS. There is a variable CFFI-GROVEL:*CC-FLAGS* but any value > it is bound to is thrown away prior to grovelling (it also can only specify > only one token). I could set these in my user init file and be done with > it. > > Doesn't this sound like a better solution for people who install libraries > in their home space, or have a package manager that isn't integrated with > the OS like me? You move that responsibility off of your shoulders and onto > the people who should know what is happening in there system, the users. > > If this sounds good, I will bring it up with Luis, > Zach There are two separate issues here, somewhat related: 1) Can/should CFFI-grovel search a list in much the same way that libraries are searched? 2) What location(s) might the Mac install (official or semi-standard) the header files? As far as 1 goes, I think it would be a good idea and I think you should bring it up on the CFFI mailing list. As far as 2 goes, we need a Mac expert. In fact, the merger of the two issues might be not just that a list can be provided but that if running on a Mac, then *all* the standard and semi-standard locations are searched without explicit reference to the paths. And of course this would be done with all OSes. I think that this is the case with libraries; there is some statement to the effect that system libraries are searched in standard places, so no special system knowledge is required. This could be expanded to headers too. Since this must be a larger issue than FSBV/GSLL, I think it really should be brought up with the CFFI list; there is more likely to be a Mac expert who can step up and provide the search list in general. Liam

2 1

← Newer
1
...
14
15
16
17
18
19
20
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel