[Gsll-devel] The price of progress: sbcl1.0.37 and gsl1.14

[Liam Healy]

On Fri, Apr 16, 2010 at 5:29 PM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> The following is my experience on 64-bit RedHat Enterprise Linux and
> emacs 23.1.  I am slowly learning the meaning of `bleeding edge'
> hardware & software.
>
> *64-bit*
>
> I cannot link to 64-bit libraries.  I had to use the 32-bit versions
> of gsl and ffi libraries.  I don't think I had this problem with
> sbcl1.0.34.  I am not sure what is the root cause of this.  I suspect
> something with cffi and latest sbcl1.037.  But I don't know how to
> test this.
>
> (btw, to compile gsl for 32 bit, I used the configure switch
> `./configure -CFLAGS=-m4')

You got me, I'm well behind you in SBCL versions.

> *gsll/mathematical/complex.lisp*
>
> The file fails to compile.  The error is:
>
>  warning:
>    Asserted type SB-SYS:SYSTEM-AREA-POINTER conflicts with derived type
>    (VALUES (COMPLEX DOUBLE-FLOAT) &OPTIONAL).
>
> I guess SBCL is picky about something, but I really wish I understood
> what was going under GSLL's hood (those macros are huge).

Can you please give a complete backtrace when you send in a bug
report?  This could come from anything, and it's not really helpful
as-is.  Also, put separate problems in separate emails please.

The macros are huge, but that should be no problem to you.  In slime,
put your cursor on the start of the form using the macro, and do C-c
C-m.  You will see instantly what it expands to.

>
> But that is only part of the story.  I can evaluate a `defmfun' form
> (such as (defmfun cx-add ...)), but I cannot execute it.  For example,
> (gsl::cx-add #C(1d0 2d0) #C(3d0 4d0)) will throw an error:
>
> The value #C(1.0d0 2.0d0)
> is not of type
>  SB-SYS:SYSTEM-AREA-POINTER.
>   [Condition of type TYPE-ERROR]
>
> I looked at fsbv/examples.lisp (see complex-add), and don't understand
> why one works and the other does not.

What do you mean by evaluate and execute?
Explain exactly what you are doing in each case.

> *testing*
>
> Testing produces more failures with the 32-bit version than with the
> 64-bit one.  The testing results can be improved somewhat by doing:
> (let ((lisp-unit:*epsilon* 1d-6))
>       (lisp-unit:run-tests))
>
> resulting in TOTAL: 1432 assertions passed, 29 failed, 9 execution errors.

Yes, this is been the case for a while (ever since I stopped testing
in 32 bits :-)).  As I replace tests with strict ports of the GSL
tests, all error numbers should go down, and then we can try to figure
out why 32 bits are worse.  But that's going to be a while.

>
> Admittedly, this is a dubious way of improving the testing score :-)
> So caveat emptor :-)
>
> *fsbv init.lisp*
>
> Here is a little patch to load libraries.  Notice the missing 64-bit
> locations.  These are banished for now.
>
> (cffi:define-foreign-library libffi
>  (:darwin
>     (:or "/opt/local/lib/libffi.dylib" "/sw/lib/libffi.dylib"
>          "/usr/local/lib/libffi.dylib"))
>  (:unix (:or "/usr/local/lib/libffi.so.0" "/usr/local/lib/libffi.so"
>              "/usr/lib/libffi.so.0" "/usr/lib/libffi.so"))
>  (t (:default "libffi")))
>
> (cffi:use-foreign-library libffi)

You'll have to explain a bit what you changed and why.  Since I'm not
a Mac user, I want to make sure that this change helps Mac users and
doesn't leave some stuck.  In general I'm cautious about changing
these paths especially for platforms I don't use.

> (I cannot push patches to git as I am behind the firewall, and even
> the http protocol does not work)

You can't push patches to the public repository because you aren't
authorized to do so, not because of your firewall.  The right thing to
do is to email them to the list or to me.  Do
git format-patch origin
and you will find one or more files starting with a four-digit
sequence number, 0001-* etc.  Attach those to your email.

Thank you.

Liam

>
> Cheers,
>
> Mirko