gmane.lisp.gsll

Re: gsll

Liam Healy — 2013-04-14T18:25:48

GSLL is a library written in C, so all its objects live in foreign
space.  CL arrays won't work because the foreign library can not see
them. You can shorten the creation of the foreign array using #m if
grid:*default-grid-type* is 'grid:FOREIGN-ARRAY:

(gsl:mean #m(1 2 3 4 5))
3.0

Please join the mailing list to ask questions and post problems.  Thanks.

Liam

On Sun, Apr 14, 2013 at 1:27 PM, Nelson Marcelino <marcelin7< at >yahoo.com> wrote:

Re: gsll

Liam Healy — 2013-04-13T21:44:53

You need to load the  libffi "developer" package. I don't know what
distro you're using, but on Debian/Ubuntu, it's called libffi-dev.
Also, this is more of a question for cffi-devel, but it happens that I
wrote cffi-libffi (which is the system triggering this error), so it
works out.

Liam

On Fri, Apr 12, 2013 at 12:55 PM, Nelson Marcelino <marcelin7< at >yahoo.com> wrote:

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/

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

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

Re: Matlisp

Akshay Srinivasan — 2013-03-01T03:23:12

At Thu, 28 Feb 2013 07:00:27 +0100,
A.J. Rossini wrote:
I think I've looked at the webpage that was put up by Mark on Berkeley's 
site. I think the tensor branch sort of satisfies all of them (except perhaps
for the LAPACK bits?). Please though take a look at the code.

Akshay

Re: Matlisp

Akshay Srinivasan — 2013-03-01T03:16:08

At Wed, 27 Feb 2013 12:11:26 -0500,
Liam Healy wrote:
I think its very important to get the generalized arrays working very well.
I'm not particularly keen on shadowing CL's functions though; I know it 
sort of makes things clumsy (to work around CL), but it also makes it awkward
to use it outside the package. 

Getting the arrays to work quite well was really my goal, I think its easier to 
build functionality around the array structure. I can just polish the code that
is there now to suit my needs, and then get on with my work, but that'll only lead
to another isolated project in the lisp world. 

It'd be useful if some of you try using matlisp and see if it is atleast
technically suitable for some of your tasks. I know there are a lot of design
decisions which many of you will not agree with, but if you think Matlisp
is worth the effort to base your work on, I'd be more than happy to make
a compromise and change the structure to suit your needs.

Akshay

Re: Matlisp

Liam Healy — 2013-02-27T17:11:26

Hi Akshay,

Thank you for your work and your email.

I think a lot of people have had very similar thoughts to yours, and
have started down the road meeting the needs of users they've
identified.  There are a lot of good and partially overlapping ideas
within this loosely organized group of people.   There was a similar
discussion started in the context of common lisp stats (which I'm not
a member of) a few months ago.  Where I was participating, I cc'ed the
antik-devel mailing list; see for example

 http://lists.common-lisp.net/pipermail/antik-devel/2012q4/000019.html

and the archives in general
http://lists.common-lisp.net/pipermail/antik-devel/2012q4/thread.html
with the subject "numerical lisp".

My feeling is that we need to break the desired functions into
relatively narrow, compatible libraries.  I started Antik as a split
out of GSLL to handle "grids" (generalized arrays) to start down that
road.  It needs to be split up further, because it now includes other
things such as calculations with physic

Re: Physics-constants library?

Mirko Vukovic — 2013-02-26T13:37:57

And, we now have a public library with physical constants, soon to be
available via quicklisp.

See https://groups.google.com/d/msg/comp.lang.lisp/TQzgqc5E98Q/cat9u1syUuQJ

On Thu, Feb 21, 2013 at 12:57 PM, Liam Healy <lhealy< at >common-lisp.net> wrote:

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

Re: Physics-constants library?

Liam Healy — 2013-02-21T17:57:56

It would be nice to have a library of physics constants.  One thing to note
is that the GSLL constants are not (yet) integrated as Antik physical
constants, but they should be.  I am in the process of overhauling
parameters and constants in Antik (on the "parameters" branch), so that
would be a good thing to include.

If you come up with anything, let us know.  Thanks.

Liam

On Thu, Feb 21, 2013 at 10:05 AM, Mirko Vukovic <mirko.vukovic< at >gmail.com>wrote:

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

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=fa

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 declarat

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-d

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-o

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">
; Re

Re: [Antik-devel] FLAME and possible next libraryports using grids

Mirko Vukovic — 2012-12-08T14:29:38

or interpolation of Delauny triangulated grids.

One of these days, when the needs really strikes, I will try to link CL to
the triangle library (https://www.cs.cmu.edu/~quake/triangle.html -- I
tested the C code on linux, and there is documentation for linking it as a
library.)

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

Re: [Antik-devel] FLAME and possible next libraryports using grids

Mirko Vukovic — 2012-11-25T16:05:06




I would like to see links to additional special functions, such as
http://www.netlib.org/amos/readme for Bessel functions of complex order.
This one is written in FORTRAN-77.  Several years ago, I did make links to
it, but it was an ugly and painful effort using another library that does
not function anymore.  The next time the need arises, I will try again, and
post the results to encourage wider usage.

Mirko
_______________________________________________
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 linea

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 give