matlisp-devel — Developers discussion list. Users can request stuff here as well.

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362

[Raymond T. <toy...@gm...>]

On Sun, Mar 18, 2012 at 8:47 PM, Akshay Srinivasan <
aks...@gm...> wrote:

> On 03/18/2012 11:15 PM, Raymond Toy wrote:
> > On 3/17/12 4:09 AM, Akshay Srinivasan wrote:
> >
> > -matlisp-commit
> > +matlisp-devel
> >> ;;Create a 4x4 matrix with random entries
> >> (defvar d (make-complex-matrix 4 4))
> >>
> >> (dotimes (i 4)
> >>   (dotimes (j 4)
> >>    (setf (matrix-ref-2d d i j)
> >>          (complex-coerce (complex (cl:random 10) (cl:random 10))))))
> > There's a rand() function, but it currently doesn't work because
> > :row-stride is unbound.
> >
> > Is there a reason why these are unbound?   Isn't there some suitable
> > default for this, assuming we're creating a regular full matrix?
> The defaults for :row-stride and :col-stride should be ((ncols mat), 1)
> for row-major and (1, (nrows mat)) for col-major. I can probably add
> this into :before initialize-instance method, but I don't think that's a
> good thing.
>

It seems to me that if I do (make-instance 'real-matrix :nrows rows :ncols
cols) I shouldn't have to specify the strides unless I really want to.
There should be some default.  Either column-major or row-major.


> >
> >> ;;Submatrix of d starting at (1, 1) or size (2, 2)
> >> (defvar e (sub! d 1 1 2 2))
> > We should pick a better name than sub!, like maybe sub-matrix!.  And
> > what does the ! mean here?  The intention for "!" is to mean a
> > destructive operation so does sub! destructively modify d to make a
> > submatrix?  And what would that actually mean?  If it's not destructive,
> > then don't use "!".
> >
> Yes, it is a bad naming convention. Can we pick some other character to
> indicate that the store is shared ? The "!" was meant to indicate that
> the store is essentially the same, but this contradicts with the usual
> Lisp convention.
>
> > It seems that e and d now both refer to the same storage.  So if I
> > modify e, d will magically change?  That's expected, but once e is
> > created, it becomes very easy to lose track of the fact that it is a
> > submatrix of d, especially at the repl.  I think we need to make the
> > relationship more explicit.  Maybe create a new class that is a subclass
> > of matrix (or whatever) that adds a slot that holds a reference to the
> > matrix.  Kind of like how in lisp you can have displaced arrays, and you
> > can tell it's displaced and can chase down all the way to the final,
> > non-displaced array if you want to.
> That sounds reasonable, shouldn't be too hard to do.
>

I think if you do this, then you don't need any special naming convention.
sub-matrix creates a submatrix of the given matrix, and the type
(submatrix) tells us instantly that something is shared.  And we can, if we
want to, chase down what matrix we're a submatrix of.  I can imagine
submatrices of submatrices of ....

Actually, we wouldn't even have to share the actual store.  Just specialize
the matrix-ref methods to do the right thing.  But for speed, it's probably
better to share the store slot.

I didn't think through all of this yet, though.  But I think it's a
requirement that we somehow be able to find out what "parent" matrix is of
the submatrix.  Otherwise, it will be a great source of obscure bugs like
when you unexpectedly share list structure.


>
> >
> > But don't get me wrong.  Real submatrices are really, really cool!
> >
> > BTW, can you merge the master branch to the matlisp-cffi branch?  There
> > are a few changes that I need to build correctly.  I tried myself, but
> > there's a conflict which I'm not confident in resolving on my own.
> Yes this is done now. I didn't get any conflicts though ?
>
>
My fault probably.  I thought I did clean out my branch before doing that.
Anyway, I've pulled the latest matlisp-cffi so I'll try it out again.

Thanks,

Ray

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362

[Akshay S. <aks...@gm...>]

On 03/18/2012 11:15 PM, Raymond Toy wrote:
> On 3/17/12 4:09 AM, Akshay Srinivasan wrote:
> 
> -matlisp-commit
> +matlisp-devel
>> ;;Create a 4x4 matrix with random entries
>> (defvar d (make-complex-matrix 4 4))
>>
>> (dotimes (i 4)
>>   (dotimes (j 4)
>>    (setf (matrix-ref-2d d i j)
>>          (complex-coerce (complex (cl:random 10) (cl:random 10))))))
> There's a rand() function, but it currently doesn't work because
> :row-stride is unbound.
> 
> Is there a reason why these are unbound?   Isn't there some suitable
> default for this, assuming we're creating a regular full matrix?
The defaults for :row-stride and :col-stride should be ((ncols mat), 1)
for row-major and (1, (nrows mat)) for col-major. I can probably add
this into :before initialize-instance method, but I don't think that's a
good thing.

The store index is now given by:
head + row-stride * i + col-stride * j

> Can we also fix the issue in mtimes and the autoswap thing?  I'm not
> exactly sure what you're trying to do, but if you explain it to me, I
> can probably help with that.
Hmm, I'm not sure what it's doing either.
I haven't touched mtimes yet, so its very likely the same version which
is in master, the *1x1*-.. is now unbound, which will probably lead to
errors.

> 
>> ;;Submatrix of d starting at (1, 1) or size (2, 2)
>> (defvar e (sub! d 1 1 2 2))
> We should pick a better name than sub!, like maybe sub-matrix!.  And
> what does the ! mean here?  The intention for "!" is to mean a
> destructive operation so does sub! destructively modify d to make a
> submatrix?  And what would that actually mean?  If it's not destructive,
> then don't use "!".
> 
Yes, it is a bad naming convention. Can we pick some other character to
indicate that the store is shared ? The "!" was meant to indicate that
the store is essentially the same, but this contradicts with the usual
Lisp convention.

> It seems that e and d now both refer to the same storage.  So if I
> modify e, d will magically change?  That's expected, but once e is
> created, it becomes very easy to lose track of the fact that it is a
> submatrix of d, especially at the repl.  I think we need to make the
> relationship more explicit.  Maybe create a new class that is a subclass
> of matrix (or whatever) that adds a slot that holds a reference to the
> matrix.  Kind of like how in lisp you can have displaced arrays, and you
> can tell it's displaced and can chase down all the way to the final,
> non-displaced array if you want to.
That sounds reasonable, shouldn't be too hard to do.

> 
> But don't get me wrong.  Real submatrices are really, really cool!
> 
> BTW, can you merge the master branch to the matlisp-cffi branch?  There
> are a few changes that I need to build correctly.  I tried myself, but
> there's a conflict which I'm not confident in resolving on my own.
Yes this is done now. I didn't get any conflicts though ?

Akshay

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch matlisp-cffi updated. 2012-02-23-57-g6173362

[Raymond T. <toy...@gm...>]

On 3/17/12 4:09 AM, Akshay Srinivasan wrote:

-matlisp-commit
+matlisp-devel
> ;;Create a 4x4 matrix with random entries
> (defvar d (make-complex-matrix 4 4))
>
> (dotimes (i 4)
>   (dotimes (j 4)
>    (setf (matrix-ref-2d d i j)
>          (complex-coerce (complex (cl:random 10) (cl:random 10))))))
There's a rand() function, but it currently doesn't work because
:row-stride is unbound.

Is there a reason why these are unbound?   Isn't there some suitable
default for this, assuming we're creating a regular full matrix?

Can we also fix the issue in mtimes and the autoswap thing?  I'm not
exactly sure what you're trying to do, but if you explain it to me, I
can probably help with that.

> ;;Submatrix of d starting at (1, 1) or size (2, 2)
> (defvar e (sub! d 1 1 2 2))
We should pick a better name than sub!, like maybe sub-matrix!.  And
what does the ! mean here?  The intention for "!" is to mean a
destructive operation so does sub! destructively modify d to make a
submatrix?  And what would that actually mean?  If it's not destructive,
then don't use "!".

It seems that e and d now both refer to the same storage.  So if I
modify e, d will magically change?  That's expected, but once e is
created, it becomes very easy to lose track of the fact that it is a
submatrix of d, especially at the repl.  I think we need to make the
relationship more explicit.  Maybe create a new class that is a subclass
of matrix (or whatever) that adds a slot that holds a reference to the
matrix.  Kind of like how in lisp you can have displaced arrays, and you
can tell it's displaced and can chase down all the way to the final,
non-displaced array if you want to.

But don't get me wrong.  Real submatrices are really, really cool!

BTW, can you merge the master branch to the matlisp-cffi branch?  There
are a few changes that I need to build correctly.  I tried myself, but
there's a conflict which I'm not confident in resolving on my own.

Thanks for your work,

Ray

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Akshay S. <aks...@gm...>]

On 03/14/2012 08:49 AM, Akshay Srinivasan wrote:
> On 03/14/2012 07:30 AM, Raymond Toy wrote:
>> On 3/13/12 9:45 AM, Akshay Srinivasan wrote:
>>> On 03/12/2012 12:18 AM, Raymond Toy wrote:
>>>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>>>>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>>>>> 
>>>>>>>>>> It would be nice to be able to detect either
>>>>>>>>>> mode and have the ffi do the right thing, but I
>>>>>>>>>> think many lisps do not support structure returns
>>>>>>>>>> the way gcc is doing it now.
>>>>>>>>> It returns a struct ? I never could get hold of the
>>>>>>>>>  documentation for that.
>>>>>>>> That's my understanding.  And when I look at the 
>>>>>>>> disassembly for a simple Fortran function, it
>>>>>>>> returns the real and imaginary parts in xmm0 and xmm1
>>>>>>>> (at least on OSX).
>>>>>>> Hmm. Too clumsy and non-portable to support all that,
>>>>>>> no ?
>>>>>> It would be good if cffi supported that, but I suspect 
>>>>>> not.
>>>>>>>>>> We also have an alternative: Add simple C
>>>>>>>>>> wrappers that use the f2c-mode return and call
>>>>>>>>>> the Fortran routine directly.
>>>>>>>>> CBLAS :) (not the netlib version).
>>>>> After some more thinking, I vote for adding wrapper 
>>>>> subroutine around zdotu/zdotc in F77. It'll be far too
>>>>> much boring work to migrate to CBLAS, given that I seem to
>>>>> be able to handle ordering quite well within lisp itself.
>>>>> There aren't any other complex returning functions in BLAS,
>>>>> are there ?
>>>> Let me do a grep....Nope.  Looks like those are the only
>>>> two.
>>>> 
>>>> Not quite sure what you're going to do here.  You want to
>>>> write two C wrapper functions that call zdotu/zdotc
>>>> correctly, and have the wrapper use the f2c convention?
>>>> 
>>>> Since we already detect if we need -ff2c, what is the
>>>> utility for this when matlisp builds its own libraries?  Of
>>>> course, for atlas, I can see that we would want this if we've
>>>> determined that atlas is not compatible.  That would be a
>>>> nice enhancement.
>>>>> We probably don't need any other f2c features, since most 
>>>>> functions I know only take character arguments instead of 
>>>>> string ones.
>>>> Fortunately, matlisp is in control of that because I think
>>>> it is valid fortran to pass in, say, 'Transpose', instead of
>>>> 'T'.
>>> I have to flip back on my words. I now think CBLAS is the only 
>>> way forward. I was writing a wrapper for dgemv (y <- alpha * A
>>> . x + beta y) today and really couldn't figure out a way to
>>> support row-ordered
>> 
>> Can you give an example?  You can't just transpose A?  Oh.
>> Maybe not because the elements still need to be in column-major
>> order?
> 
> That will only work when A is square though.
Sorry I should've thought this through, more carfully. Yes transpose
will actually do the trick. I guess we don't need CBLAS after all.

I found the source code of:
http://netlib.org/blas/blast-forum/cblas.tgz
useful.

zdotc/zdotu works beautifully by the way (with and without ATLAS).

Akshay

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Akshay S. <aks...@gm...>]

On 03/14/2012 07:30 AM, Raymond Toy wrote:
> On 3/13/12 9:45 AM, Akshay Srinivasan wrote:
>> On 03/12/2012 12:18 AM, Raymond Toy wrote:
>>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>>>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>>>> 
>>>>>>>>> It would be nice to be able to detect either mode
>>>>>>>>> and have the ffi do the right thing, but I think
>>>>>>>>> many lisps do not support structure returns the way
>>>>>>>>> gcc is doing it now.
>>>>>>>> It returns a struct ? I never could get hold of the 
>>>>>>>> documentation for that.
>>>>>>> That's my understanding.  And when I look at the 
>>>>>>> disassembly for a simple Fortran function, it returns
>>>>>>> the real and imaginary parts in xmm0 and xmm1 (at least
>>>>>>> on OSX).
>>>>>> Hmm. Too clumsy and non-portable to support all that, no
>>>>>> ?
>>>>> It would be good if cffi supported that, but I suspect
>>>>> not.
>>>>>>>>> We also have an alternative: Add simple C wrappers 
>>>>>>>>> that use the f2c-mode return and call the Fortran 
>>>>>>>>> routine directly.
>>>>>>>> CBLAS :) (not the netlib version).
>>>> After some more thinking, I vote for adding wrapper
>>>> subroutine around zdotu/zdotc in F77. It'll be far too much
>>>> boring work to migrate to CBLAS, given that I seem to be able
>>>> to handle ordering quite well within lisp itself. There
>>>> aren't any other complex returning functions in BLAS, are
>>>> there ?
>>> Let me do a grep....Nope.  Looks like those are the only two.
>>> 
>>> Not quite sure what you're going to do here.  You want to write
>>> two C wrapper functions that call zdotu/zdotc correctly, and
>>> have the wrapper use the f2c convention?
>>> 
>>> Since we already detect if we need -ff2c, what is the utility
>>> for this when matlisp builds its own libraries?  Of course, for
>>> atlas, I can see that we would want this if we've determined
>>> that atlas is not compatible.  That would be a nice
>>> enhancement.
>>>> We probably don't need any other f2c features, since most 
>>>> functions I know only take character arguments instead of
>>>> string ones.
>>> Fortunately, matlisp is in control of that because I think it
>>> is valid fortran to pass in, say, 'Transpose', instead of 'T'.
>> I have to flip back on my words. I now think CBLAS is the only
>> way forward. I was writing a wrapper for dgemv (y <- alpha * A .
>> x + beta y) today and really couldn't figure out a way to support
>> row-ordered
> 
> Can you give an example?  You can't just transpose A?  Oh.  Maybe
> not because the elements still need to be in column-major order?

That will only work when A is square though.

Akshay

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Raymond T. <toy...@gm...>]

On 3/13/12 9:45 AM, Akshay Srinivasan wrote:
> On 03/12/2012 12:18 AM, Raymond Toy wrote:
>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>>>
>>>>>>>> It would be nice to be able to detect either mode and
>>>>>>>> have the ffi do the right thing, but I think many lisps
>>>>>>>> do not support structure returns the way gcc is doing
>>>>>>>> it now.
>>>>>>> It returns a struct ? I never could get hold of the 
>>>>>>> documentation for that.
>>>>>> That's my understanding.  And when I look at the
>>>>>> disassembly for a simple Fortran function, it returns the
>>>>>> real and imaginary parts in xmm0 and xmm1 (at least on
>>>>>> OSX).
>>>>> Hmm. Too clumsy and non-portable to support all that, no ?
>>>> It would be good if cffi supported that, but I suspect not.
>>>>>>>> We also have an alternative: Add simple C wrappers
>>>>>>>> that use the f2c-mode return and call the Fortran
>>>>>>>> routine directly.
>>>>>>> CBLAS :) (not the netlib version).
>>> After some more thinking, I vote for adding wrapper subroutine
>>> around zdotu/zdotc in F77. It'll be far too much boring work to
>>> migrate to CBLAS, given that I seem to be able to handle ordering
>>> quite well within lisp itself. There aren't any other complex
>>> returning functions in BLAS, are there ?
>> Let me do a grep....Nope.  Looks like those are the only two.
>>
>> Not quite sure what you're going to do here.  You want to write two
>> C wrapper functions that call zdotu/zdotc correctly, and have the
>> wrapper use the f2c convention?
>>
>> Since we already detect if we need -ff2c, what is the utility for
>> this when matlisp builds its own libraries?  Of course, for atlas,
>> I can see that we would want this if we've determined that atlas is
>> not compatible.  That would be a nice enhancement.
>>> We probably don't need any other f2c features, since most
>>> functions I know only take character arguments instead of string
>>> ones.
>> Fortunately, matlisp is in control of that because I think it is
>> valid fortran to pass in, say, 'Transpose', instead of 'T'.
> I have to flip back on my words. I now think CBLAS is the only way
> forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta
> y) today and really couldn't figure out a way to support row-ordered
> matrices; to do this I will have to use dgemm at best to doing it
> completely in lisp at worst. This is bad because, I can't use gemv to
> support sliced matrices in gemm!
>
> I do think it is worth the trouble now, given that I will be able
> support a lot of matrix-slicey things with access to the order switch
> which is provided by CBLAS functions.
>
Point me to the version of cblas you want to use.  I'll do the work to
get the library built.  I'll leave the interface changes to you (if they
need to be changed).

Ray

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Raymond T. <toy...@gm...>]

On 3/13/12 9:45 AM, Akshay Srinivasan wrote:
> On 03/12/2012 12:18 AM, Raymond Toy wrote:
>> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>>>
>>>>>>>> It would be nice to be able to detect either mode and
>>>>>>>> have the ffi do the right thing, but I think many lisps
>>>>>>>> do not support structure returns the way gcc is doing
>>>>>>>> it now.
>>>>>>> It returns a struct ? I never could get hold of the 
>>>>>>> documentation for that.
>>>>>> That's my understanding.  And when I look at the
>>>>>> disassembly for a simple Fortran function, it returns the
>>>>>> real and imaginary parts in xmm0 and xmm1 (at least on
>>>>>> OSX).
>>>>> Hmm. Too clumsy and non-portable to support all that, no ?
>>>> It would be good if cffi supported that, but I suspect not.
>>>>>>>> We also have an alternative: Add simple C wrappers
>>>>>>>> that use the f2c-mode return and call the Fortran
>>>>>>>> routine directly.
>>>>>>> CBLAS :) (not the netlib version).
>>> After some more thinking, I vote for adding wrapper subroutine
>>> around zdotu/zdotc in F77. It'll be far too much boring work to
>>> migrate to CBLAS, given that I seem to be able to handle ordering
>>> quite well within lisp itself. There aren't any other complex
>>> returning functions in BLAS, are there ?
>> Let me do a grep....Nope.  Looks like those are the only two.
>>
>> Not quite sure what you're going to do here.  You want to write two
>> C wrapper functions that call zdotu/zdotc correctly, and have the
>> wrapper use the f2c convention?
>>
>> Since we already detect if we need -ff2c, what is the utility for
>> this when matlisp builds its own libraries?  Of course, for atlas,
>> I can see that we would want this if we've determined that atlas is
>> not compatible.  That would be a nice enhancement.
>>> We probably don't need any other f2c features, since most
>>> functions I know only take character arguments instead of string
>>> ones.
>> Fortunately, matlisp is in control of that because I think it is
>> valid fortran to pass in, say, 'Transpose', instead of 'T'.
> I have to flip back on my words. I now think CBLAS is the only way
> forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta
> y) today and really couldn't figure out a way to support row-ordered

Can you give an example?  You can't just transpose A?  Oh.  Maybe not
because the elements still need to be in column-major order?

Ray

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Akshay S. <aks...@gm...>]

On 03/12/2012 12:18 AM, Raymond Toy wrote:
> On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
>> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>> 
>>>>>>> It would be nice to be able to detect either mode and
>>>>>>> have the ffi do the right thing, but I think many lisps
>>>>>>> do not support structure returns the way gcc is doing
>>>>>>> it now.
>>>>>> It returns a struct ? I never could get hold of the 
>>>>>> documentation for that.
>>>>> That's my understanding.  And when I look at the
>>>>> disassembly for a simple Fortran function, it returns the
>>>>> real and imaginary parts in xmm0 and xmm1 (at least on
>>>>> OSX).
>>>> Hmm. Too clumsy and non-portable to support all that, no ?
>>> It would be good if cffi supported that, but I suspect not.
>>>>>>> We also have an alternative: Add simple C wrappers
>>>>>>> that use the f2c-mode return and call the Fortran
>>>>>>> routine directly.
>>>>>> CBLAS :) (not the netlib version).
>> After some more thinking, I vote for adding wrapper subroutine
>> around zdotu/zdotc in F77. It'll be far too much boring work to
>> migrate to CBLAS, given that I seem to be able to handle ordering
>> quite well within lisp itself. There aren't any other complex
>> returning functions in BLAS, are there ?
> Let me do a grep....Nope.  Looks like those are the only two.
> 
> Not quite sure what you're going to do here.  You want to write two
> C wrapper functions that call zdotu/zdotc correctly, and have the
> wrapper use the f2c convention?
> 
> Since we already detect if we need -ff2c, what is the utility for
> this when matlisp builds its own libraries?  Of course, for atlas,
> I can see that we would want this if we've determined that atlas is
> not compatible.  That would be a nice enhancement.
>> 
>> We probably don't need any other f2c features, since most
>> functions I know only take character arguments instead of string
>> ones.
> Fortunately, matlisp is in control of that because I think it is
> valid fortran to pass in, say, 'Transpose', instead of 'T'.

I have to flip back on my words. I now think CBLAS is the only way
forward. I was writing a wrapper for dgemv (y <- alpha * A . x + beta
y) today and really couldn't figure out a way to support row-ordered
matrices; to do this I will have to use dgemm at best to doing it
completely in lisp at worst. This is bad because, I can't use gemv to
support sliced matrices in gemm!

I do think it is worth the trouble now, given that I will be able
support a lot of matrix-slicey things with access to the order switch
which is provided by CBLAS functions.

What do you think ?

Akshay

Re: [Matlisp-devel] How expensive is CLOS object creation ?

[Raymond T. <toy...@gm...>]

On 3/12/12 10:18 AM, Akshay Srinivasan wrote:
> Hi,
> 	Now that I have a reasonable amount of support for matrix slices (and
> more). I can now do neat stuff like
>
> ? (defvar a (make-complex-matrix 2 2))
> ;; Get the second column
> ? (defvar e (make-sub-matrix a 0 1 2 1))
> ;; Set the imaginary part of the second column to pi
> ? (copy! pi (imagpart! e))

This is pretty cool stuff!
>
> without without ever having to copy the store. I guess this is okay
> for user interaction; but I guess there are costs involved with
> creating new CLOS objects though. Should this sort of stuff be avoided
> inside core functions then ?

I think it really depends on the clos implementation.  I would say for
now to just ignore it unless you're creating lots of clos objects in a
tight loop.  That's probably not a good idea, plus that generates a lot
of garbage.

Ray

>
> Akshay
>
> P.S: I will merge my changes and push things to matlisp-cffi, after
> sending this mail.
>

[Matlisp-devel] How expensive is CLOS object creation ?

[Akshay S. <aks...@gm...>]

Hi,
	Now that I have a reasonable amount of support for matrix slices (and
more). I can now do neat stuff like

? (defvar a (make-complex-matrix 2 2))
;; Get the second column
? (defvar e (make-sub-matrix a 0 1 2 1))
;; Set the imaginary part of the second column to pi
? (copy! pi (imagpart! e))

without without ever having to copy the store. I guess this is okay
for user interaction; but I guess there are costs involved with
creating new CLOS objects though. Should this sort of stuff be avoided
inside core functions then ?

Akshay

P.S: I will merge my changes and push things to matlisp-cffi, after
sending this mail.

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Akshay S. <aks...@gm...>]

>> After some more thinking, I vote for adding wrapper subroutine
>> around zdotu/zdotc in F77. It'll be far too much boring work to
>> migrate to CBLAS, given that I seem to be able to handle ordering
>> quite well within lisp itself. There aren't any other complex
>> returning functions in BLAS, are there ?
> Let me do a grep....Nope.  Looks like those are the only two.
> 
> Not quite sure what you're going to do here.  You want to write two
> C wrapper functions that call zdotu/zdotc correctly, and have the
> wrapper use the f2c convention?
No the wrapper will be in F77, which will be a subroutine working like
the f2c version (or the CBLAS version).

> 
> Since we already detect if we need -ff2c, what is the utility for
> this when matlisp builds its own libraries?  Of course, for atlas,
> I can see that we would want this if we've determined that atlas is
> not compatible.  That would be a nice enhancement.
Yes, but If we have the wrapper, we don't have to bother with -ff2c
flag anymore, and also be able to use ATLAS at the same time without
doing much else.

Doing it only when we've determined ATLAS doesn't work the way we
want, will involve, I think, changing bits of the function definitions
of zdotc/zdotu in src/blas.lisp during the build.

>> 
>> We probably don't need any other f2c features, since most
>> functions I know only take character arguments instead of string
>> ones.
> Fortunately, matlisp is in control of that because I think it is
> valid fortran to pass in, say, 'Transpose', instead of 'T'.
That might only be because Fortran only reads the first character of
the string (?).

Akshay

Re: [Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Raymond T. <toy...@gm...>]

On 3/11/12 11:13 AM, Akshay Srinivasan wrote:
> On 03/11/2012 11:24 PM, Raymond Toy wrote:
>> On 3/10/12 7:20 PM, Akshay Srinivasan wrote:
>>> On 03/11/2012 08:21 AM, Raymond Toy wrote:
>>>> On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
>>>>> On 03/10/2012 10:54 PM, Raymond Toy wrote: Dang.  You're
>>>>> right. I read the description of *f-l-d* backwards. I think
>>>>> your solution is probably the right one, and we should add
>>>>> @libdir@ to all the library paths.
>>>>>
>>>>> I think the backward description makes more sense. Oh well.
>>>>> Added @libdir@ to all the library paths.
>>>>>
>>>> Unfortunately, this breaks matlisp for me on osx.  It tries to
>>>> load the library but can't find all the dependent fortran
>>>> libraries so it dies because of missing symbols.
>>> That's odd. Are you using gfortran ? BLAS compiled with gfortran
>>> on my machine looks like it has already been linked with the
>>> gfortran stuff.
>> Looks like an issue on Darwin (OSX).  Same thing happens with cmucl
>> and ccl.  For both, I used gfortran to build the code.  On linux
>> and sparc, ldd shows that the libraries include dependencies on the
>> fortran libraries.  On darwin, otool -L shows only the dependency
>> on libSystem.
>>
>> So, perhaps this is a bug in automake/autotools in building shared 
>> libraries on OSX.
>>
>> For now, I've worked around this by adding a :darwin feature to 
>> define-foreign-library.  Works fine on OSX, linux, and sparc.
> That reassures our faith in CFFI :)
>
>
Of course, if you use OSX and have the libraries somewhere else, this
issue will bite you.  I don't have that problem, so I'm ignoring it for now.

Also, I took a closer look at how the libraries are built.  Pretty much
the same command is used on linux and osx, and I can see that the shared
library is built with -L and -l options to specify the fortran
libraries.  But for whatever reason the information isn't (explicitly)
recorded in the lib.  At least otool doesn't show it, but, of course,
the fortran libraries do eventually get linked.  Not sure how that
works, though.

Ray

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Raymond T. <toy...@gm...>]

On 3/11/12 11:11 AM, Akshay Srinivasan wrote:
> On 03/11/2012 12:37 PM, Raymond Toy wrote:
>> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>>>
>>>>>> It would be nice to be able to detect either mode and have 
>>>>>> the ffi do the right thing, but I think many lisps do not 
>>>>>> support structure returns the way gcc is doing it now.
>>>>> It returns a struct ? I never could get hold of the 
>>>>> documentation for that.
>>>> That's my understanding.  And when I look at the disassembly 
>>>> for a simple Fortran function, it returns the real and 
>>>> imaginary parts in xmm0 and xmm1 (at least on OSX).
>>> Hmm. Too clumsy and non-portable to support all that, no ?
>> It would be good if cffi supported that, but I suspect not.
>>>>>> We also have an alternative: Add simple C wrappers that
>>>>>> use the f2c-mode return and call the Fortran routine
>>>>>> directly.
>>>>> CBLAS :) (not the netlib version).
> After some more thinking, I vote for adding wrapper subroutine around
> zdotu/zdotc in F77. It'll be far too much boring work to migrate to
> CBLAS, given that I seem to be able to handle ordering quite well
> within lisp itself. There aren't any other complex returning functions
> in BLAS, are there ?
Let me do a grep....Nope.  Looks like those are the only two.

Not quite sure what you're going to do here.  You want to write two C
wrapper functions that call zdotu/zdotc correctly, and have the wrapper
use the f2c convention?

Since we already detect if we need -ff2c, what is the utility for this
when matlisp builds its own libraries?  Of course, for atlas, I can see
that we would want this if we've determined that atlas is not
compatible.  That would be a nice enhancement.
>
> We probably don't need any other f2c features, since most functions I
> know only take character arguments instead of string ones.
Fortunately, matlisp is in control of that because I think it is valid
fortran to pass in, say, 'Transpose', instead of 'T'.

Ray

 

Re: [Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Akshay S. <aks...@gm...>]

On 03/11/2012 11:24 PM, Raymond Toy wrote:
> On 3/10/12 7:20 PM, Akshay Srinivasan wrote:
>> On 03/11/2012 08:21 AM, Raymond Toy wrote:
>>> On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
>>>> On 03/10/2012 10:54 PM, Raymond Toy wrote: Dang.  You're
>>>> right. I read the description of *f-l-d* backwards. I think
>>>> your solution is probably the right one, and we should add
>>>> @libdir@ to all the library paths.
>>>> 
>>>> I think the backward description makes more sense. Oh well.
>>>> Added @libdir@ to all the library paths.
>>>> 
>>> Unfortunately, this breaks matlisp for me on osx.  It tries to
>>> load the library but can't find all the dependent fortran
>>> libraries so it dies because of missing symbols.
>> That's odd. Are you using gfortran ? BLAS compiled with gfortran
>> on my machine looks like it has already been linked with the
>> gfortran stuff.
> Looks like an issue on Darwin (OSX).  Same thing happens with cmucl
> and ccl.  For both, I used gfortran to build the code.  On linux
> and sparc, ldd shows that the libraries include dependencies on the
> fortran libraries.  On darwin, otool -L shows only the dependency
> on libSystem.
> 
> So, perhaps this is a bug in automake/autotools in building shared 
> libraries on OSX.
> 
> For now, I've worked around this by adding a :darwin feature to 
> define-foreign-library.  Works fine on OSX, linux, and sparc.
That reassures our faith in CFFI :)

Akshay

Re: [Matlisp-devel] BLAS (was Matlisp tests)

[Akshay S. <aks...@gm...>]

On 03/11/2012 12:37 PM, Raymond Toy wrote:
> On 3/10/12 7:03 PM, Akshay Srinivasan wrote:
>> On 03/10/2012 11:16 PM, Raymond Toy wrote:
>>> On 3/10/12 8:40 AM, Akshay Srinivasan wrote:
>>> 
>>>>> It would be nice to be able to detect either mode and have 
>>>>> the ffi do the right thing, but I think many lisps do not 
>>>>> support structure returns the way gcc is doing it now.
>>>> It returns a struct ? I never could get hold of the 
>>>> documentation for that.
>>> That's my understanding.  And when I look at the disassembly 
>>> for a simple Fortran function, it returns the real and 
>>> imaginary parts in xmm0 and xmm1 (at least on OSX).
>> Hmm. Too clumsy and non-portable to support all that, no ?
> It would be good if cffi supported that, but I suspect not.
>> 
>>>>> We also have an alternative: Add simple C wrappers that
>>>>> use the f2c-mode return and call the Fortran routine
>>>>> directly.
>>>> CBLAS :) (not the netlib version).
After some more thinking, I vote for adding wrapper subroutine around
zdotu/zdotc in F77. It'll be far too much boring work to migrate to
CBLAS, given that I seem to be able to handle ordering quite well
within lisp itself. There aren't any other complex returning functions
in BLAS, are there ?

We probably don't need any other f2c features, since most functions I
know only take character arguments instead of string ones.

Akshay

Re: [Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Raymond T. <toy...@gm...>]

On 3/10/12 7:20 PM, Akshay Srinivasan wrote:
> On 03/11/2012 08:21 AM, Raymond Toy wrote:
>> On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
>>> On 03/10/2012 10:54 PM, Raymond Toy wrote: Dang.  You're right.
>>> I read the description of *f-l-d* backwards. I think your
>>> solution is probably the right one, and we should add @libdir@ to
>>> all the library paths.
>>>
>>> I think the backward description makes more sense. Oh well. Added
>>> @libdir@ to all the library paths.
>>>
>> Unfortunately, this breaks matlisp for me on osx.  It tries to load
>> the library but can't find all the dependent fortran libraries so
>> it dies because of missing symbols.
> That's odd. Are you using gfortran ? BLAS compiled with gfortran on my
> machine looks like it has already been linked with the gfortran stuff.
Looks like an issue on Darwin (OSX).  Same thing happens with cmucl and
ccl.  For both, I used gfortran to build the code.  On linux and sparc,
ldd shows that the libraries include dependencies on the fortran
libraries.  On darwin, otool -L shows only the dependency on libSystem.

So, perhaps this is a bug in automake/autotools in building shared
libraries on OSX.

For now, I've worked around this by adding a :darwin feature to
define-foreign-library.  Works fine on OSX, linux, and sparc.

Ray

Re: [Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Akshay S. <aks...@gm...>]

On 03/11/2012 08:21 AM, Raymond Toy wrote:
> On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
>> On 03/10/2012 10:54 PM, Raymond Toy wrote: Dang.  You're right.
>> I read the description of *f-l-d* backwards. I think your
>> solution is probably the right one, and we should add @libdir@ to
>> all the library paths.
>> 
>> I think the backward description makes more sense. Oh well. Added
>> @libdir@ to all the library paths.
>> 
> Unfortunately, this breaks matlisp for me on osx.  It tries to load
> the library but can't find all the dependent fortran libraries so
> it dies because of missing symbols.
That's odd. Are you using gfortran ? BLAS compiled with gfortran on my
machine looks like it has already been linked with the gfortran stuff.

I wonder if this has something do with *darwin-framework-directories*
in cffi. I'm not sure what it means though.

> 
> I think the only option we have is to undo this and set
> LD_LIBRARY_PATH to include libdir.  This will work if you use make.
> If you do something else, this won't.  We could add a script,
> matlisp, that sets up LD_LIBRARY_PATH correctly and runs the
> appropriate lisp.
I'm not happy with that because then it won't work, when loading
matlisp on slime, unless I remember to set the LD_LIBRARY_PATH before
actually opening Emacs. Can't we just set LD_LIBRARY_PATH through
(run-system ..) inside start.lisp ?

Akshay

[Matlisp-devel] foreign-library-directories (Was Re: [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8)

[Raymond T. <toy...@gm...>]

On 3/10/12 9:35 AM, Akshay Srinivasan wrote:
> On 03/10/2012 10:54 PM, Raymond Toy wrote:
> Dang.  You're right.  I read the description of *f-l-d* backwards.
> I think your solution is probably the right one, and we should add 
> @libdir@ to all the library paths.
>
> I think the backward description makes more sense. Oh well.
> Added @libdir@ to all the library paths.
>
Unfortunately, this breaks matlisp for me on osx.  It tries to load the
library but can't find all the dependent fortran libraries so it dies
because of missing symbols.

I think the only option we have is to undo this and set LD_LIBRARY_PATH
to include libdir.  This will work if you use make.  If you do something
else, this won't.  We could add a script, matlisp, that sets up
LD_LIBRARY_PATH correctly and runs the appropriate lisp.

What do you think?

Ray

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Akshay S. <aks...@gm...>]

On 03/10/2012 10:54 PM, Raymond Toy wrote:
> On 3/10/12 9:12 AM, Akshay Srinivasan wrote:
>> On 03/10/2012 10:24 PM, Raymond Toy wrote:
>> 
>> This is apparently the way its supposed to work.
>>> From cffi/src/libraries.lisp :
>> ------------------------------------------------------------------------
>>
>> 
;;; Only after failing to find a library through the normal ways
>> ;;; (eg: on Linux LD_LIBRARY_PATH, /etc/ld.so.cache, /usr/lib/,
>> /lib) ;;; do we try to find the library ourselves. 
>> ------------------------------------------------------------------------
>>
>
>> 
> Dang.  You're right.  I read the description of *f-l-d* backwards.
> I think your solution is probably the right one, and we should add 
> @libdir@ to all the library paths.
> 

I think the backward description makes more sense. Oh well.
Added @libdir@ to all the library paths.

Akshay

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Raymond T. <toy...@gm...>]

On 3/10/12 9:12 AM, Akshay Srinivasan wrote:
> On 03/10/2012 10:24 PM, Raymond Toy wrote:
>
> This is apparently the way its supposed to work.
> >From cffi/src/libraries.lisp :
> ------------------------------------------------------------------------
> ;;; Only after failing to find a library through the normal ways
> ;;; (eg: on Linux LD_LIBRARY_PATH, /etc/ld.so.cache, /usr/lib/, /lib)
> ;;; do we try to find the library ourselves.
> ------------------------------------------------------------------------
>

Dang.  You're right.  I read the description of *f-l-d* backwards.  I
think your solution is probably the right one, and we should add
@libdir@ to all the library paths.

Ray

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Akshay S. <aks...@gm...>]

On 03/10/2012 10:24 PM, Raymond Toy wrote:
> On 3/10/12 8:36 AM, Akshay Srinivasan wrote:
>> On 03/10/2012 10:02 PM, Raymond Toy wrote:
>>> On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
>>>> This is an automated email from the git hooks/post-receive 
>>>> script. It was generated because a ref change was pushed to
>>>> the repository containing the project "matlisp".
>>>> 
>>>> The branch, master has been updated via 
>>>> b4755e861709360bf208f0b9b479c388003274de (commit) from 
>>>> 035339c307401f593732418ecdba8fa6785b678d (commit)
>>>> 
>>>> Those revisions listed above that are new to this repository 
>>>> have not appeared on any other notification email; so we
>>>> list those revisions in full, below.
>>>> 
>>>> - Log 
>>>> -----------------------------------------------------------------
>>>>
>>>>
>>
>>>> 
commit b4755e861709360bf208f0b9b479c388003274de
>>>> Author: Akshay Srinivasan <aks...@gm...> Date: 
>>>> Sat Mar 10 21:13:48 2012 +0530
>>>> 
>>>> Made sure that CFFI loads our version of BLAS, when it is
>>>> asked to.
>>>> 
>>>> diff --git a/lib/lazy-loader.lisp.in
>>>> b/lib/lazy-loader.lisp.in index 11f3358..f67b5d0 100644 ---
>>>> a/lib/lazy-loader.lisp.in +++ b/lib/lazy-loader.lisp.in @@
>>>> -140,7 +140,7 @@ (unless @ATLAS_P@ ;; Use our blas and lapack
>>>> libraries (cffi:define-foreign-library blas -    (t (:default
>>>> "libblas")))) +    (t (:default "@libdir@/libblas"))))
>>>> 
>>> Somehow this doesn't look right.  Shouldn't cffi be looking in
>>>  *foreign-libraries-directories* first?  Is that not set up 
>>> correctly?
>> Doesn't look like it does. If I use the old version of the 
>> lazy-loader.lisp the tests for zdot fail (like in the ATLAS
>> build). Are you sure your version of CFFI isn't doing the same ?
>> 
>> I agree that it should look at *foreign-libraries-directories*
>> first; should report this as bug to CFFI.
>> 
> I'm almost 100% sure it's working.  Previously, *f-l-d* was set to 
> "lib/".  When I tried loading start.lisp from a lisp started from
> some other directory, loading the libraries failed.  When I changed
> *f-l-d* to the full path, I could load the libraries.
> 
> So make sure *f-l-d* has the full path to the matlisp lib
> directory. That should work.  Or temporarily rename the blas
> library in /usr/lib and see what's happening.
> 

This is apparently the way its supposed to work.
>From cffi/src/libraries.lisp :
------------------------------------------------------------------------
;;; Only after failing to find a library through the normal ways
;;; (eg: on Linux LD_LIBRARY_PATH, /etc/ld.so.cache, /usr/lib/, /lib)
;;; do we try to find the library ourselves.
------------------------------------------------------------------------


Akshay

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Akshay S. <aks...@gm...>]

On 03/10/2012 10:24 PM, Raymond Toy wrote:
> On 3/10/12 8:36 AM, Akshay Srinivasan wrote:
>> On 03/10/2012 10:02 PM, Raymond Toy wrote:
>>> On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
>>>> This is an automated email from the git hooks/post-receive 
>>>> script. It was generated because a ref change was pushed to
>>>> the repository containing the project "matlisp".
>>>> 
>>>> The branch, master has been updated via 
>>>> b4755e861709360bf208f0b9b479c388003274de (commit) from 
>>>> 035339c307401f593732418ecdba8fa6785b678d (commit)
>>>> 
>>>> Those revisions listed above that are new to this repository 
>>>> have not appeared on any other notification email; so we
>>>> list those revisions in full, below.
>>>> 
>>>> - Log 
>>>> -----------------------------------------------------------------
>>>>
>>>>
>>
>>>> 
commit b4755e861709360bf208f0b9b479c388003274de
>>>> Author: Akshay Srinivasan <aks...@gm...> Date: 
>>>> Sat Mar 10 21:13:48 2012 +0530
>>>> 
>>>> Made sure that CFFI loads our version of BLAS, when it is
>>>> asked to.
>>>> 
>>>> diff --git a/lib/lazy-loader.lisp.in
>>>> b/lib/lazy-loader.lisp.in index 11f3358..f67b5d0 100644 ---
>>>> a/lib/lazy-loader.lisp.in +++ b/lib/lazy-loader.lisp.in @@
>>>> -140,7 +140,7 @@ (unless @ATLAS_P@ ;; Use our blas and lapack
>>>> libraries (cffi:define-foreign-library blas -    (t (:default
>>>> "libblas")))) +    (t (:default "@libdir@/libblas"))))
>>>> 
>>> Somehow this doesn't look right.  Shouldn't cffi be looking in
>>>  *foreign-libraries-directories* first?  Is that not set up 
>>> correctly?
>> Doesn't look like it does. If I use the old version of the 
>> lazy-loader.lisp the tests for zdot fail (like in the ATLAS
>> build). Are you sure your version of CFFI isn't doing the same ?
>> 
>> I agree that it should look at *foreign-libraries-directories*
>> first; should report this as bug to CFFI.
>> 
> I'm almost 100% sure it's working.  Previously, *f-l-d* was set to 
> "lib/".  When I tried loading start.lisp from a lisp started from
> some other directory, loading the libraries failed.  When I changed
> *f-l-d* to the full path, I could load the libraries.
> 
> So make sure *f-l-d* has the full path to the matlisp lib
> directory. That should work.  Or temporarily rename the blas
> library in /usr/lib and see what's happening.
> 
> Ray
> 

Yes *f-l-d* has the full-path.
Using (.. (t (:default "libblas"))) as before the commit,

* Doing nothing else; zdotu/c tests fail.
* Moving /usr/lib/libblas.so to something else; all tests pass.

Akshay

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Raymond T. <toy...@gm...>]

On 3/10/12 8:36 AM, Akshay Srinivasan wrote:
> On 03/10/2012 10:02 PM, Raymond Toy wrote:
>> On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
>>> This is an automated email from the git hooks/post-receive
>>> script. It was generated because a ref change was pushed to the
>>> repository containing the project "matlisp".
>>>
>>> The branch, master has been updated via
>>> b4755e861709360bf208f0b9b479c388003274de (commit) from
>>> 035339c307401f593732418ecdba8fa6785b678d (commit)
>>>
>>> Those revisions listed above that are new to this repository
>>> have not appeared on any other notification email; so we list
>>> those revisions in full, below.
>>>
>>> - Log
>>> -----------------------------------------------------------------
>>>
>>>
> commit b4755e861709360bf208f0b9b479c388003274de
>>> Author: Akshay Srinivasan <aks...@gm...> Date:
>>> Sat Mar 10 21:13:48 2012 +0530
>>>
>>> Made sure that CFFI loads our version of BLAS, when it is asked
>>> to.
>>>
>>> diff --git a/lib/lazy-loader.lisp.in b/lib/lazy-loader.lisp.in 
>>> index 11f3358..f67b5d0 100644 --- a/lib/lazy-loader.lisp.in +++
>>> b/lib/lazy-loader.lisp.in @@ -140,7 +140,7 @@ (unless @ATLAS_P@ 
>>> ;; Use our blas and lapack libraries (cffi:define-foreign-library
>>> blas -    (t (:default "libblas")))) +    (t (:default
>>> "@libdir@/libblas"))))
>>>
>> Somehow this doesn't look right.  Shouldn't cffi be looking in 
>> *foreign-libraries-directories* first?  Is that not set up
>> correctly?
> Doesn't look like it does. If I use the old version of the
> lazy-loader.lisp the tests for zdot fail (like in the ATLAS build).
> Are you sure your version of CFFI isn't doing the same ?
>
> I agree that it should look at *foreign-libraries-directories* first;
> should report this as bug to CFFI.
>
I'm almost 100% sure it's working.  Previously, *f-l-d* was set to
"lib/".  When I tried loading start.lisp from a lisp started from some
other directory, loading the libraries failed.  When I changed *f-l-d*
to the full path, I could load the libraries.

So make sure *f-l-d* has the full path to the matlisp lib directory. 
That should work.  Or temporarily rename the blas library in /usr/lib
and see what's happening.

Ray

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Akshay S. <aks...@gm...>]

On 03/10/2012 10:02 PM, Raymond Toy wrote:
> On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
>> This is an automated email from the git hooks/post-receive
>> script. It was generated because a ref change was pushed to the
>> repository containing the project "matlisp".
>> 
>> The branch, master has been updated via
>> b4755e861709360bf208f0b9b479c388003274de (commit) from
>> 035339c307401f593732418ecdba8fa6785b678d (commit)
>> 
>> Those revisions listed above that are new to this repository
>> have not appeared on any other notification email; so we list
>> those revisions in full, below.
>> 
>> - Log
>> -----------------------------------------------------------------
>>
>> 
commit b4755e861709360bf208f0b9b479c388003274de
>> Author: Akshay Srinivasan <aks...@gm...> Date:
>> Sat Mar 10 21:13:48 2012 +0530
>> 
>> Made sure that CFFI loads our version of BLAS, when it is asked
>> to.
>> 
>> diff --git a/lib/lazy-loader.lisp.in b/lib/lazy-loader.lisp.in 
>> index 11f3358..f67b5d0 100644 --- a/lib/lazy-loader.lisp.in +++
>> b/lib/lazy-loader.lisp.in @@ -140,7 +140,7 @@ (unless @ATLAS_P@ 
>> ;; Use our blas and lapack libraries (cffi:define-foreign-library
>> blas -    (t (:default "libblas")))) +    (t (:default
>> "@libdir@/libblas"))))
>> 
> Somehow this doesn't look right.  Shouldn't cffi be looking in 
> *foreign-libraries-directories* first?  Is that not set up
> correctly?

Doesn't look like it does. If I use the old version of the
lazy-loader.lisp the tests for zdot fail (like in the ATLAS build).
Are you sure your version of CFFI isn't doing the same ?

I agree that it should look at *foreign-libraries-directories* first;
should report this as bug to CFFI.

Akshay

Re: [Matlisp-devel] [Matlisp-commit] [matlisp-git]matlisp branch master updated. 2012-02-23-12-gb4755e8

[Raymond T. <toy...@gm...>]

On 3/10/12 7:53 AM, Akshay Srinivasan wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "matlisp".
>
> The branch, master has been updated
>        via  b4755e861709360bf208f0b9b479c388003274de (commit)
>       from  035339c307401f593732418ecdba8fa6785b678d (commit)
>
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
>
> - Log -----------------------------------------------------------------
> commit b4755e861709360bf208f0b9b479c388003274de
> Author: Akshay Srinivasan <aks...@gm...>
> Date:   Sat Mar 10 21:13:48 2012 +0530
>
>     Made sure that CFFI loads our version of BLAS, when it is asked to.
>
> diff --git a/lib/lazy-loader.lisp.in b/lib/lazy-loader.lisp.in
> index 11f3358..f67b5d0 100644
> --- a/lib/lazy-loader.lisp.in
> +++ b/lib/lazy-loader.lisp.in
> @@ -140,7 +140,7 @@
>  (unless @ATLAS_P@
>    ;; Use our blas and lapack libraries
>    (cffi:define-foreign-library blas
> -    (t (:default "libblas"))))
> +    (t (:default "@libdir@/libblas"))))
>
Somehow this doesn't look right.  Shouldn't cffi be looking in
*foreign-libraries-directories* first?  Is that not set up correctly?

Ray