gmane.lisp.gsll

gsll

Nelson Marcelino — 2013-04-12T16:55:46

I'm having trouble getting this to work on Linux. Any help?


Error while trying to load definition for system gsll from
pathname
/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/gsll-20130312-git/gsll.asd:

   External process exited with code 1.
Command was: "cc" "-m64" "-I/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/" "-o" "/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix" "/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c"
Output was:
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:7:17: error: ffi.h: No such file or directory
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c: In function âmainâ:
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:25: error: âFFI_OKâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:25: error: (Each undeclared identifier is reported only once
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:25: error: for each function it appears in.)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:30: error: âFFI_BAD_TYPEDEFâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:35: error: âFFI_BAD_ABIâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:46: error: âFFI_DEFAULT_ABIâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:51: error: âFFI_SYSVâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:56: error: âFFI_UNIX64â undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:64: error: âffi_abiâ undeclared (first use in this function)
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:111: error: invalid application of âsizeofâ to incomplete type âstruct _ffi_typeâ 
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:116: error: dereferencing pointer to incomplete type
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:121: error: dereferencing pointer to incomplete type
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:126: error: dereferencing pointer to incomplete type
/home/nelson/.cache/common-lisp/ccl-1.8-f95-linux-x64/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/cffi_0.11.0/libffi/libffi-unix.c:131: error: dereferencing pointer to incomplete type

   [Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]

Restarts:
 0: [RETRY] Retry #<STANDARD-CLASS PROCESS-OP> on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi">.
 1: [ACCEPT] Continue, treating #<STANDARD-CLASS PROCESS-OP> on #<GROVEL-FILE "cffi-libffi" "libffi" "libffi"> as having been successful.
 2: [RETRY-LOAD] Retry loading #P"/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/gsll-20130312-git/gsll.asd"
 3: [SKIP-LOAD] Skip loading #P"/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/gsll-20130312-git/gsll.asd"
 4: [LOAD-OTHER] Load other file instead of #P"/home/nelson/lib-asdf/quicklisp/dists/quicklisp/software/gsll-20130312-git/gsll.asd"
 5: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system gsll after reinitializing the source-registry.

LinkedIn Ağ Güncellemeleri, 11/4/2013

LinkedIn Güncellemeleri — 2013-04-11T19:07:51

LinkedIn
------------



  LinkedIn Ağ Güncellemeleri
  GÖRÜNTÜLENEN GÜNCELLEMELER
  4 Nis - 11 Nis
  ---
  Görüntülenen Güncellemeler


* D. E. (Steve) Stevenson şu kişiyle bağlantı kurdu: Strickler Cassy                ve 
Curt Reynolds                

  Genişletilmiş Ağınızdan Güncellemeler</span><br />
  (Bu kişiler ile bağlantı kurarark neler yaptıklarını öğrenin.)
  




 * umud shukri bir kitab
İran: Tehdit mi, Fırsat mı?
Bülent Keneş
http://lnkd.in/RPChBy      
   Bağlantıyı Görüntüleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nua/s1415730201/http%3A%2F%2Flnkd%2Ein%2FRPChBy/Q8kz/5728191161848299520/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=0Z2WDCrjkXklI1
   umud shukri ile bağlantı kurun: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/int/profile/206959193/umud/shukri/XWBU/name/EML-nusdigest-bkf/?hs=false&tok=3vCqwxxZIXklI1
   Yorum ekleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nds/206959193/M/U/5728191161848299520/Nzx1/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=1doZM5nNMXklI1





 * Cemil Cemiloglu Linkedin has a very accurate recommendations system, this is how they do it, Hadoop is what is under the hood.
http://lnkd.in/3hER9M      
   Bağlantıyı Görüntüleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nua/s1415724342/http%3A%2F%2Flnkd%2Ein%2F3hER9M/K7lG/5728191048421736448/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=2nmAwESbkXklI1
   Cemil Cemiloglu ile bağlantı kurun: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/int/profile/6152363/Cemil/Cemiloglu/R5GY/name/EML-nusdigest-bkf/?hs=false&tok=2B0m-L8YcXklI1
   Yorum ekleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nds/6152363/M/U/5728191048421736448/QX_n/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=3HLJTO2jkXklI1





 * Püren Özyüksel http://lnkd.in/ks8Pq3      
   Bağlantıyı Görüntüleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nua/s1415722082/http%3A%2F%2Flnkd%2Ein%2Fks8Pq3/bB2i/5728189960197009408/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=0TWruG5XcXklI1
   Püren Özyüksel ile bağlantı kurun: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/int/profile/12385490/P%C3%BCren/%C3%96zy%C3%BCksel/RbBa/name/EML-nusdigest-bkf/?hs=false&tok=0TKy-6J5UXklI1
   Yorum ekleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nds/12385490/M/U/5728189960197009408/f8Q0/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=2Ry9KtMiAXklI1





 * sezgin cirit link postaladı      
   Bağlantıyı Görüntüleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nua/s1415725256/http%3A%2F%2Flnkd%2Ein%2FJkz_Cd/CoBd/5728189505693839360/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=1mbDHREdUXklI1
   sezgin cirit ile bağlantı kurun: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/int/profile/61079128/sezgin/cirit/34_f/name/EML-nusdigest-bkf/?hs=false&tok=3W-05GHJwXklI1
   Yorum ekleyin: http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nds/61079128/M/U/5728189505693839360/ftPY/EML_nus_share-FBackfillKafkaConsumer/?hs=false&tok=0VM7DhWIcXklI1


  Diğer güncellemeleri göster »
      http://www.linkedin.com/e/-8a34oq-hfeauj7u-4t/nth/false/eml_nus_home_bottom/?hs=false&tok=0Mv1SmoHcXklI1

Loading Foreign Libraries in MacOSX

David Hodge — 2013-04-01T00:38:26

Hi

I am using SBCL on MacOSX and when I try to load the latest GSLL it 
can't find the foreign libraries for libgslcblas and libgsl.
Looking at the source from an earlier version I see that the 
"lib/"prefix has been omitted from the library names.

One possible workaround would be to use "gsl-config --libs" and extract 
the library directory from that. if you are interested I can supply a patch.

cheers

CFFI release 0.11.0

Liam Healy — 2013-03-03T23:12:42

CFFI 0.11.0 was released last week.  This includes cffi-libffi, which
makes FSBV obsolete.  The new versions of Antik and GSLL now use
cffi-libffi instead of FSBV.  For most users of these systems, this is
an internal detail and unimportant.  However, for the past 6 months at
least, I have been using and updating these versions and not the FSBV
version.  So, with these branches merged into the master branch, a
number of patches and fixes have made there way into the master
branch.   I expect in the March update to quicklisp, all these changes
will be in the new dist.

Waiting for CFFI to be finalized blocked a number of projects.  One is
to split up Antik into different systems instead of making one system
that loads everything (grid, physical quantities, etc.).  Another is
dataflow definitions (and coordination with org-mode) that I am just
starting on.  In GSLL, I've started to look at the definition of
physical constants.  I don't know when I'll have time to work on these
or when they'll be complete, but I'll update when I have something.

Liam

Physics-constants library?

Mirko Vukovic — 2013-02-21T15:05:16

I did not find a library with physics constants on cliki or quicklisp.

There is one available from within GSLL, but loading GSLL just for physics constants is an overkill.

Are there any other ones?

I have one of my own (somewhat incomplete) that works for me, and I can clean it up and push it to quicklisp if nothing meaningful is out there.


Mirko

LinkedIn'deki ağıma katılın.

Leo Liu, LinkedIn aracılığıyla — 2013-02-11T12:34:05

LinkedIn
------------




    Leo Liu, sizi LinkedIn'de bağlantı olarak eklemek istiyor:
  

------------------------------------------

Sizi LinkedIn'deki profesyonel ağıma eklemek istiyorum.

Leo Liu adlı kullanıcıdan gelen davetiyeyi kabul et
http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/blk/I147969124_210/e39SrCAJoS5vrCAJoyRJtCVFnSRJrScJr6RBfnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_c34OnPgOcjASejsQckALrRFAqjpFsmgLd30Sdz8Ndj0Mcj4LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=3t6EU1UCri0RE1

Leo Liu adlı kullanıcının profilini görüntüle
http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/rso/231655244/zieP/name/210660491_I147969124_210/?hs=false&tok=0Ju4BzoBHi0RE1
------------------------------------------
Davet e-postaları alıyorsunuz


Bu e-posta Steve Stevenson için tasarlanmıştır.
Bunun neden eklendiğini öğrenin: http://www.linkedin.com/e/-8a34oq-hd1lsvdo-5z/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=0G8IwWQ4vi0RE1

(c) 2012, LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043 USA


  
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

added basic fft to my dataframes

Mirko Vukovic — 2013-01-14T02:53:55

In preparation for experiments that start tomorrow, I added today 
real-array fft and power spectrum capabilities to my dataframe code.  It 
uses GSLL's fft functions (search for file fft.lisp).  The classes, generic 
functions, and methods are still a bit rough, and will be refined.

You can read more about it: 
https://github.com/mirkov/data-table/blob/master/user/example1/README.org

That same directory contains examples-w-fft.lisp that shows the code 
usage.  I annotated the code.

The png files show sunspot data and two power spectra.

The example shows how I create one data-table with raw data, and then 
another one with slightly massaged data.  I do the fft on the latter one.

The example also shows that the current syntax is `functional' vs 
`declarative'. I explicitly  build the second data table, instead of 
declaring its dependency on the first table.  I think that the latter 
approach is preferable from a user's point of view.  But I will refrain 
from trying to design and implement this declarative approach.  I need more 
real-world experience before trying to do this.

I may add windowing capability to the fft code later on.

Mirko
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Fixing up make-grid-data for clisp (was making copy-to working in clisp+grid: fix to element-type)

Mirko Vukovic — 2013-01-04T16:47:51

This is a follow up on my posted fix to copy-to.  For some reason this has
triggered another
error.  I do not understand how that other error is triggered.  The error
and the fix are discussed
at the bottom of the email

On Fri, Jan 4, 2013 at 10:39 AM, Mirko Vukovic <mirko.vukovic< at >gmail.com>wrote:

traced to make-grid-data and make-array

In clisp, make-array will return an array of NIL's even if the element-type
is specified as double float.  In SBCL make-array
will return an array filled with 1d0.

I had to add some clisp specific code to make-grid-data in order for it to
initialize properly.

First, a helper function:
(defun default-element (element-type)
   "Return a default element depending on element-type
"
   (let ((a-list '((double-float . 1d0)
           (symbol . T))))
     (let ((match (cdr (assoc element-type a-list))))
       (assert match ()
           "Default element type undefined for element-type ~a"
           element-type)
       match)))

And second, a bit of set-up code in make-grid-data.  I broke apart the
(let* statement
to provide an explicit initial element if it has not been specified already:

(defmethod make-grid-data
  ((type (eql 'array)) dimensions rest-spec
   &key (initial-element nil initial-element-p)
   (initial-contents nil initial-contents-p))
  (let ((element-type (top-spec-type rest-spec)))
    #+clisp
    (unless (or initial-element-p
        initial-contents-p)
      (setf initial-element (default-element element-type)
        initial-element-p t))
    (let ((array ... UNCHANGED


Summary:  To fix to copy-to, I modified (defmethod element-type ((grid
array))
For some unknown reason, that triggered an error in the array
initialization routine.
To fix that, I had to add code to make-grid-data, so that it fills
double-float arrays with 0d0
instead of NIL's

I will continue using this code to see if there are additional problems.

BTW, I realize that CLISP is not a preferred platform for speedy
computation, but that is what I use
on Windows, until SBCL gets officially ported to it.  And in addition, it
is a nice cross-check on portability.

Mirko
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

making copy-to working in clisp+grid: fix toelement-type

Mirko Vukovic — 2013-01-04T15:39:53

The following works in sbcl+grid:

(copy-to (make-array 2 :element-type 'double-float :initial-contents
'(1.0d0 2.0d0)) 'grid:foreign-array)

But it does not work in clisp+grid.

The root cause lies in the function grid/array.lisp/element-type.  It uses
`(array-element-type grid)'.

But this can present a problem.  Quoting hyperspec:

(Because of *array* <26_glo_a.htm#array> *upgrading*, this *type
specifier*<26_glo_t.htm#type_specifier>can in some cases denote a
*supertype* <26_glo_s.htm#supertype> of the *expressed array element
type*<26_glo_e.htm#expressed_array_element_type>of the
*array*.)

In CLISP, array-element-type returns `T' when passed #(1d0 2d0)

It returns T even when passed a simple array:

(array-element-type (make-array 2 :element-type 'double-float
:initial-contents
                      '(1.0d0 2.0d0)
                      :adjustable nil
                      :fill-pointer nil
                      :displaced-to nil) )

The proposed fix is

(defmethod element-type ((grid array))
  (type-of (row-major-aref grid 0))
  #+skip(array-element-type grid))

Now copy-to works in clisp as well.

Mirko
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Error installing GSLL

Patrick M. Groulx — 2013-01-02T23:52:55

Hi all,

I have been trying to install GSLL for the past couple of days on Ubuntu and
Debian, both running SBCL, and I keep encountering the same problem.

I install Quicklisp without any difficulty but when I attempt to install
GSLL I get the output that I have included below.

It appears that the error is in static-vectors and the use of the component
"CFFI-GROVEL-FILE." I'm not seeing where in the source files that I have the
component defined anywhere, so I am at a loss as to what it does. I have
included the output of (list-all-packages) at the very bottom in case I am
missing something. I'm hoping that someone with a more in-depth
understanding of the different components can help me out.

Thanks,

Patrick




* (ql:quickload "gsll")

; Loading system definition from
; /usr/share/common-lisp/source/cl-cffi/cffi-grovel.asd into #<PACKAGE
"ASDF2">
; Registering #<SYSTEM "cffi-grovel">
; Loading system definition from
; /usr/share/common-lisp/source/alexandria/alexandria.asd into
; #<PACKAGE "ASDF2">
; Registering #<SYSTEM "alexandria">
; Loading system definition from
/usr/share/common-lisp/source/cl-cffi/cffi.asd
; into #<PACKAGE "ASDF2">
; Registering #<SYSTEM "cffi">
; Loading system definition from
/usr/share/common-lisp/source/babel/babel.asd
; into #<PACKAGE "ASDF2">
; Registering #<SYSTEM "babel">
; Loading system definition from
; /usr/share/common-lisp/source/trivial-features/trivial-features.asd into
; #<PACKAGE "ASDF2">
; Registering #<SYSTEM "trivial-features">
; Loading system definition from
; 
/home/pgroulx/quicklisp/dists/quicklisp/software/asdf-system-connections-201
01006-darcs/asdf-system-connections.asd
; into #<PACKAGE "ASDF1">
; Registering #<SYSTEM "asdf-system-connections">
To load "gsll":
  Load 1 ASDF system:
    gsll
; Loading "gsll"

debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread #<THREAD
                                                               "initial
thread" RUNNING
                                                               {AAE5749}>:
  Error while trying to load definition for system antik from pathname
  
/home/pgroulx/quicklisp/dists/quicklisp/software/antik-20120909-git/antik.as
d:

     Error while trying to load definition for system static-vectors from
     pathname
     
/home/pgroulx/quicklisp/dists/quicklisp/software/static-vectors-1.4/src/stat
ic-vectors.asd:

        don't recognize component type CFFI-GROVEL-FILE

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system
                                              static-vectors after
                                              reinitializing the
                                              source-registry.
  1:                                          Retry finding system antik
after
                                              reinitializing the
                                              source-registry.
  2: [ABORT                                 ] Give up on "gsll"
  3:                                          Exit debugger, returning to
top
                                              level.

((FLET #:LAMBDA2060) #<LOAD-SYSTEM-DEFINITION-ERROR {B6E6AD9}>)
0] 0 
.......;
; compilation aborted because of fatal error:
;   SB-INT:SIMPLE-READER-PACKAGE-ERROR at 4208 (line 102, column 38) on
#<SB-SYS:FD-STREAM
;                  
for "file 
/home/pgroulx/quicklisp/dists/quicklisp/software/antik-20120909-git/foreign-
array/foreign-array.lisp"
;                  
{C1CA541}>:
;     package "STATIC-VECTORS" not found
;   

debugger invoked on a ASDF:COMPILE-ERROR in thread #<THREAD
                                                     "initial thread"
RUNNING
                                                     {AAE5749}>:
  Error while invoking #<COMPILE-OP (:VERBOSE NIL) {B53E519}> on
  #<CL-SOURCE-FILE "antik" "foreign-array" "foreign-array">

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY ] Retry
              compiling #<CL-SOURCE-FILE "antik" "foreign-array"
"foreign-array">.
  1: [ACCEPT] Continue, treating
              compiling #<CL-SOURCE-FILE "antik" "foreign-array"
"foreign-array">
              as having been successful.
  2: [ABORT ] Give up on "gsll"
  3:          Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
 #<unavailable argument>
 #<unavailable argument>
 #<ASDF:COMPILE-OP (:VERBOSE NIL) {B53E519}>
 #<ASDF:CL-SOURCE-FILE "antik" "foreign-array" "foreign-array">)
0] 2
; 
; compilation unit aborted
;   caught 2 fatal ERROR conditions

("gsll")










(#<PACKAGE "AFFI"> #<PACKAGE "ANTIK-USER"> #<PACKAGE "GRID"> #<PACKAGE
"ANTIK">
 #<PACKAGE "ITERATE"> #<PACKAGE "SPLIT-SEQUENCE">
 #<PACKAGE "FOREIGN-STRUCTURES-BY-VALUE"> #<PACKAGE "DRAKMA"> #<PACKAGE
"PURI">
 #<PACKAGE "CL-BASE64"> #<PACKAGE "CHUNGA"> #<PACKAGE "CL-PPCRE">
 #<PACKAGE "USOCKET"> #<PACKAGE "CL+SSL"> #<PACKAGE "FLEXI-STREAMS">
 #<PACKAGE "TRIVIAL-GRAY-STREAMS"> #<PACKAGE "BORDEAUX-THREADS">
 #<PACKAGE "PURI-SYSTEM"> #<PACKAGE "CL-BASE64-SYSTEM">
 #<PACKAGE "CL-PPCRE-ASD"> #<PACKAGE "TRIVIAL-GRAY-STREAMS-SYSTEM">
 #<PACKAGE "FLEXI-STREAMS-SYSTEM"> #<PACKAGE "CL+SSL-SYSTEM">
 #<PACKAGE "ASDF-SYSTEM-CONNECTIONS-SYSTEM"> #<PACKAGE "CFFI-GROVEL">
 #<PACKAGE "CFFI-FEATURES"> #<PACKAGE "CFFI"> #<PACKAGE "CFFI-SYS">
 #<PACKAGE "BABEL"> #<PACKAGE "BABEL-ENCODINGS"> #<PACKAGE
"ALEXANDRIA.0.DEV">
 #<PACKAGE "DRAKMA-ASD"> #<PACKAGE "TRIVIAL-GARBAGE"> #<PACKAGE "QL-SBCL">
 #<PACKAGE "SB-BSD-SOCKETS"> #<PACKAGE "SB-BSD-SOCKETS-SYSTEM">
 #<PACKAGE "SB-BSD-SOCKETS-INTERNAL"> #<PACKAGE "SB-POSIX-SYSTEM">
 #<PACKAGE "SB-GROVEL-SYSTEM"> #<PACKAGE "SB-GROVEL"> #<PACKAGE "SB-POSIX">
 #<PACKAGE "QL-MKCL"> #<PACKAGE "QL-ECL"> #<PACKAGE "QL-LISPWORKS">
 #<PACKAGE "QL-SCL"> #<PACKAGE "QL-CMUCL"> #<PACKAGE "QL-CLISP">
 #<PACKAGE "QL-CCL"> #<PACKAGE "QL-ABCL"> #<PACKAGE "QL-ALLEGRO">
 #<PACKAGE "QUICKLISP-CLIENT"> #<PACKAGE "QL-DIST-USER"> #<PACKAGE
"QL-DIST">
 #<PACKAGE "QL-CDB"> #<PACKAGE "QL-GUNZIPPER"> #<PACKAGE "QL-MINITAR">
 #<PACKAGE "QL-HTTP"> #<PACKAGE "QL-PROGRESS"> #<PACKAGE "QL-NETWORK">
 #<PACKAGE "QL-IMPL-UTIL"> #<PACKAGE "QL-IMPL"> #<PACKAGE "QL-CONFIG">
 #<PACKAGE "QL-SETUP"> #<PACKAGE "QL-UTIL"> #<PACKAGE "ASDF">
 #<PACKAGE "COMMON-LISP-CONTROLLER"> #<PACKAGE "COMMON-LISP-USER">
 #<PACKAGE "SB-LOOP"> #<PACKAGE "SB-EVAL"> #<PACKAGE "SB-WALKER">
 #<PACKAGE "SB-UNIX"> #<PACKAGE "SB-SEQUENCE"> #<PACKAGE "SB-PROFILE">
 #<PACKAGE "SB-PRETTY"> #<PACKAGE "SB-MOP"> #<PACKAGE "SB-THREAD">
 #<PACKAGE "SB-GRAY"> #<PACKAGE "SB-FORMAT"> #<PACKAGE "SB-FASL">
 #<PACKAGE "SB-DISASSEM"> #<PACKAGE "SB-DEBUG"> #<PACKAGE "SB-C">
 #<PACKAGE "SB-BIGNUM"> #<PACKAGE "SB-ASSEM"> #<PACKAGE "SB-ALIEN">
 #<PACKAGE "SB-PCL"> #<PACKAGE "SB-ALIEN-INTERNALS"> #<PACKAGE "SB-DI">
 #<PACKAGE "KEYWORD"> #<PACKAGE "SB-IMPL"> #<PACKAGE "SB-SYS">
 #<PACKAGE "SB-KERNEL"> #<PACKAGE "SB-VM"> #<PACKAGE "SB-INT">
 #<PACKAGE "SB-EXT"> #<PACKAGE "COMMON-LISP">)



_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

FLAME and possible next library ports using grids

Liam Healy — 2012-11-17T14:20:47

On this and other mailing lists, there have been recent discussions of
"numerical lisp" which in one aspect or another has been the vision of many
of us, some for many years.  My approach is to write libraries I think will
form a piece of the overall solution, with the hope that others will join
in and write compatible libraries that form another piece.  So, I initially
wrote GSLL and then split the grid part out into Antik (which has other
features I adapted from my personal libraries).  The grid functions can use
enhancement, but they are usable now for developing library ports.

I have thought about and had discussions with others about what would be a
good candidate library for the next port.  These thoughts have revolved
mainly around an FFT library (like fftw) or a linear algebra library (like
*lapack) because those are widely used and, since GSL already provides some
of that capability, offers a good opportunity to compare features and make
a unified interface.  Recently, I came across the FLAME linear algebra
library (http://z.cs.utexas.edu/wiki/flame.wiki/FrontPage).  It is designed
with an intriguing modularity concept.  I think it would be a good library
to port to grid/Antik.  Unfortunately, I don't have the time to work on
this, but if anyone (particularly someone who needs linear algebra
capability like this) wants to take it up, I encourage that and will help
as much as I can.

A big challenge I foresee in any foreign library interface is the
allocation of arrays.  If it is a "closed box," it makes it hard to use
e.g. static-vectors and therefore the arrays have to be copied back and
forth between the foreign side and the CL side.  GSL has the advantage that
there are functions that allow building GSL arrays out of supplied C
arrays, so regular CL arrays can be allocated with a C pointer passed to
these functions to wrap them with GSL metadata.  I'm not sure many other
libraries are that flexible; many (e.g. C++ libraries) consider it a virtue
to seal off the raw storage (C arrays) from the user, and force you to go
through a foreign interface to do the allocation.  Since there are almost
no CLs that permit construction of CL arrays using foreign data, copying is
the only option left.

So, if anyone has thoughts on FLAME or any other library, I'll be happy to
contribute my ideas if it will help.

Liam
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Violation of the GFDL in GSLL

Sébastien Villemot — 2012-10-29T20:42:38

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,

Invitation to connect on LinkedIn

D. E. (Steve) Stevenson — 2012-10-19T23:32:27

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=false&tok=2Tj8mB7ma4vRs1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-8a34oq-h8hxokmc-3p/ZinPG-VgE-rKjpgcnEb9mzEQSFxByJSla2OxtonX/goo/gsll-devel%40common-lisp%2Enet/20061/I3066803727_1/?hs=false&tok=2RwYqb33a4vRs1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.


  
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Having trouble installing GSLL

Steve Stevenson — 2012-06-17T17:03:18

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.

recompilation of antic upon load of gssl

JTK — 2012-02-14T22:58:32


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

Why FFT tests are slow

Sumant S. R. Oemrawsingh — 2011-11-19T23:38:10

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

grid:map-n-grids does not play nice withgsll:make-interpolation

Mirko Vukovic — 2011-11-03T19:02:40

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
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

try to install package with not results

2011-09-24T02:35:03

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_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Installing gsll with allegro

2011-09-20T02:59:48

hi Liam,
 
I'm new with lisp and I would like to install the gsll in my machine with allegro cl- . However noting seems to work
I would appreciate your help. 
 
Best regards,
 
Ismael_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Antik, a Common Lisp system that provides a foundation for scientific and engineering computation

Liam Healy — 2011-08-18T03:22:02

Hello GSLLers,

Over the past eight months or so, I have been working on a new Lisp system
to provide common definitions useful for a variety of scientific and
engineering computing.  It is called "Antik" and it is now ready to be used
by others.  Though I say "new", in reality, much of it is old, as it is
composed of two parts: one are the grid and foreign-array modules that were
already required by GSLL (and formerly supplied by the GSD repository), and
the other consist of several modules, most of which I have written over the
past decade or more and used myself but never made public.  These include
elementary generic mathematical functions, physical dimension quantities
(i.e., computation with units), and simplified interfaces to some GSLL
functions.  There are other, less well developed modules, such as one to
help organize computation, that I hope will get more complete in the
future.  There is detailed documentation for the mature parts of Antik.  The
homepage for Antik is http://www.common-lisp.net/project/antik/.

Because Antik has all the grid definitions from GSD, GSLL now uses Antik
instead of GSD, and GSD is now obsolete.   The grid definitions are for the
most part the same as before, with a few changes.  First, grid:aref is
preferred to grid:gref for grid element access, though the latter is still
supported.  The reader macro #m by default expands to generate CL arrays,
but this can easily be changed to expanding to foreign arrays by changing
grid:*default-grid-type*, which GSLL does on loading.

Since GSLL needs the grid and foreign-array modules, and most GSLL users are
interested in broader scientific computing tasks than just GSL, I thought I
would let you know about Antik via this mailing list.   If you load GSLL
using git, you will need to load Antik from the git repository (see
http://repo.or.cz/w/antik.git).  If you load GSLL using quicklisp, you will
need to wait a bit until the next update, which should automatically bring
in the right systems.

An independent change to GSLL is that there is no longer a separate system
gsll-tests that needs to be loaded.  Instead, the tests are defined by an
asdf-system-connections system, so that if gsll and lisp-unit are both
loaded (in either order), the tests will be defined.

When convenient, please switch to the new GSLL and Antik.  Your comments are
welcome; there is a mailing list for Antik at
http://common-lisp.net/cgi-bin/mailman/listinfo/antik-devel.

Liam
_______________________________________________
GSLL-devel mailing list
GSLL-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel

Bug in dirichlet-log-pdf?

Nils Bertschinger — 2011-07-29T12:49:27

Hi,

it appears that dirichlet-log-pdf is broken:

CL-USER> (gsll:dirichlet-log-pdf #m(1.0d0 2.0d0) #m(0.3d0 0.7d0))
0.0d0
CL-USER> (gsll:dirichlet-log-pdf #m(2.0d0 1.0d0) #m(0.7d0 0.3d0))
-0.35667494393873245d0

Obviously, the Dirichlet distribution is permutation invariant, so both 
results should be the same! By the way, both values are wrong. A straight 
forward implementation of the formula for the Dirichlet distribution 
gives:

(defun dirichlet-log-pdf (alphas ps)
   (let ((norm (loop for a across alphas
  sum (gsll:log-gamma a) into num
  sum a into denom
  finally (return (- num (gsll:log-gamma denom))))))
     (- (reduce #'+ (map 'vector #'(lambda (p a) (* (- a 1.0d0) (log p)))
 ps alphas))
        norm)))

CL-USER> (dirichlet-log-pdf #(1.0d0 2.0d0) #(0.3d0 0.7d0))
0.33647223662121384d0
CL-USER> (dirichlet-log-pdf #(2.0d0 1.0d0) #(0.7d0 0.3d0))
0.33647223662121384d0
CL-USER>

as it should be.

Maybe I'm doing something wrong, when calling the gsl library function. 
Otherwise, I suspect there is a problem with passing arrays to the GSL. 
Broken memory layout?

I'm using the following version of SBCL:

CL-USER> (lisp-implementation-version)
"1.0.45.0.debian"
CL-USER> (software-version)
"2.6.35-28-server"
CL-USER> gsl:*gsl-version*
"1.14"

and my GSLL is from gsll-20101207-git as packaged in quicklisp.

Any ideas of what is going on here?

Thanks,

 Nils