On Fri, Apr 16, 2010 at 5:29 PM, Mirko Vukovic mirko.vukovic@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