gsll-devel December 2009

gsll-devel@common-lisp.net

3 participants
4 discussions

[Gsll-devel] Introducing "Grid Structured Data"
by Liam Healy 09 Jan '10

09 Jan '10

Based on several expressed wishes for the ability to create, compose and extract array-like objects and pieces of such objects, I have introduced the "Grid Structured Data" collection at http://repo.or.cz/w/gsd.git, and rewritten GSLL to be built on top of that. The GSLL interface is the same as before, but now it is possible to do subarrays, concatenation, slices, transpose, etc. on arrays (both CL arrays and GSLL marrays). There is some documentation for gsd in gsd/documentation/grid/index.html which describes how it works. There is more work to be done, but as it is now, it provides functions that people have asked for to create and manipulate marrays. If you don't need that, you can go on as before and everything is the same. Liam

3 2

[Gsll-devel] clisp&cffi: broken foreign functions in saved images
by Sam Steingold 06 Jan '10

06 Jan '10

Hi, I do this: $ clisp -x '(asdf:operate 'asdf:load-op :gsll) (saveinitmem "gsll" :executable t)' $ ./gsll > > (gsll:make-chebyshev 1) FFI::FOREIGN-CALL-OUT: no dynamic object named "gsl_cheb_alloc" in library :DEFAULT this indicates a bug somewhere between cffi and gsll. specifically, the definition of the foreign function gsl_cheb_alloc should specify that it is to be found in "libgsl.so", not in :default. moreover, when I do the (not so) trivial thing: (ffi:default-foreign-language :stdc) (ffi:open-foreign-library "libgslcblas.so") (ffi:def-call-out gsl_cheb_alloc (:library "libgsl.so") (:arguments (n ffi:int)) (:return-type ffi:c-pointer)) (gsl_cheb_alloc 10) ;; ==> #<FOREIGN-ADDRESS #x0000000005503380> (saveinitmem "foo" :executable t) (quit) ./foo (ffi:open-foreign-library "libgslcblas.so") (gsl_cheb_alloc 10) #<FOREIGN-ADDRESS #x0000000001D9F4C0> i.e., if the foreign function definition includes the correct library name, the function will work automatically[*] even in the saved image. So, since I am not quite sure where the bug is hiding, I am reporting this to both gsll and cffi lists. Thanks. Sam. [*] apparently, libgsl.so cannot be loaded before libgslcblas.so is. how do people specify such dependencies?!

2 7

Re: [Gsll-devel] Introducing "Grid Structured Data"
by Liam Healy 29 Dec '09

29 Dec '09

The "w" link is the gitweb page, open it up in your browser and you see information about the repository, changelog summary, etc. There you will find the URL to clone, either git://repo.or.cz/gsd.git or http://repo.or.cz/r/gsd.git Let me know how it goes. Liam On Mon, Dec 28, 2009 at 2:19 AM, A.J. Rossini <blindglobe(a)gmail.com> wrote: > Liam - > > I think there is a small problem with the repo: > > $ git clone http://repo.or.cz/w/gsd.git > Initialized empty Git repository in /home/tony/sandbox/gsd/.git/ > warning: remote HEAD refers to nonexistent ref, unable to checkout. > > > ? > > On Mon, Dec 28, 2009 at 4:31 AM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> Based on several expressed wishes for the ability to create, compose >> and extract array-like objects and pieces of such objects, I have >> introduced the "Grid Structured Data" collection at >> http://repo.or.cz/w/gsd.git, and rewritten GSLL to be built on top of >> that. The GSLL interface is the same as before, but now it is >> possible to do subarrays, concatenation, slices, transpose, etc. on >> arrays (both CL arrays and GSLL marrays). There is some documentation >> for gsd in gsd/documentation/grid/index.html which describes how it >> works. There is more work to be done, but as it is now, it provides >> functions that people have asked for to create and manipulate marrays. >> If you don't need that, you can go on as before and everything is the >> same. >> >> Liam >> >> _______________________________________________ >> Gsll-devel mailing list >> Gsll-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> > > > > -- > best, > -tony > > blindglobe(a)gmail.com > 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! >

2 1

[Gsll-devel] ODE apply-step: argument passing problem
by Mirko Vukovic 03 Dec '09

03 Dec '09

Hi, I am trying to solve a second order ODE by calling a stepper for a number of fixed-size steps. I am getting an error about conversion to foreign type c-pointer. I modeled my call to `apply-step' based on `apply-evolution'. Looking at the source files, that is likely not to work because `apply-evolution' uses c-pointers, and `apply-step' makes direct variable references. But I don't know how to deal with those - my C and CFFI knowledge are non-existent. Anyway, here is a sample code that I hope someone can improve: ;;;; Example of a simple time-stepper (defun sin-ode (time y z) "Define ODE for a sinusoid y''=-y or as a system: y'=z z'=-y with initial conditions: y0=0 z0=1 " (declare (ignore time)) (values z (- y))) (defun sin-ode-jacobian (time y z) (declare (ignore time y z)) (values 0d0 0d0 0d0 1d0 -1d0 0d0)) #| (let ((time 0d0) (delta-t 0.1d0) (stepper-type +step-rk2+)) (let ((stepper (make-ode-stepper stepper-type 2 #'sin-ode #'sin-ode-jacobian)) (dep (make-marray 'double-float :dimensions 2)) (dydt-in (make-marray 'double-float :dimensions 2)) (dydt-out (make-marray 'double-float :dimensions 2)) (yerr (make-marray 'double-float :dimensions 2))) (setf (maref dep 0) 0d0 (maref dep 1) 1d0) (dotimes (i 10) (incf time delta-t) (apply-step stepper time dep delta-t yerr dydt-in dydt-out)))) |# BTW, once this is working, I will submit it as a patch to the ode-examples.lisp file Thanks, Mirko

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel December 2009