matlisp-users — General discussion list.

Re: [Matlisp-users] Trouble running matlisp on Ubuntu with Allegro

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

>>>>> "Eric" == Eric Timmons <eti...@MI...> writes:

    Eric> Hi all,
    Eric> I've managed to get matlisp working on windows, but I also need to get 

That's fantastic!  I've never personally done that and wasn't really
expecting the current version to build on windows.  Did you need to do
anything special?  If so, can you provide some hints on how to do
that?  Or better yet, if you have a sourceforge account, edit the trac
page for matlisp at http://sourceforge.net/apps/trac/matlisp.

    Eric> it working on a linux distro as well. Specifically I'm working on Ubuntu 
    Eric> 10.04 with allegro CL 8.1 (64-bit if that matters).

IIRC, the free Allegro limits are too low to build matlisp.  Are you
using the full version?

    Eric> I got the latest version of matlisp from git and followed the 
    Eric> instructions in the INSTALL file. I noticed some bugs while compiling, 
    Eric> though. The makefile attempted to install LAPACK before BLAS and it 
    Eric> (understandably) got unhappy about that. I fixed that, then I noticed 

I'll look into that and fix it soon.

    Eric> that the file libmatlisp.so wasn't actually generated so I had to change 
    Eric> lazy-loader.lisp to load libblas.so, liblapack.so, libdfftpack.so, and 
    Eric> libtoms715.so.

Yes, that's correct.  I don't have a way to test with acl, so that
part no longer works with acl.  The new structure doesn't generate
libmatlisp.so anymore; you loaded the correct files.

Patches would be most appreciated for this.

    Eric> After making those changes, I loaded start.lisp from Allegro. There were 
    Eric> some compile warnings, but nothing looked too major. I was then able to 
    Eric> make matrices using MAKE-REAL-MATRIX, but whenever any code tried to use 
    Eric> a Fortran function an error was signaled. The following error was given 
    Eric> when I tried to evaluate (eye 2):

Ah, this might be an issue the FFI.  That may have been messed up.  I
think acl has a fortran option for the ffi which we may (or may not)
be using correctly.  

This will require some investigation.

Ray

[Matlisp-users] Trouble running matlisp on Ubuntu with Allegro

[Eric T. <eti...@MI...>]

Hi all,

I've managed to get matlisp working on windows, but I also need to get 
it working on a linux distro as well. Specifically I'm working on Ubuntu 
10.04 with allegro CL 8.1 (64-bit if that matters).

I got the latest version of matlisp from git and followed the 
instructions in the INSTALL file. I noticed some bugs while compiling, 
though. The makefile attempted to install LAPACK before BLAS and it 
(understandably) got unhappy about that. I fixed that, then I noticed 
that the file libmatlisp.so wasn't actually generated so I had to change 
lazy-loader.lisp to load libblas.so, liblapack.so, libdfftpack.so, and 
libtoms715.so.

After making those changes, I loaded start.lisp from Allegro. There were 
some compile warnings, but nothing looked too major. I was then able to 
make matrices using MAKE-REAL-MATRIX, but whenever any code tried to use 
a Fortran function an error was signaled. The following error was given 
when I tried to evaluate (eye 2):

Attempt to do an array operation on #12\? which is not an array.
    [Condition of type TYPE-ERROR]

Restarts:
  0: [RETRY] Retry SLIME REPL evaluation request.
  1: [*ABORT] Return to SLIME's top level.
  2: [ABORT] Abort entirely from this (lisp) process.

Backtrace:
   0: (ERROR TYPE-ERROR :DATUM #12\? :EXPECTED-TYPE ARRAY ...)
   1: (BLAS::FORTRAN-DCOPY 2 #(1.0d0) 0 #(0.0d0 0.0d0 0.0d0 0.0d0) 3)
   2: (DCOPY 2 #(1.0d0) 0 #(0.0d0 0.0d0 0.0d0 0.0d0) 3)
   3: (EYE 2)
   4: (EVAL (EYE 2))
  --more--

Similar errors happen whenever I try to use a fortran function. This 
doesn't happen on Windows (32- or 64-bit). Anyone have any 
ideas/suggestions of what to do to get this to work on Ubuntu?

Cheers,
-Eric

[Matlisp-users] Cholesky decomp. and sol.

[Knut G. <knu...@nt...>]

Hello,

I want to be able to use the Cholesky method in matlisp, i.e. access the
functions dpotrf and dpotrs from lapack. I wrote the files needed, basically
copying from getrf.lisp and getrs.lisp in matlisp/src. It compiles and
everything looks OK. However, running 

(let* ((a (matlisp:make-real-matrix-dim 3 3))(ipiv (make-array 3 :element-type
'(unsigned-byte 32)))(b (matlisp:make-real-matrix-dim 3 1)))(loop for i from 0
to 2 do (loop for j from 0 to 2 do (setf (matlisp:matrix-ref a i j)
10.0d0)))(setf (matlisp:matrix-ref a 0 0) 25.0d0)(setf (matlisp:matrix-ref a 2
2) 62.0d0)(setf (matlisp:matrix-ref a 0 1) -5.0d0)(setf (matlisp:matrix-ref a 1
0) -5.0d0)(setf (matlisp:matrix-ref a 1 1) 17.0d0)(setf (matlisp:matrix-ref b 0
0) 55.0d0)(setf (matlisp:matrix-ref b 1 0) -19.0d0)(setf (matlisp:matrix-ref b 2
0) 114.0d0)(matlisp:getrf! a ipiv )(matlisp:getrs! a ipiv b :trans :N))

gives the correct solution [1,-2,2], whilst 

(let* ((a (matlisp:make-real-matrix-dim 3 3))(b (matlisp:make-real-matrix-dim 3
1 )))(loop for i from 0 to 2 do (loop for j from 0 to 2 do (setf
(matlisp:matrix-ref a i j) 10.0d0)))(setf (matlisp:matrix-ref a 0 0)
25.0d0)(setf (matlisp:matrix-ref a 2 2) 62.0d0)(setf (matlisp:matrix-ref a 0 1)
-5.0d0)(setf (matlisp:matrix-ref a 1 0) -5.0d0)(setf (matlisp:matrix-ref a 1 1)
17.0d0)(setf (matlisp:matrix-ref b 0 0) 55.0d0)(setf (matlisp:matrix-ref b 1 0)
-19.0d0)(setf (matlisp:matrix-ref b 2 0) 114.0d0)(matlisp:potrf! a :uplo
:U)(print a)(print b)(matlisp:potrs! a b :uplo :U))

gives an error message:

#<MATLISP:REAL-MATRIX  3 x 3
    5.0000     -1.0000      2.0000     
   -5.0000      4.0000      3.0000     
    10.000      10.000      7.0000     > 
#<MATLISP:REAL-MATRIX  3 x 1
    55.000     
   -19.000     
    114.00     > 
debugger invoked on a SIMPLE-TYPE-ERROR:
  The value of FORTRAN-FFI-ACCESSORS::VEC is 3, which is not of type
FORTRAN-FFI-ACCESSORS::MATLISP-SPECIALIZED-ARRAY.

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [STORE-VALUE] Supply a new value for FORTRAN-FFI-ACCESSORS::VEC.
  1: [ABORT      ] Exit debugger, returning to top level.

(SB-KERNEL:CHECK-TYPE-ERROR
 FORTRAN-FFI-ACCESSORS::VEC
 3
 FORTRAN-FFI-ACCESSORS::MATLISP-SPECIALIZED-ARRAY
 NIL)
0] 
WARNING: Starting a select without a timeout while interrupts are disabled.

I threw in the (print )s just to verify that both matrices are of type
real-matrix. Why does this not give the correct answer and wat do I have to do?

Thanks,

Knut Gjerden

Re: [Matlisp-users] using matlisp core to link to fortran library

[Raymond T. <ray...@st...>]

Mirko Vukovic wrote:
> Hi,
>
> I have compiled a bunch of Bessel function routines for complex
> arguments from netlib/amos into a shareable library, and would like to
> link to them from cl (sbcl for now).
>
> Instead of reinventing the wheel, I would like to use matlisp's
> capabilities to link to these libraries.  Can someone point me to the
> important (mat)lisp files where I can find the necessary
> functionality?
>   
I think you should look at src/ffi-sbcl.lisp.  That contains the Fortran
interface used by matlisp to interface LAPACK routines to Lisp.

Ray

[Matlisp-users] using matlisp core to link to fortran library

[Mirko V. <mir...@gm...>]

Hi,

I have compiled a bunch of Bessel function routines for complex
arguments from netlib/amos into a shareable library, and would like to
link to them from cl (sbcl for now).

Instead of reinventing the wheel, I would like to use matlisp's
capabilities to link to these libraries.  Can someone point me to the
important (mat)lisp files where I can find the necessary
functionality?

Once everything is said and done, I would put up a summary that could
be useful for others.

Thanks,

Mirko

[Matlisp-users] [ELS 2009] Call for participation

[Marco A. <ma...@cs...>]

Apologies for multiple postings....


************************************************************************

  2nd European Lisp Symposium (ELS 2009)

  Milan, Italy, May 27-29, 2009
  Universita` degli Studi di Milano-Bicocca

  www.european-lisp-symposium.org

************************************************************************

CALL FOR PARTICIPATION
**********************

REGISTRATION IS OPEN AT www.european-lisp-symposium.org.
Check out the updated program.



Scope and Program Highlights:
*****************************

The purpose of the European Lisp Symposium is to provide a forum for
the discussion of all aspects of the design, implementation and
application of any of the Lisp dialects.  We encourage everyone
interested in Lisp to participate.

The European Lisp Symposium 2009 program includes presentations of
high quality papers about novel research results, insights and lessons
learned from practical applications, and educational perspectives, all
involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp,
AutoLisp, ISLISP, Dylan, Clojure, and so on.

The European Lisp Symposium will feature the following highlights:

- Scott McKay of ITA Software will talk about how Lisp use has evolved  
in
   his circannual industry work.

- Mark Tarver of Lambda Associates will talk about Qi as a viral
   mutation of the Lisp DNA.

- Mauro Pezze` of University of Milan-Bicocca will host a panel on
   Programmers' Productivity from a Software Engineering point of view.

- Joao Pavao Martins and Ernesto Morgado of SISCOG will talk about
   the role of LISP in the success of SISCOG

- Christophe Rhodes will give an unportable tutorial.

- Michele Simionato will give a tutorial on Scheme module system and
   Scheme libraries portability issues across implementations.


Social Events:
**************

Friday 29th evening, Conference Banquet

Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in
the center of Milan; 2009 marks the 100th anniversary of the Futurism
Manifesto; stretching it, the harbinger of Lisp 50 years later.


Program Chair:
**************

  * Antonio Leitao, Technical University of Lisbon, Portugal


Local Chair:
************

  * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy


Program committee:
******************

  * Giuseppe Attardi, Universita` di Pisa , Italy
  * Pascal Costanza, Vrije Universiteit Brussel, Belgium
  * Irene Durand, Universite` Bordeaux 1, France
  * Marc Feeley, Universite` de Montreal, Canada
  * Ron Garret, Amalgamated Widgets Unlimited, USA
  * Gregor Kiczales, University of British Columbia, Canada
  * Scott McKay, ITA Software, Inc., USA
  * Peter Norvig, Google Inc., USA
  * Julian Padget, University of Bath, UK
  * Kent Pitman, HyperMeta, USA
  * Christian Queinnec, Universite` Pierre et Marie Curie, France
  * Christophe Rhodes, Goldsmiths College, University of London, UK
  * Robert Strandh, Universite` Bordeaux 1, France
  * Mark Tarver, Lambda Associates, UK
  * Didier Verna, EPITA Research and Development Laboratory, France
  * JonL White, TheGingerIceCreamFactory of Palo Alto, USA
  * Taiichi Yuasa, Kyoto University, Japan


Registration Fees:
******************

  * Students EU100, regular EU220.

Registration will include the proceedings, coffee breaks,
the symposium dinner and other amenities.
Accommodation is not included.

[Matlisp-users] ELS 2009 in Milan, Italy: Call for Participation

[Marco A. <ma...@cs...>]

Apologies for multiple postings....


************************************************************************

  2nd European Lisp Symposium (ELS 2009)

  Milan, Italy, May 27-29, 2009
  Universita` degli Studi di Milano-Bicocca

  www.european-lisp-symposium.org

************************************************************************

CALL FOR PARTECIPATION
**********************

REGISTRATION IS NOW OPEN AT www.european-lisp-symposium.org.
Take advantage of the early bird registration fee.


Scope and Program Highlights:
*****************************

The purpose of the European Lisp Symposium is to provide a forum for
the discussion of all aspects of the design, implementation and
application of any of the Lisp dialects.  We encourage everyone
interested in Lisp to participate.

The European Lisp Symposium 2009 program includes presentations of
high quality papers about novel research results, insights and lessons
learned from practical applications, and educational perspectives, all
involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp,
AutoLisp, ISLISP, Dylan, Clojure, and so on.


Kent Pitman will give the keynote address on Thursday, May 28.

The presentations will be divided into two categories.

* Original contributions.

* Work in progress describing ongoing work that will be discussed in
the form of a "writers' workshop". The writers' workshops will take
place at the symposium in Milan on May 28, 2008.

Social Events:
**************

Friday 29th evening, Conference Banquet

Saturday 30th morning, Guided tour to the "Futurismo" Exhibit in
the center of Milan; 2009 marks the 100th anniversary of the Futurism
Manifesto; stretching it, the harbinger of Lisp 50 years later.


Program Chair:
**************

  * Antonio Leitao, Technical University of Lisbon, Portugal


Local Chair:
************

  * Marco Antoniotti, DISCo, Universita`† Milano Bicocca, Italy


Program committee:
******************

  * Giuseppe Attardi, Universita`† di Pisa , Italy
  * Pascal Costanza, Vrije Universiteit Brussel, Belgium
  * Irene Durand, Universite` Bordeaux 1, France
  * Marc Feeley, Universit` de Montreal, Canada
  * Ron Garret, Amalgamated Widgets Unlimited, USA
  * Gregor Kiczales, University of British Columbia, Canada
  * Scott McKay, ITA Software, Inc., USA
  * Peter Norvig, Google Inc., USA
  * Julian Padget, University of Bath, UK
  * Kent Pitman, PTC, USA
  * Christian Queinnec, Universite` Pierre et Marie Curie, France
  * Christophe Rhodes, Goldsmiths College, University of London, UK
  * Robert Strandh, Universite` Bordeaux 1, France
  * Mark Tarver, Lambda Associates, UK
  * Didier Verna, EPITA Research and Development Laboratory, France
  * JonL White, TheGingerIceCreamFactory of Palo Alto, USA
  * Taiichi Yuasa, Kyoto University, Japan


Registration Fees:
******************

  * Early registration before April 25, 2008: Students EU60, regular  
EU120.
  * Late registration before May 16, 2008: Students EU80, regular EU160.
  * Onsite registration: Students EU100, regular EU220.

Registration will include the proceedings, coffee breaks,
the symposium dinner and other amenities.
Accommodation is not included.

Re: [Matlisp-users] Question wrt interface to Allegro

[A.J. R. <bli...@gm...>]

I have some code which goes part way towards that (using the
cl-blapack links to BLAS and LAPACK, which are auto-generated and use
CFFI), but got seduced by lisp-matrix's duality for either
lisp-centric or foriegn-centric storage.

So much for getting sold on hype.

On the other hand, it's been a fun project (as per another post, you
can see the lisp-matrix/cl-blapack work I'm doing at github, and I
probably should return by matlisp hacks back there for posterity,
though unfortunately not for reuse, I'm just not that good at lisp
right now...).


On Wed, Dec 10, 2008 at 5:28 PM, Raymond Toy <ray...@er...> wrote:
>>>>>> "AJ" == A J Rossini <A.J.> writes:
>
>    AJ> My "right answer" to the "wrong question" (that you didn't ask).
>    AJ> If you don't mind the potential overhead of CFFI, take a look at the
>    AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>    AJ> (concepts and code) for Fortran linking with CFFI.
>
> On my list of things to do is replacing the existing FFI in matlisp
> with a new version that calls CFFI instead.
>
> And, I think, for the the existing supported Lisps, CFFI has no
> additional overhead.  And then matlisp will be automagically support
> more lisps than sbcl, cmucl, and Allegro.
>
> I can't really debug the Allegro issue since I don't have Allegro.
> Will the free Allegro version compile enough of matlisp for me to test
> it?
>
> Ray
>



-- 
best,
-tony

bli...@gm...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

Re: [Matlisp-users] Question wrt interface to Allegro

[A.J. R. <bli...@gm...>]

Unofficial site for cl-blapack and lisp-matrix (if you can "git") is


On Wed, Dec 10, 2008 at 6:19 PM, Nicolas Neuss
<ne...@ma...> wrote:
> Nicolas Neuss <ne...@ma...> writes:
>
>> "A.J. Rossini" <bli...@gm...> writes:
>>
>>> My "right answer" to the "wrong question" (that you didn't ask).
>>>
>>> If you don't mind the potential overhead of CFFI, take a look at the
>>> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>>> (concepts and code) for Fortran linking with CFFI.
>>
>> OK, thanks for the pointer.  I will have a look.
>>
>> Nicolas
>
> Stupid question: How can I get those (cl-blapack, lisp-matrix)?  Are there
> homepages or official download sites for those projects?
>
> Thanks, Nicolas
>



-- 
best,
-tony

bli...@gm...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

Re: [Matlisp-users] Question wrt interface to Allegro

[Raymond T. <ray...@er...>]

>>>>> "Nicolas" == Nicolas Neuss <ne...@ma...> writes:

    Nicolas> Comparing with Matlisp, I have found my bug.
    Nicolas> Nicolas Neuss <ne...@ma...> writes:

    >> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
    Nicolas>                                               "dnrm2" is correct

    >> ((n :int) (x (:array :double)) (incx :int))
    >> :convention :fortran
    >> :returning :double)

    Nicolas> To make sure I understand this correctly: dnrm2_ is probably a routine
    Nicolas> suitable for calling from C (passing arrays as a pointer to values) while
    Nicolas> Allegro with convention :fortran passes arrays pointing to values-1 as is
    Nicolas> suitable for the Fortran "dnrm2".

I don't know what the :fortran convention means, but your explanation
sounds plausible.  It seems a little odd to me.  For n and incx, I can
see the :fortran convention to mean pass the address of the location
of n and incx to the routine, since that's what Fortran does
(everything is pass by reference).  Arrays are a bit trickier.  I
don't see why you want to pass the address of x-1 instead of just x.
After all, Fortran x(1) is the first element of the array, however
that array might be arranged in memory.

Ray

Re: [Matlisp-users] Question wrt interface to Allegro

[Nicolas N. <ne...@ma...>]

Nicolas Neuss <ne...@ma...> writes:

> "A.J. Rossini" <bli...@gm...> writes:
>
>> My "right answer" to the "wrong question" (that you didn't ask).
>>
>> If you don't mind the potential overhead of CFFI, take a look at the
>> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
>> (concepts and code) for Fortran linking with CFFI.
>
> OK, thanks for the pointer.  I will have a look.
>
> Nicolas

Stupid question: How can I get those (cl-blapack, lisp-matrix)?  Are there
homepages or official download sites for those projects?

Thanks, Nicolas

Re: [Matlisp-users] Question wrt interface to Allegro

[Nicolas N. <ne...@ma...>]

"A.J. Rossini" <bli...@gm...> writes:

> My "right answer" to the "wrong question" (that you didn't ask).
>
> If you don't mind the potential overhead of CFFI, take a look at the
> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
> (concepts and code) for Fortran linking with CFFI.

OK, thanks for the pointer.  I will have a look.

Nicolas

Re: [Matlisp-users] Question wrt interface to Allegro

[Nicolas N. <ne...@ma...>]

Comparing with Matlisp, I have found my bug.

Nicolas Neuss <ne...@ma...> writes:

> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
                                              "dnrm2" is correct

>     ((n :int) (x (:array :double)) (incx :int))
>   :convention :fortran
>   :returning :double)

To make sure I understand this correctly: dnrm2_ is probably a routine
suitable for calling from C (passing arrays as a pointer to values) while
Allegro with convention :fortran passes arrays pointing to values-1 as is
suitable for the Fortran "dnrm2".

Is this correct?

Thanks, Nicolas

Re: [Matlisp-users] Question wrt interface to Allegro

[Nicolas N. <ne...@ma...>]

Raymond Toy <ray...@er...> writes:

> I can't really debug the Allegro issue since I don't have Allegro.
> Will the free Allegro version compile enough of matlisp for me to test
> it?
>
> Ray

I think, yes, because it should be sufficient to compile only blas.lisp.
At least that worked for me.  But I've found the problem already - see my
other post.

Nicolas

Re: [Matlisp-users] Question wrt interface to Allegro

[Raymond T. <ray...@er...>]

>>>>> "AJ" == A J Rossini <A.J.> writes:

    AJ> My "right answer" to the "wrong question" (that you didn't ask).
    AJ> If you don't mind the potential overhead of CFFI, take a look at the
    AJ> cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
    AJ> (concepts and code) for Fortran linking with CFFI.

On my list of things to do is replacing the existing FFI in matlisp
with a new version that calls CFFI instead.

And, I think, for the the existing supported Lisps, CFFI has no
additional overhead.  And then matlisp will be automagically support
more lisps than sbcl, cmucl, and Allegro.

I can't really debug the Allegro issue since I don't have Allegro.
Will the free Allegro version compile enough of matlisp for me to test
it?

Ray

Re: [Matlisp-users] Question wrt interface to Allegro

[A.J. R. <bli...@gm...>]

My "right answer" to the "wrong question" (that you didn't ask).

If you don't mind the potential overhead of CFFI, take a look at the
cl-blapack (works, for BLAS and LAPACK) and/or lisp-matrix packages
(concepts and code) for Fortran linking with CFFI.

On Wed, Dec 10, 2008 at 2:20 PM, Nicolas Neuss
<ne...@ma...> wrote:
> Hello,
>
> I have troubles with interfacing to Fortran using Allegro and I think that
> maybe the experience of the people here might help me with this problem.
>
> The following code using SBCL works fine and returns sqrt(10).
>
>    (sb-alien:load-shared-object #p"/usr/lib/libblas.so")
>    (SB-ALIEN:DEFINE-ALIEN-ROUTINE "dnrm2_" SB-ALIEN:DOUBLE
>                                   (N SB-ALIEN:INT :COPY)
>                                   (X (* SB-ALIEN:DOUBLE) :IN)
>                                   (INCX SB-ALIEN:INT :COPY))
>
>    (dnrm2- 10 (sb-sys:vector-sap
>                 (make-array 10 :element-type 'double-float
>                 :initial-element 1.0d0))
>            1)
>
> works fine.  But when I try the same thing with Allegro (ACL 8.1, trial
> edition), I get:
>
> CL-USER(1): (cl:load #p"/usr/lib/libblas.so")
>
> (foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
>    ((n :int) (x (:array :double)) (incx :int))
>  :convention :fortran
>  :returning :double)
>
> (dnrm2- 10 (make-array 10 :element-type 'double-float :initial-element 1.0d0) 1)
>
> ; Foreign loading /usr/lib/libblas.so.
> T
> CL-USER(2): CL-USER(2): DNRM2-
> CL-USER(3): CL-USER(3): Error: Attempt to do an array operation on -269087380 which is not an
>       array.
>  [condition type: TYPE-ERROR]
>
> Restart actions (select using :continue):
>  0: Return to Top Level (an "abort" restart).
>  1: Abort entirely from this (lisp) process.
> [1] CL-USER(4): :bt
> Evaluation stack:
>
> DNRM2- <-
>  EVAL <- TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <-
>  TPL:START-INTERACTIVE-TOP-LEVEL
>
> [1] CL-USER(5): :local
> Interpreted lexical environment:
> INCX: 1
> X: #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
> N: 10
> Compiled lexical environment:
> 0(REQUIRED): N: 10
> 1(REQUIRED): X:
>   #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
> 2(REQUIRED): INCX: 1
> [1] CL-USER(6):
>
> Does anyone have an idea what happens here?
>
> Thanks, Nicolas
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>



-- 
best,
-tony

bli...@gm...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

[Matlisp-users] Question wrt interface to Allegro

[Nicolas N. <ne...@ma...>]

Hello,

I have troubles with interfacing to Fortran using Allegro and I think that
maybe the experience of the people here might help me with this problem.

The following code using SBCL works fine and returns sqrt(10).

    (sb-alien:load-shared-object #p"/usr/lib/libblas.so")
    (SB-ALIEN:DEFINE-ALIEN-ROUTINE "dnrm2_" SB-ALIEN:DOUBLE
                                   (N SB-ALIEN:INT :COPY)
                                   (X (* SB-ALIEN:DOUBLE) :IN)
                                   (INCX SB-ALIEN:INT :COPY)) 

    (dnrm2- 10 (sb-sys:vector-sap
                 (make-array 10 :element-type 'double-float
                 :initial-element 1.0d0))
            1)

works fine.  But when I try the same thing with Allegro (ACL 8.1, trial
edition), I get:

CL-USER(1): (cl:load #p"/usr/lib/libblas.so")

(foreign-functions:def-foreign-call (dnrm2- "dnrm2_")
    ((n :int) (x (:array :double)) (incx :int))
  :convention :fortran
  :returning :double)

(dnrm2- 10 (make-array 10 :element-type 'double-float :initial-element 1.0d0) 1)

; Foreign loading /usr/lib/libblas.so.
T
CL-USER(2): CL-USER(2): DNRM2-
CL-USER(3): CL-USER(3): Error: Attempt to do an array operation on -269087380 which is not an
       array.
  [condition type: TYPE-ERROR]

Restart actions (select using :continue):
 0: Return to Top Level (an "abort" restart).
 1: Abort entirely from this (lisp) process.
[1] CL-USER(4): :bt
Evaluation stack:

DNRM2- <-
  EVAL <- TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP <-
  TPL:START-INTERACTIVE-TOP-LEVEL

[1] CL-USER(5): :local
Interpreted lexical environment:
INCX: 1
X: #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
N: 10
Compiled lexical environment:
0(REQUIRED): N: 10
1(REQUIRED): X:
   #(1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0 1.0d0)
2(REQUIRED): INCX: 1
[1] CL-USER(6): 

Does anyone have an idea what happens here?

Thanks, Nicolas

Re: [Matlisp-users] thread safety

[<eva...@gm...>]

"Raymond Toy (RT/EUS)" <ray...@er...> writes:

> Evan Monroig wrote:
>> Hi,
>>
>> I have been using matlisp for a little while now, and I started to
>> look inside matlisp files to see if it was thread-safe.
>>
>> One issue that I have found is that functions like
>> DGEEV-WORKSPACE-INQUIRY are closures around matrices of size one
>> which are used to store the size of the work matrix.
>>
>> If I call DGEEV-WORKSPACE-INQUIRY simultaneously in several threads,
>> it might happen that the values that are read/written in this matrix
>> will be polluted by the other threads.
>
> Yes, that's a problem.  At the time these were written, I guess I
> could bear to cons up a single-element matrix just for this.  But now
> that threaded Lisp's are becoming more common, we should change this.
>
> Thanks for the reminder.  I'll look into fixing this soon.

Thanks for your answer.  Please let me know if you would like a patch
for this, although it might be less work for you to do the modifications
than handle a patch in this case.

Evan

Re: [Matlisp-users] thread safety

[Raymond T. (RT/EUS) <ray...@er...>]

Evan Monroig wrote:
> Hi,
> 
> I have been using matlisp for a little while now, and I started to look
> inside matlisp files to see if it was thread-safe.
> 
> One issue that I have found is that functions like
> DGEEV-WORKSPACE-INQUIRY are closures around matrices of size one which
> are used to store the size of the work matrix.
> 
> If I call DGEEV-WORKSPACE-INQUIRY simultaneously in several threads, it
> might happen that the values that are read/written in this matrix will
> be polluted by the other threads.

Yes, that's a problem.  At the time these were written, I guess I could 
bear to cons up a single-element matrix just for this.  But now that 
threaded Lisp's are becoming more common, we should change this.

Thanks for the reminder.  I'll look into fixing this soon.

Ray

[Matlisp-users] least-squares estimate

[Evan M. <eva...@gm...>]

Hi,

I found the need to find the least-squares solution of a classical
equation Ax = b, so I added a binding for the lapack function DGELSY.

This is the one that solves rectangular real linear least squares
problems using a complete orthogonal factorization (see [1] and [2]).

Please find a patch attached.

I authorize you to incorporate it to matlisp as is or after
modification, using the same license as other parts of matlisp.

Cheers,

Evan

[1] http://www.netlib.org/lapack/lug/node27.html
[2] http://www.netlib.org/lapack/lug/node43.html

[Matlisp-users] thread safety

[Evan M. <eva...@gm...>]

Hi,

I have been using matlisp for a little while now, and I started to look
inside matlisp files to see if it was thread-safe.

One issue that I have found is that functions like
DGEEV-WORKSPACE-INQUIRY are closures around matrices of size one which
are used to store the size of the work matrix.

If I call DGEEV-WORKSPACE-INQUIRY simultaneously in several threads, it
might happen that the values that are read/written in this matrix will
be polluted by the other threads.

other examples are:

DGEEV-workspace-inquiry
zgeev-workspace-inquiry
GEMM!
dgeqrf-workspace-inquiry
zgeqrf-workspace-inquiry
dgeqp3-workspace-inquiry
zgeqp3-workspace-inquiry

I may have missed others, as I looked only at toplevel LET bindings.

Evan

Re: [Matlisp-users] [Maxima] Windows build of Maxima 5.0.14

[A.J. R. <bli...@gm...>]

On Dec 24, 2007 4:59 PM, Terrence Brannon <sch...@gm...> wrote:
> Raymond Toy wrote:
> > Terrence Brannon wrote:
> >> Terrence Brannon wrote:
> >>
> >>> Hello, I am developing a library of array processing code in Common
> >>> Lisp inspired by the J programming language. I am using Windows XP
> >>> for development.
> >>>
> > Have you heard of matlisp?
> Yes, in my survey of Lisp array processing I came across it. My feedback:
> * Re: http://matlisp.sourceforge.net/ - MatLisp adds to this richness by
> giving you a *matrix fast class *based on BLAS
> <http://www.netlib.org/blas> and LAPACK <http://www.netlib.org/lapack>.
> -- grammatically, that should be fast matrix class
> * I am on Windows, so CMUCL does not run and Allegro is too expensive
> for a hobbyist like me. Also, I desire the blinding speed of SBCL or GCL
> over Clisp for the ultimate product. Not that my project will ever
> matter, but I still want to see this little baby crank.
> * I turned a guy on to Matlisp recently. He goes by the handle mogonus
> in #lisp. His name is Marco.
> * I didnt see a manual at the website.
> * I'm mainly doing this to create an open-source package which is just
> like the J programming language. A key idea of J is verb rank, which
> allows verbs to operate on data of any rank.
> * Matlisp is not limited to rank-2 arrays is it? The README in the
> distro imply that.. or rather dont discuss anything else.
> * Precompiling BLAS and LAPACK is fine, but what if a new arch wants to
> use the library? I like the fortran to lisp approach of Maxima.
> * I'm not sure about the overhead of using a matrix class. My approach
> so far has been to use the built in ARRAY type.
> * There is a great amount of care in documenting the code. A lot of work
> has gone into this. Has there been no reason for a release since 2003?
>
> >   There's also at least one other matrix package bug I've forgotten
> > its name.
> Hmm... the only other thing I came across was LUSH - which is Lisp-like
> syntax but not genuine common lisp. Oh wait, actually from a thread I
> started:
> http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/d44a7c5c6b3276d8
>
> there is NLISP - http://nlisp.info/index.html
> there is also RCL and RCLG, listed here - http://www.cliki.net/Mathematics

(Full disclosure - I've got a vested interest in statistical
applications of matrices)

Having documented/packaged RCLG and fully read RCL, I just want to
note that yes you could use them for arrays in CL with exactly what
you want, it would be silly (the prime use for them is to handle the
features in R that CL doesn't yet have natively -- one of these days
CL will).

best,
-tony

bli...@gm...
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee:  Do stupid things faster with more energy!

Re: [Matlisp-users] [Maxima] Windows build of Maxima 5.0.14

[Terrence B. <sch...@gm...>]

Raymond Toy wrote:
> Terrence Brannon wrote:
>> Terrence Brannon wrote:
>>  
>>> Hello, I am developing a library of array processing code in Common 
>>> Lisp inspired by the J programming language. I am using Windows XP 
>>> for development.
>>>     
> Have you heard of matlisp?
Yes, in my survey of Lisp array processing I came across it. My feedback:
* Re: http://matlisp.sourceforge.net/ - MatLisp adds to this richness by 
giving you a *matrix fast class *based on BLAS 
<http://www.netlib.org/blas> and LAPACK <http://www.netlib.org/lapack>.  
-- grammatically, that should be fast matrix class
* I am on Windows, so CMUCL does not run and Allegro is too expensive 
for a hobbyist like me. Also, I desire the blinding speed of SBCL or GCL 
over Clisp for the ultimate product. Not that my project will ever 
matter, but I still want to see this little baby crank.
* I turned a guy on to Matlisp recently. He goes by the handle mogonus 
in #lisp. His name is Marco.
* I didnt see a manual at the website.
* I'm mainly doing this to create an open-source package which is just 
like the J programming language. A key idea of J is verb rank, which 
allows verbs to operate on data of any rank.
* Matlisp is not limited to rank-2 arrays is it? The README in the 
distro imply that.. or rather dont discuss anything else.
* Precompiling BLAS and LAPACK is fine, but what if a new arch wants to 
use the library? I like the fortran to lisp approach of Maxima.
* I'm not sure about the overhead of using a matrix class. My approach 
so far has been to use the built in ARRAY type.
* There is a great amount of care in documenting the code. A lot of work 
has gone into this. Has there been no reason for a release since 2003?

>   There's also at least one other matrix package bug I've forgotten 
> its name.
Hmm... the only other thing I came across was LUSH - which is Lisp-like 
syntax but not genuine common lisp. Oh wait, actually from a thread I 
started:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/d44a7c5c6b3276d8

there is NLISP - http://nlisp.info/index.html
there is also RCL and RCLG, listed here - http://www.cliki.net/Mathematics
>
> (Full disclosure:  I wrote parts of matlisp.)
nice work!
>
>>  >(funcall (intern (symbol-name :operate-on-system) :mk) "maxima"  
>> :load :verbose t))
>>   
> You probably want to use :compile instead of :load.  Then all the 
> files will be compiled (and loaded).
>> ;    - Loading module "info"
>> ;      - Binary file binary-gcl/nregex.o is old or does not exist.
>> ;        Compile (and load) source file src/nregex.lisp instead?
>>   
> Not sure why you get this, but there is a bug in gcl in that it 
> doesn't know how to create directories.  You might want to create the 
> binary-gcl directory by hand first.
yes, that helped out a lot. Thanks. And for readers of the mail archive. 
the binary-gcl directory should be made in the root of the distro, not 
in lisp-utils or src.
>
> Ray
>
The whole thing built. Now the only issue is that GCL doesnt work with 
SLIME. So I might try the whole build process over again with SBCL soon.

Re: [Matlisp-users] matlisp on Mac OS X (Intel)

[Jan R. <ja...@ry...>]

> Jan,
> Okay.  I think I've found the problem.   Go back to the file  
> configure.in and edit the block that deals with Darwin.  Change  
> things so that you end up with:
> 
> FLIBS="-llapack -lblas -lg2c -lSystem /usr/lib/dylib1.o"
> SHARED_LIB_LDFLAGS="-dylib -single_module"
[...]

Nice! That does indeed produce a working installation of matlisp with
sbcl on MacOS X Intel 10.4.9!

Thanks!

> Note that the -llapack -lblas entries in the FLIBS statement will  
> load the apple vecLib framework optimized lapack and blas libraries  
> as can be seen in the resulting shared object:
[...]

I guess that's good -- those are likely faster than the ones included
with matlisp.

Many thanks for your help, and I'd like to humbly suggest that the above
FLIBS and SHARED_LIB_LDFLAGS settings be copied into the Darwin section
of the default configure.in...

--Jan

Re: [Matlisp-users] matlisp on Mac OS X (Intel)

[Enphilistor <enp...@ma...>]

Jan,

Okay.  I think I've found the problem.   Go back to the file  
configure.in and edit the block that deals with Darwin.  Change  
things so that you end up with:

FLIBS="-llapack -lblas -lg2c -lSystem /usr/lib/dylib1.o"
SHARED_LIB_LDFLAGS="-dylib -single_module"

Then run:

	autoconf configure.in > configure

and then run

	./configure --prefix=`pwd` --with-fflags="-O3 -fPIC"  --with- 
lisp=sbcl --with-lisp-exec=sbcl

This will create a libmatlisp.so that CAN be loaded into sbcl and  
which will allow the 'make' process to run to completion (i.e. the  
loading and processing of 'start.lisp' works).
Note that the -llapack -lblas entries in the FLIBS statement will  
load the apple vecLib framework optimized lapack and blas libraries  
as can be seen in the resulting shared object:

% otool -L lib/libmatlisp.so

lib/libmatlisp.so:
         ./lib/libmatlisp.so (compatibility version 0.0.0, current  
version 0.0.0)
         /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib (compatibility  
version 1.0.0, current version 192.15.0)
         /System/Library/Frameworks/Accelerate.framework/Versions/A/ 
Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility  
version 1.0.0, current version 192.15.0)
         /usr/local/lib/libg2c.0.dylib (compatibility version 1.0.0,  
current version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
current version 88.3.7)

Anyway this seems to work for me.
Cheers,

-- E


On Apr 21, 2007, at 3:41 AM, Jan Rychter wrote:

>> Jan,
>> I'm trying to get things working with Mac OS X on intel as well.  I
>> am also using the g77, gfortran, and gcc from the Mac HPC page on
>> sourceforge.  I've noticed that the default distribution from cvs
>> seems to have been built assuming that folks would be using Fink.
>> I'm definitely not and that's what's causing the link to fail for
>> me.  I've found that if you'll edit configure.in, search for "-L/sw/
>> lib" down under the case for darwin you'll find some rules that
>> pertain to the problem at hand.  If you'll replace the line that  
>> says:
>>
>> 	FLIBS="-L/sw/lib -lf2c -lSystem /usr/lib/bundle1.o"
>>
>> with
>>
>> 	FLIBS="-lSystem /usr/lib/bundle1.o"
>>
>> and then save the file and run "autoconf configure.in > configure"
>> and then ./configure as usual, and then make, you should get through
>> the link.  This is about as far as I've gotten so far.  Which lisp
>> are you using?  I'm using SBCL.
>
> This is a good bit of advice -- one thing I was missing was that I've
> been trying to use the included configure script, instead of
> regenerating it using autoconf. Running autoconf definitely improved
> things.
>
> libmatlisp.so does get built now -- but SBCL is unable to load it:
>
> debugger invoked on a SIMPLE-ERROR:
>   Error opening shared object "/Users/jwr/lisp/matlisp/lib/ 
> libmatlisp.so":
>   dlopen(3) failed.
>
> [10:40] tnuctip:/Users/jwr>file /Users/jwr/lisp/matlisp/lib/ 
> libmatlisp.so
> /Users/jwr/lisp/matlisp/lib/libmatlisp.so: Mach-O bundle i386
> [10:40] tnuctip:/Users/jwr>
>
> I thought SBCL did support loading shared objects on Mac OS X?
>
> AllegroCL seems to load the same library just fine.
>
> --J.
>
>> On Apr 20, 2007, at 4:50 AM, Jan Rychter wrote:
>>
>>> Does anyone use matlisp on Mac OS X on an Intel CPU? If so, which
>>> fortran compiler did you use? Which exact version and where did you
>>> get
>>> it?
>>>
>>> I can't seem to get through the linking phase for BLAS/LAPACK. I  
>>> tried
>>> gfortran from the gcc 4.3 package from http://hpc.sourceforge.net/,
>>> and
>>> now tried g77 from GNU Fortran (GCC) 3.4.0. They work fine until ld
>>> gets
>>> invoked and then things break. One reason for the breakage is that
>>> configure insists on trying to link in crt1.o into libraries, which
>>> won't work, but even removing that doesn't get me anywhere.
>>>
>>> Since some people reported being able to get it to work with minor
>>> adjustments, there must be something I'm doing wrong.
>>>
>>> Any hints?
>>>
>>> --J.
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users