- gsll-devel - mailman3.common-lisp.net

[GSLL-devel] Violation of the GFDL in GSLL
by Sébastien Villemot 29 Oct '12

29 Oct '12

Hi, Thanks for writing GSLL, it is a very useful piece of software for scientists like me. Since I am also a Debian Developer, I would like to package GSLL into Debian. However a major issue needs to be solved before this can happen. The problem is that documentation strings in GSLL are copied (and possibly modified) from the GSL reference manual, which is licensed under the GNU Free Documentation License (GFDL). But GSLL is licensed under the GNU General Public License (GPL). Therefore, the portions of the GSL reference manual incorporated in the documentation strings have been de facto relicensed under the GPL, which is a violation of the GFDL (the two licenses being incompatible). As such, this make GSLL unredistributable from a legal point of view. I see only two possible solutions to this problem: 1. Ask the permission from the copyright holders of the GSL manual (i.e. the GSL Team) to incorporate parts of the GSL manual into the GSLL under the GPL. If such a permission has already been given, it should be mentioned somewhere in the GSLL source tree (I could not find it anywhere). 2. Strip from GSLL all documentation strings that incorporate material from the GSL manual. Of course, 1 would be preferable over 2. Thanks in advance for your feedback. I hope this issue can be solved, so that GSLL makes its way into Debian. Regards, -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594

1 0

[GSLL-devel] Invitation to connect on LinkedIn
by D. E. (Steve) Stevenson 19 Oct '12

19 Oct '12

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - D. E. (Steve) D. E. (Steve) Stevenson Director at Institute for Modeling and Simulation Applications, Clemson University Greenville, South Carolina Area Confirm that you know D. E. (Steve) Stevenson: https://www.linkedin.com/e/-8a34oq-h8hxokmc-3p/isd/9166890412/LiGvUD8U/?hs=… -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-8a34oq-h8hxokmc-3p/ZinPG-VgE-rKjpgcnEb9mzEQSFxBy… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

[GSLL-devel] Having trouble installing GSLL
by Steve Stevenson 17 Jun '12

17 Jun '12

The instructions on "http://common-lisp.net/project/gsll/" do not match what is loaded from quicklisp.lisp. I'm using SBCL and I see "qlqs-sbcl" as a package. What do I need to change? Thanks. -- D. E. (Steve) Stevenson (Almost emeritus) Associate Professor Director, Institute for Modeling and Simulation Applications. Clemson University steve at clemson dot edu Anyone who has ever looked into the glazed eyes of a soldier dying on the battlefield will think hard before starting a war. -Otto von Bismarck, statesman (1815-1898)

1 0

Re: [GSLL-devel] [Antik-devel] error loading gsll with quicklisp
by Liam Healy 23 Mar '12

23 Mar '12

On Thu, Mar 22, 2012 at 11:35 AM, <harven(a)free.fr> wrote: > Hi, > > As far as I understand, gsll is being merged with antik, so I am posting > here. > That is not correct, I'm not sure where you would get the idea. GSLL uses parts of Antik (which were formerly part of GSLL), but that is the extent of the relationship, now or planned. So your question is more appropriate for the GSLL-devel list, which I am copying on this reply. > I am trying to install gsll using quicklisp and I run into an error, > as reported in the attachment below. This seems to be related to > cffi-grovel, > which is installed. > > $ ls ~/.quicklisp/dists/quicklisp/software/cffi_0.10.6/grovel/asdf.lisp > common.h grovel.lisp invoke.lisp package.lisp > > CL-USER> (find-package 'cffi-grovel) > #<PACKAGE "CFFI-GROVEL"> > > I am on debian squeeze, using sbcl from the repos. I have installed > the following packages related to gsl > libgsl0-dev, libgsl0ldbl, libffi-dev, gsl-doc-info, gsl-ref-html > > I also tried to load gsll with asdf, but I run into the same error > > CL-USER> (asdf:load-system "gsll") > > Error while trying to load definition for system gsll from > pathname > > /home/harven/.quicklisp/dists/quicklisp/software/gsll-20111105-git/gsll.asd: > The variable #:CFFI-GROVEL is unbound. > [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR] > > > Any suggestion ? > That is very odd. I'm on the debian squeeze myself, and I've never seen that. However, is there a reason you are using asdf:load-system instead of ql:quickload? Try that and see what happens. Also, please join the appropriate mailing list(s) to post, otherwise, I must approve each time you send. Thank you. Liam > > Regards, > -- > Harven > > _______________________________________________ > Antik-devel mailing list > Antik-devel(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/antik-devel > >

2 2

Re: [GSLL-devel] GSLL handling lib name under CCL
by Liam Healy 19 Feb '12

19 Feb '12

Yuan, Thanks for the patch. I don't use MacOSX so I can't test it, but I've committed it. If possible, in the future please join the mailing list and post your items there. As far as your CFFI suggestions go, I encourage you to post them on the cffi-devel list; Mac users seem to have a lot of trouble with paths and anything that improves that situation should be welcome. Liam On Thu, Oct 13, 2011 at 5:46 PM, Yuan MEI <yuan.mei(a)gmail.com> wrote: > Hi Liam, > I've started using GSLL. It is wonderful! I just discovered a > glitch though, when using CCL under MacOSX, it complains that a > #P"xxx.dylib" is not accepted. I'd rather think cffi should be blamed > for not accepting a path, but I'd like to let you know that there is > this issue and here is a quick fix. Actually a better portable way > should be implemented to translate #P"" to a string that cffi could > understand, or better cffi should be modified to accept #P in any CL > implementation on any platform. > > Thanks, > > Yuan Mei > > diff --git a/init/init.lisp b/init/init.lisp > index 41ef370..e632f09 100644 > --- a/init/init.lisp > +++ b/init/init.lisp > @@ -66,7 +66,9 @@ > (merge-pathnames pn (pathname (format nil "~a/" (gsl-config > "--prefix")))))) > > (cffi:define-foreign-library libgslcblas > - (:darwin #.(gsl-config-pathname "lib/libgslcblas.dylib")) > + (:darwin #+ccl #.(ccl:native-translated-namestring > + (gsl-config-pathname "lib/libgslcblas.dylib")) > + #-ccl #.(gsl-config-pathname "lib/libgslcblas.dylib")) > (:cygwin "cyggslcblas-0.dll") > (:unix (:or "libgslcblas.so.0" "libgslcblas.so")) > (t (:default "libgslcblas"))) > @@ -80,9 +82,12 @@ > (cffi:load-foreign-library "/lib/lapack/cygblas.dll") > > (cffi:define-foreign-library libgsl > - (:darwin #. (gsl-config-pathname "lib/libgsl.dylib")) > + (:darwin #+ccl #.(ccl:native-translated-namestring > + (gsl-config-pathname "lib/libgsl.dylib")) > + #-ccl #.(gsl-config-pathname "lib/libgsl.dylib")) > (:cygwin "cyggsl-0.dll") > (:unix (:or "libgsl.so.0" "libgsl.so")) > (t (:default "libgsl"))) > > (cffi:use-foreign-library libgsl) >

2 3

[GSLL-devel] recompilation of antic upon load of gssl
by JTK 19 Feb '12

19 Feb '12

Hello I noticed that when I load gssl, antik recompiles (see below). Is this normal? I would expect it to reuse the compiled fasls. This is the quicklisp version running in SBCL 1.0.54 John cl-user> (asdf:operate 'asdf:load-op 'gsll) warning: No definition for cflag-vswtc warning: No definition for tty-iuclc warning: No definition for tty-olcuc style-warning: Implicitly creating new generic function read-sequence*. [similar things deleted] style-warning: Undefined alien: "nil" ; compiling file "/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/optimize/one-dim.lisp" (written 13 FEB 2012 06:12:50 PM): ; compiling (in-package :antik) ; compiling (export (quote #)) ; compiling (defun root-1d ...) ; compiling (defun minimize-1d ...) ; compiling (defun maximize-1d ...) ; /Volumes/data/Users/jtk/.cache/common-lisp/sbcl-1.0.54-macosx-x64/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/optimize/ASDF-TMP-one-dim.fasl written ; compilation finished in 0:00:00.023 ; compiling file "/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/linear-algebra/linear-algebra.lisp" (written 13 FEB 2012 06:12:50 PM): ; compiling (in-package :antik) ; compiling (export (quote #)) ; compiling (defmethod *i ...) ; compiling (defmethod *i ...) ; compiling (defmethod *i ...) ; compiling (defmethod /i ...) ; compiling (defmethod +i ...) ; compiling (defmethod +i ...) ; compiling (defmethod +i ...) ; compiling (defmethod -i ...) ; compiling (defmethod -i ...) ; compiling (defmethod -i ...) ; compiling (defmethod expt ...) ; compiling (defun invert-matrix ...) ; compiling (defun determinant ...) ; compiling (defun solve-linear ...) ; /Volumes/data/Users/jtk/.cache/common-lisp/sbcl-1.0.54-macosx-x64/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/linear-algebra/ASDF-TMP-linear-algebra.fasl written ; compilation finished in 0:00:00.032 ; compiling file "/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/sample/low-discrepancy-sequence.lisp" (written 13 FEB 2012 06:12:50 PM): ; compiling (in-package :antik) ; compiling (export (quote #)) ; compiling (defun val-from-range ...) ; compiling (defun quasi-random-values ...) ; compiling (defun low-discrepancy-sample ...) ; compiling (defun apply-to-arguments ...) ; /Volumes/data/Users/jtk/.cache/common-lisp/sbcl-1.0.54-macosx-x64/Volumes/data/Software/lisp-lib/dists/quicklisp/software/antik-20111105-git/sample/ASDF-TMP-low-discrepancy-sequence.fasl written ; compilation finished in 0:00:00.025

2 1

[GSLL-devel] Why FFT tests are slow
by Sumant S. R. Oemrawsingh 17 Feb '12

17 Feb '12

Hi Liam, I recently realised that I completely forgot to submit the forms that I used to check where the problem lies with the slow FFT tests. So my apologies, and hereby some very simple forms (should be run in package :gsll). I quickly re-ran them to verify that the timings are still the same (with updated gsll and now using antik). ;;;; Check 1: Perform FFTs on 1000 different vectors, each with 1000 ;;;; random complex elements (consisting of a real and a complex ;;;; random element). Takes ~2 seconds on my old laptop. (time (progn (loop for i from 0 below 1000 do (forward-fourier-transform (make-urand-vector '(complex double-float) 1000))) nil)) ;;;; Check 2: Same as 1, but without the FFTs. Takes ~1.8 seconds. (time (progn (loop for i from 0 below 1000 do (make-urand-vector '(complex double-float) 1000)) nil)) Here, it's clear that the time increases by an order of magnitude by just generating random vectors. 1000 FFTs take less time: ;;;; Check 3: Generate only 1 random vector, FFT 1000 times. Takes ~ ;;;; 0.14 seconds. (time (let ((rand (make-urand-vector '(complex double-float) 1000))) (loop for i from 0 below 1000 do (forward-fourier-transform rand)) nil)) So let's see where the problems lie in making the random vector: ;;;; Check 4: Same as 2, but without making the vector. Takes ~1 second. (time (progn (loop for i from 0 below 1000 do (loop for j from 0 below 1000 do (coerce (complex (urand) (urand)) '(complex double-float)))) nil)) ;;;; Check 5: Same as 4, but without coercing. Takes ~0.6 seconds. (time (progn (loop for i from 0 below 1000 do (loop for j from 0 below 1000 do (complex (urand) (urand)))) nil)) You can see that half the time of Check 1 is just spent generating and coercing elements. Then ~40% is making and setting the vectors (non-optimized) and ~10% is the FFTs themselves. I tried making an optimized version of make-urand-vector using declarations, which only sped up things by a little bit (certainly not an order of magnitude); we discussed this before on #lisp. However, since the transition to antik, I didn't manage to get this working in a reasonable amount of time. Regardless, the fact that it still contained the form: (coerce (complex (urand) (urand)) '(complex double-float)) is the reason for the fact that even the optimized version is slow. Since the original GSL tests use random vectors a lot, this is a real problem. The second thing is that I suspect that setf-ing array elements is slower than in C as well. The GSL tests also use this a lot, since they initialize the vectors with known numbers, to verify that those elements were untouched when using the stride keyword. It could be that optimized functions, using declarations and gsetf, will cause those parts of the tests to go faster. I will try that when I have some more time, and when I get it working. By the way, here's the defun for the attempt at an optimized version of make-urand-vector for complex double-floats. I tried many different things (also without the let around) but couldn't get it to run: I always get a type-error. (defun make-urand-complex-double-float-vector (dimension &key (stride 1) init-offset) "Make a complex double-float vector with random elements." (let ((vec (make-and-init-vector '(complex double-float) (* stride dimension) :init-offset init-offset))) (declare (type grid:vector-complex-double-float vec)) (loop for i from 0 below (* stride dimension) by stride do (let ((value (coerce (complex (urand) (urand)) '(complex double-float)))) (declare (type (complex double-float) value)) (grid:gsetf (grid:aref* vec i) value))) vec)) Regards, Sumant -- Sumant Oemrawsingh

2 2

[GSLL-devel] grid:map-n-grids does not play nice with gsll:make-interpolation
by Mirko Vukovic 06 Nov '11

06 Nov '11

The following is using a a few months old GSLL and SBCL -- I do not want to upgrade unless absolutely necessary at this moment, because I need to finish a project first. Consider the following function: (defun foo (x y) (let ((z (grid:map-n-grids :combination-function (lambda (y) y) :sources `((,y nil))))) (gsll:make-interpolation gsll:+linear-interpolation+ x z))) If I call it twice with vectors of different size on the second call (let ((x #m(1d0 2d0 3d0)) (y #m(1d0 1d0 1d0)) (u #m(1d0 2d0 3d0 4d0)) (v #m(1d0 1d0 1d0 1d0))) (foo x y) (foo u v)) I get an error on the second call Invalid argument; data must match size of interpolation object in interp.c at line 76 [Condition of type GSLL:INVALID-ARGUMENT] It seems that `z' still somehow lives with incorrect dimensions between the calls. In actual use, I call foo from repl. So, before calling it, I force a recompile, so that it works for a new vector. Is there a more elegant workaround for this problem? Thanks, Mirko

1 1

[GSLL-devel] try to install package with not results
by ilencaco＠yahoo.com 25 Sep '11

25 Sep '11

Hi, I try to install the package in xp windows - allegro. However i have difficulties to do so Could you help me with this? Best regards, Ismael

2 3

Re: [GSLL-devel] Installing gsll with allegro
by Mirko Vukovic 22 Sep '11

22 Sep '11

You forgot to include gsll mailing list in your reply :-) On what OS are you doing this? On Tue, Sep 20, 2011 at 5:40 PM, <ilencaco(a)yahoo.com> wrote: > > hi, > > I'm using quickload and these are the errors i have. > > Thank you very much for your guidance in this installation > > Best regards, > > Ismael > > > > > > > ==== quicklisp quickstart loaded ==== > > To continue, evaluate: (quicklisp-quickstart:install) > > cg-user(1): (quicklisp-quickstart:install) > > Error: Quicklisp has already been installed. Load #P"C:\\Documents and > Settings\\ismael\\quicklisp\\setup.lisp" instead. > cg-user(2): (ql:quickload "gsll") > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\cffi-grovel.asd > into #<The asdf2 package> > ; Registering #<system "cffi-grovel"> > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\alexandria-20110522-git\alexandria.asd > into #<The asdf2 package> > ; Registering #<system "alexandria"> > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\cffi.asd into > #<The asdf2 package> > ; Registering #<system "cffi"> > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\babel-20110730-git\babel.asd > into #<The asdf2 package> > ; Registering #<system "babel"> > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\trivial-features-20101006-darcs\trivial-features.asd > into #<The asdf2 package> > ; Registering #<system "trivial-features"> > ; Loading system definition from C:\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\asdf-system-connections-20101006-darcs\asdf-system-connections.asd > into #<The asdf1 package> > ; Registering #<system "asdf-system-connections"> > To load "gsll": > Load 7 ASDF systems: > alexandria antik asdf-system-connections cffi-grovel > fsbv osicat trivial-garbage > Install 1 Quicklisp release: > gsll > ; Loading "gsll" > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -fPIC -o > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.exe > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.c > Error: "starting shell command" resulted in error "No such file or > directory" > [condition type: syscall-error] > ("gsll") > cg-user(3): > ; Loading E:\allegro-projects\este > es\project1\statcs\trivial-garbage_latest.tar.gz > > cg-user(3): (ql:quickload "gsll") > > To load "gsll": > Load 1 ASDF system: > gsll > ; Loading "gsll" > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -fPIC -o > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.exe > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.c > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -shared > -fPIC -o C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\libosicat.dll > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\wrappers.c > Error: "starting shell command" resulted in error "No such file or > directory" > [condition type: syscall-error] > ("gsll") > cg-user(4): > cg-user(4): trivial-garbage > (ql:quickload "trivial-garbage") > > Error: Attempt to take the value of the unbound variable `trivial-garbage'. > [condition type: unbound-variable] > cg-user(5): (ql:quickload "trivial-garbage") > > > To load "trivial-garbage": > Load 1 ASDF system: > trivial-garbage > ; Loading "trivial-garbage" > > ("trivial-garbage") > cg-user(6): > cg-user(6): (ql:quickload "gsll") > To load "gsll": > Load 1 ASDF system: > gsll > ; Loading "gsll" > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -fPIC -o > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.exe > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.c > Error: "starting shell command" resulted in error "No such file or > directory" > [condition type: syscall-error] > ("gsll") > cg-user(7): (ql:quickload "trivial-garbage") > > ; Loading E:\allegro-projects\este es\project1\statcs\cffi_0.10.6.tar.gz > (ql:quickload "trivial-garbage") > To load "trivial-garbage": > Load 1 ASDF system: > trivial-garbage > ; Loading "trivial-garbage" > > ("trivial-garbage") > cg-user(8): (ql:quickload "cffi") > > To load "cffi": > Load 1 ASDF system: > cffi > ; Loading "cffi" > > ("cffi") > cg-user(9): > cg-user(9): (ql:quickload "gsll") > > To load "gsll": > Load 1 ASDF system: > gsll > ; Loading "gsll" > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -fPIC -o > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.exe > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\basic-unixint.c > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -shared > -fPIC -o C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\libosicat.dll > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\wrappers.c > ; c:/msys/1.0/bin/gcc.exe -m32 -I\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\cffi_0.10.6\ -shared > -fPIC -o C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\libosicat.dll > C:\Documents and Settings\ismael\Application > Data\common-lisp\cache\acl-8.2m-win-x86\C\Documents and > Settings\ismael\quicklisp\dists\quicklisp\software\osicat-20110619-git\posix\wrappers.c > ("gsll") > cg-user(10): > cg-user(10): > > It seems that you had trouble compiling a few C files in your first two attempts. But then your last (ql:quickload "gsll") does not emit any error messages, right? Mirko

1 0