matlisp-users — General discussion list.

Re: [Matlisp-users] Matlisp/CMUCL-19a

[Michael A. K. <ma...@ll...>]

Ray,

   Yes!  That did it...thanks!

mike

Raymond Toy wrote:
>  Ah, thanks for the hint!  Yes, in cmucl-19a %top-level is in the LISP
> package, not the CL package.
> 
> Could you change that and see if that works?  Although I've compiled
> matlisp with cmucl 19a, I never save a core with matlisp, so I never
> noticed this problem.
> 
> Sorry about that!
> 
> Ray

Re: [Matlisp-users] Addition of .ASD to cvs tree

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

>>>>> "Robert" == Robert Sedgewick <rd...@me...> writes:

    Robert> On another issue, do you think that my modified configure.in could be 
    Robert> committed to CVS?  darwin doesn't like the AC_F77_FUNC autoconf command 
    Robert> (autoconf version 2.59).  I modified the configure.in not to use it on 
    Robert> darwin.  Other platforms should not be affected.

Did I forget to do that?  Sorry!  I ran into some problems with that
as well, but I forgot how I worked around it, and I obviously didn't
check in my fixes.

Ray

Re: [Matlisp-users] Matlisp/CMUCL-19a

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

>>>>> "Tunc" == simsek  <si...@EE...> writes:

    Tunc> It looks like cmucl guys changed the funcion CL::%TOP-LEVEL which 
    Tunc> is called at start-up time to get the lisp prompt.  The culprit
    Tunc> is in the file save.lisp.  Search for the string CL::%TOP-LEVEL

Ah, thanks for the hint!  Yes, in cmucl-19a %top-level is in the LISP
package, not the CL package.

Could you change that and see if that works?  Although I've compiled
matlisp with cmucl 19a, I never save a core with matlisp, so I never
noticed this problem.

Sorry about that!

Ray

Re: [Matlisp-users] Addition of .ASD to cvs tree

[Robert S. <rd...@me...>]

(sorry for the delay in replying, I've been busy lately)

On Jan 4, 2005, at 9:52 AM, Raymond Toy wrote:
>
> For the asd file to work properly, I think it needs to be generated
> from configure so that the right options are given to the Fortran
> compiler.

yeah, that is true.  I just stuck in by hand what works for linux and 
darwin.  I'll try to do this at some point, but I might not get to it 
for a little while.  If someone else wants to do this they are welcome 
to it.

On another issue, do you think that my modified configure.in could be 
committed to CVS?  darwin doesn't like the AC_F77_FUNC autoconf command 
(autoconf version 2.59).  I modified the configure.in not to use it on 
darwin.  Other platforms should not be affected.

I appended the diff, and put my version of configure.in up at
http://mercury.chem.pitt.edu/~rds/configure.in

Once this gets committed, then I think you can add Mac OS X to the list 
of supported platforms.

Thanks,
  Robbie

> At one point mk-defsys file could also compile the Fortran
> sources, but I don't know if I ever committed the changes or if it
> even works anymore.
>
> If one of you wants to maintain the asd file, then I can commmit it.
> But you'll have to make it so that it's either created by configure or
> you punt and have a makefile build the Fortran sources.
>
> Ray
>

==================================================================
--- matlisp/configure.in        2004-05-25 20:17:24.000000000 -0400
+++ matlisp.newautoconf/configure.in    2004-06-03 01:01:20.000000000 
-0400
@@ -263,7 +263,15 @@
  dnl    Figure out what the Fortran name mangling is
  dnl
  dnl This is only for autoconf 2.49d or later!
-AC_F77_FUNC(f77_name)
+dnl This breaks on darwin, so just insert the correct value
+case "$host" in
+  *-*-darwin*)
+        f77_name=f77_name_
+        ;;
+  *)
+        AC_F77_FUNC(f77_name)
+       ;;
+esac
  # Setup our environment variables based on the value of f77_name
  F77_LOWER_CASE=t
  F77_UNDERSCORE=t

Re: [Matlisp-users] Matlisp/CMUCL-19a

[<si...@EE...>]

Hi, 

It looks like cmucl guys changed the funcion CL::%TOP-LEVEL which 
is called at start-up time to get the lisp prompt.  The culprit
is in the file save.lisp.  Search for the string CL::%TOP-LEVEL

The thing to fix this is to replace the call to cl::%top-level with
the call to the new function that produces the lisp prompt.  However,
I don't know what this function is, I don't have cmucl-19a and I don't
have a linux available to install it on.  

I hope this helps.
Tunc

----- Original Message -----
From: "Michael A. Koerber" <ma...@ll...>
Date: Thursday, January 6, 2005 10:41 am
Subject: [Matlisp-users] Matlisp/CMUCL-19a

> 1.  Compiled Matlisp under cmucl-19a on FreeBSD-5.3 today...no 
> problems.
> 2.  When I started matlisp I get an error about CL::%TOP-LEVEL 
> undefined.  (See below.)
> 
> 3.  What do I need to do?
> 
> tnx
> mike
> 
> 
> matlisp -noinit
> ;;; Running /usr/bin/ld...
> ;;; Done.
> 
> CMU Common Lisp 19a, running on oboe.llan.ll.mit.edu
> With core: /usr/home/mak/bin/matlisp.core
> Dumped on: Thu, 2005-01-06 07:49:28-05:00 on oboe.llan.ll.mit.edu
> See <" target="l">http://www.cons.org/cmucl/> for support information.
> Loaded subsystems:
>     Python 1.1, target Intel x86
>     CLOS based on Gerd's PCL 2004/04/14 03:32:47
>     MATLISP/Pre 2.0
> 
> 
> Error in KERNEL:%COERCE-TO-FUNCTION:  the function 
> COMMON-LISP::%TOP-LEVEL is un
> defined.
>    [Condition of type UNDEFINED-FUNCTION]
> 
> 
> Debug  (type H for help)
> 
> (KERNEL:%COERCE-TO-FUNCTION COMMON-LISP::%TOP-LEVEL)
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no 
> longer 
> exists:
>   target:code/fdefinition.lisp.
> 0] back
> 
> 0: (KERNEL:%COERCE-TO-FUNCTION COMMON-LISP::%TOP-LEVEL)
> 1: (NIL)
> 2: ((LABELS LISP::RESTART-LISP
>       SAVE-LISP))
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

[Matlisp-users] Matlisp/CMUCL-19a

[Michael A. K. <ma...@ll...>]

1.  Compiled Matlisp under cmucl-19a on FreeBSD-5.3 today...no problems.

2.  When I started matlisp I get an error about CL::%TOP-LEVEL 
undefined.  (See below.)

3.  What do I need to do?

tnx
mike


matlisp -noinit
;;; Running /usr/bin/ld...
;;; Done.

CMU Common Lisp 19a, running on oboe.llan.ll.mit.edu
With core: /usr/home/mak/bin/matlisp.core
Dumped on: Thu, 2005-01-06 07:49:28-05:00 on oboe.llan.ll.mit.edu
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
     Python 1.1, target Intel x86
     CLOS based on Gerd's PCL 2004/04/14 03:32:47
     MATLISP/Pre 2.0


Error in KERNEL:%COERCE-TO-FUNCTION:  the function 
COMMON-LISP::%TOP-LEVEL is un
defined.
    [Condition of type UNDEFINED-FUNCTION]


Debug  (type H for help)

(KERNEL:%COERCE-TO-FUNCTION COMMON-LISP::%TOP-LEVEL)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer 
exists:
   target:code/fdefinition.lisp.
0] back

0: (KERNEL:%COERCE-TO-FUNCTION COMMON-LISP::%TOP-LEVEL)
1: (NIL)
2: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

Re: [Matlisp-users] Addition of .ASD to cvs tree

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

>>>>> "Robert" == Robert Sedgewick <rd...@me...> writes:

    Robert> 1.  (*) text/plain          ( ) text/html           
    Robert> On Dec 22, 2004, at 9:21 AM, Raymond Toy wrote:

    >>>>>>> "Denis" == Denis Bueno <db...@cc...> writes:
    >> 
    Denis> Could a committer add the following, matlisp.asd, to the 
    >> cvs tree?
    Denis> It's  quite convenient to use.
    >> 
    >> Is there something that this asd file does that mk-defsys doesn't do?
    >> I'm not really keen on maintaining two defsystems for matlisp.

    Robert> Well, the asd file takes care of compiling the fortran sources, while 
    Robert> the mk-defsys solution needs a makefile for that.   Also, asdf is 
    Robert> integrated with slime (I don't think mk-defsys is).

For the asd file to work properly, I think it needs to be generated
from configure so that the right options are given to the Fortran
compiler.  At one point mk-defsys file could also compile the Fortran
sources, but I don't know if I ever committed the changes or if it
even works anymore.

If one of you wants to maintain the asd file, then I can commmit it.
But you'll have to make it so that it's either created by configure or
you punt and have a makefile build the Fortran sources.

Ray

Re: [Matlisp-users] Addition of .ASD to cvs tree

[Robert S. <rd...@me...>]

On Dec 22, 2004, at 9:21 AM, Raymond Toy wrote:

>>>>>> "Denis" == Denis Bueno <db...@cc...> writes:
>
>     Denis> Could a committer add the following, matlisp.asd, to the 
> cvs tree?
>     Denis> It's  quite convenient to use.
>
> Is there something that this asd file does that mk-defsys doesn't do?
> I'm not really keen on maintaining two defsystems for matlisp.

Well, the asd file takes care of compiling the fortran sources, while 
the mk-defsys solution needs a makefile for that.   Also, asdf is 
integrated with slime (I don't think mk-defsys is).

On the other hand, I don't think the asd file currently works with 
windows, although it probably wouldn't be too hard to fix that for 
someone with a windows box.

I think it is mostly a matter of personal preference.

--Robbie

Re: [Matlisp-users] Addition of .ASD to cvs tree

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

>>>>> "Denis" == Denis Bueno <db...@cc...> writes:

    Denis> Could a committer add the following, matlisp.asd, to the cvs tree? 
    Denis> It's  quite convenient to use.

Is there something that this asd file does that mk-defsys doesn't do?
I'm not really keen on maintaining two defsystems for matlisp.

Ray

[Matlisp-users] Addition of .ASD to cvs tree

[Denis B. <db...@cc...>]

Could a committer add the following, matlisp.asd, to the cvs tree? It's  
quite convenient to use.

This is part of Robbie Sedgewick's port of matlisp to SBCL that never  
made it into matlisp cvs.


;;; -*- Mode: lisp; Syntax: ansi-common-lisp; Base: 10 -*-
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;;;
;;;
;;; Copyright (c) 2000 The Regents of the University of California.
;;; All rights reserved.
;;;
;;; Permission is hereby granted, without written agreement and without
;;; license or royalty fees, to use, copy, modify, and distribute this
;;; software and its documentation for any purpose, provided that the
;;; above copyright notice and the following two paragraphs appear in  
all
;;; copies of this software.
;;;
;;; IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY  
PARTY
;;; FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
;;; ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN  
IF
;;; THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF
;;; SUCH DAMAGE.
;;;
;;; THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
;;; INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
;;; MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
;;; PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
;;; CALIFORNIA HAS NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT,  
UPDATES,
;;; ENHANCEMENTS, OR MODIFICATIONS.
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;;;
;;;
;;; $Id: matlisp.lisp,v 1.21 2003/06/01 15:21:59 rtoy Exp $
;;;
;;; $Log: matlisp.lisp,v $
;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;;;
;(in-package "COMMON-LISP-USER")

(defpackage :matlisp.system
   (:use :cl
         :asdf))

(in-package :matlisp.system)

(defvar *fortran-compiler* "g77")
(defvar *c-compiler* "gcc")
(defvar *linker* "ld")

;; just warn on warnings. Some of the f2cl generated files cause  
problems
;; without this.  See  
http://article.gmane.org/gmane.lisp.cclan.general/206
(setf asdf:*compile-file-failure-behaviour* :warn)

;;;BEGIN: code to do alien-files
(defclass unix-dso (module)
   ((dso-name :reader dso-name
              :initarg :dso-name)))

(defun unix-name (pathname)
   (namestring
    (typecase pathname
      (logical-pathname (translate-logical-pathname pathname))
      (t pathname))))

;; FIXME: this needs to know about alien-modules
(defmethod asdf::input-files ((operation compile-op) (dso unix-dso))
   (mapcar #'component-pathname (module-components dso)))
;  (mapcar #'(lambda (x)
;              (funcall #'asdf::input-files operation x))
;          (module-components dso)))


(defmethod output-files ((operation compile-op) (dso unix-dso))
   (let ((dir (component-pathname dso)))
     (list
      (make-pathname :type "so"
                     :name (dso-name dso)  ;(car (last  
(pathname-directory dir)))
                     :directory  (pathname-directory dir)
                             ;; (butlast (pathname-directory dir))
                     :defaults dir))))

(defclass alien-module (module) ())

(defmethod output-files ((op compile-op) (m alien-module))
   (mapcan (lambda (c)
             (output-files op c))
           (module-components m)))


(defmethod perform :after ((operation compile-op) (dso unix-dso))
   (let ((dso-name (unix-name (car (output-files operation dso)))))
     (unless (or (operation-done-p operation dso)
                 (zerop
                  (run-shell-command
                   "~A ~A -o ~S ~{~S ~} ~A"
                   *linker*
                                         ; (if (sb-ext:posix-getenv  
"LDFLAGS")
                                         ;     (sb-ext:posix-getenv  
"LDFLAGS")
                   #+sunos "-shared -lresolv -lsocket -lnsl"
                   #+darwin "-bundle -flat_namespace -undefined suppress"
                   #-(or darwin sunos) "-shared"
                                         ; )
                   dso-name
                   (mapcar #'unix-name
                           (mapcan (lambda (c)
                                     (output-files operation c))
                                   (module-components dso)))
                   #+darwin
                                         ;       "-L/sw/lib -lg2c -lm"   
;;probably need more here...
                   "-L/sw/lib -lf2c -lSystem -lcc_dynamic  
/usr/lib/bundle1.o"
                   #-darwin
                   "-L/usr/lib/gcc-lib/i486-linux/3.3.3  
-L/usr/lib/gcc-lib/i486-linux/3.3.3/../../.. -lfrtbegin -lg2c -lm  
-lgcc_s")))
       (error 'operation-error :operation operation :component dso))))

(defmethod output-files ((op compile-op) (c c-source-file))
   (list
    (make-pathname :type "o" :defaults
                   (component-pathname c))))

(defmethod perform ((op compile-op) (c c-source-file))
   (unless
       (= 0 (run-shell-command "~A ~A -o ~S -c ~S"
;                              (if (sb-ext:posix-getenv "CFLAGS")
;                                  (sb-ext:posix-getenv "CFLAGS")
;                                "-fPIC")
                               *c-compiler*
                               #+darwin "-fPIC -O3"
                               #-darwin "-fPIC -O3"
                               (unix-name (car (output-files op c)))
                               (unix-name (component-pathname c))))
     (error 'operation-error :operation op :component c)))

(defmethod perform ((operation load-op) (c c-source-file))
   t)


(defmethod perform ((o load-op) (c unix-dso))
   (let ((co (make-instance 'compile-op)))
     (let ((filename (car (output-files co c))))
       #+cmu (ext:load-foreign filename)
       #+sbcl (sb-alien:load-shared-object filename))))

(defclass fortran-source-file (source-file) ())
(defmethod asdf:source-file-type ((f fortran-source-file) (s module))  
"f")

(defmethod output-files ((op compile-op) (f fortran-source-file))
   (list
    (make-pathname :type "o" :defaults
                   (component-pathname f))))

(defmethod perform ((op compile-op) (f fortran-source-file))
   (unless
       (= 0 (run-shell-command "~A ~A -o ~S -c ~S"
                               *fortran-compiler*
                               #+darwin "-fPIC -O3"
                               #-darwin "-fPIC -O3"
                               (unix-name (car (output-files op f)))
                               (unix-name (component-pathname f))))
     (error 'operation-error :operation op :component f)))

(defmethod perform ((operation load-op) (f fortran-source-file))
   t)

;;;END: code to do alien-files


;; This is for macros.l which has a nonstandard suffix.
(defclass cl-source-file* (cl-source-file) ())
(defmethod asdf:source-file-type ((c cl-source-file*) (s module)) "l")

(defsystem :matlisp
                                         ;      :depends-on  
("lazy-loader"
                                         ;                    
"matlisp-packages")
     :components
   ((:unix-dso "alien code"
               :pathname ""
               :dso-name "lib/libmatlisp"
               :components
               ((:alien-module "BLAS"
                               :pathname "LAPACK/BLAS/SRC/"
                               :components
                        #.(mapcar (lambda (x)
                                           `(:fortran-source-file ,x))
                                  '("dgemm" "dswap" "dtrmv" "lsame"  
"zdotu"
                                    "zhemv" "ztrmv" "dgemv" "dsymv"  
"dtrsm"
                                    "zher2" "ztrsm" "dasum" "dger" "dsyr"
                                    "dtrsv" "zdscal" "zher2k" "ztrsv"  
"daxpy"
                                    "dsyr2" "dzasum" "xerbla" "zgemm"  
"zherk"
                                    "dcabs1" "dnrm2" "dsyr2k" "dznrm2"  
"zaxpy"
                                    "zgemv" "zscal" "dcopy" "drot"  
"dsyrk"
                                    "idamax" "zcopy" "zgerc" "zswap"  
"ddot"
                                    "dscal" "dtrmm" "izamax" "zdotc"  
"zgeru"
                                    "ztrmm" "dsymm")))
                (:alien-module "LAPACK"
                               :pathname "LAPACK/SRC/"
                               :components
                               #.(mapcar (lambda (x)
                                           `(:fortran-source-file ,x))
                                  '("dlasq5" "dlasq6" "ieeeck" "zdrot"  
"dlabad"
                                    "dlarf" "dorglq" "zhetd2" "zlatrs"  
"dbdsqr"
                                    "dlabrd" "dlarfb" "dorgql" "zhetrd"  
"zpotf2"
                                    "dgebak" "dlacon" "dlarfg" "dorgqr"  
"zhseqr"
                                    "zpotrf" "dgebal" "dlacpy" "dlarft"  
"dorgtr"
                                    "zbdsqr" "zlabrd" "zrot" "dgebd2"  
"dladiv"
                                    "dlarfx" "dorm2r" "zdrscl" "zlacgv"  
"zsteqr"
                                    "dgebrd" "dlae2" "dlartg" "dormbr"
                                    "zgebak" "zlacon" "ztrevc" "dgeesx"  
"dlaev2"
                                    "dlas2" "dorml2" "zgebal" "zlacpy"  
"ztrexc"
                                    "dgeev" "dlaexc" "dlascl" "dormlq"  
"zgebd2"
                                    "zladiv" "ztrsen" "dgehd2" "dlag2"  
"dlaset"
                                    "dormqr" "zgebrd" "zlahqr" "ztrsyl"
                                    "dgehrd" "dlahqr" "dlasq1" "drscl"  
"zgeesx"
                                    "zlahrd" "zung2l" "dgelq2" "dlahrd"  
"dlasq2"
                                    "dsteqr" "zgeev" "zlange" "zung2r"  
"dgelqf"
                                    "dlaln2" "dlasq3" "dsterf" "zgehd2"  
"zlanhe"
                                    "zungbr" "dgelss" "dlasq4" "dsyev"  
"zgehrd"
                                    "zlanhs" "zunghr" "dgeqp3" "dlaqp2"  
"dlaqps"
                                    "zgeqp3" "zlaqp2" "zlaqps" "dgeqpf"  
"dlasr"
                                    "dsytd2" "zgelq2" "zlarf" "zungl2"  
"dgeqr2"
                                    "dlasrt" "dsytrd" "zgelqf" "zlarfb"  
"zunglq"
                                    "dgeqrf" "dlassq" "dtrevc" "zgelss"  
"zlarfg"
                                    "zungql" "dlasv2" "dtrexc" "zgeqpf"  
"zlarft"
                                    "zungqr" "dgesvd" "dlamch" "dtrsen"  
"zgeqr2"
                                    "zlarfx" "zungtr" "dgetf2" "dlange"  
"dlasy2"
                                    "dtrsyl" "zgeqrf" "zlartg" "zunm2r"  
"dlanhs"
                                    "dlatrd" "dzsum1" "zlascl" "zunmbr"  
"dlanst"
                                    "dorg2l""ilaenv" "zgesvd" "zlaset"  
"zunml2"
                                    "dggbal" "dlansy" "dorg2r""izmax1"  
"zgetf2"
                                    "zlasr" "zunmlq" "dgghrd" "dlanv2"  
"dorgbr"
                                    "zlassq" "zunmqr" "dhgeqz" "dlapy2"  
"dorghr"
                                    "dhseqr" "dlapy3" "dorgl2" "zheev"
                                    "zlatrd"
                                    ;;Atlas lapack objects
                                    "dgetrf" "zgetrf" "dgetrs" "zgetrs"  
"dlaswp"
                                    "zlaswp" "dgesv" "zgesv"
                                    )))
                (:alien-module "DFFTPACK"
                               :pathname "dfftpack/"
                               :components
                               #.(mapcar (lambda (x)
                                           `(:fortran-source-file ,x))
                                  '("zfftb" "cfftb1" "zfftf" "cfftf1"  
"zffti"
                                    "cffti1" "dcosqb" "cosqb1" "dcosqf"
                                    "cosqf1" "dcosqi" "dcost" "dcosti"  
"ezfft1"
                                    "dzfftb" "dzfftf" "dzffti" "passb"  
"passb2"
                                    "passb3" "passb4" "passb5" "passf"  
"passf2"
                                    "passf3" "passf4" "passf5" "radb2"  
"radb3"
                                    "radb4" "radb5" "radbg" "radf2"  
"radf3"
                                    "radf4" "radf5" "radfg" "dfftb"  
"rfftb1"
                                    "dfftf" "rfftf1" "dffti" "rffti1"  
"dsinqb"
                                    "dsinqf" "dsinqi" "dsint" "sint1"
                                    "dsinti")))
                (:alien-module "CPOLY"
                               :pathname "lib-src/cpoly/"
                               :components
                               ((:fortran-source-file "cpoly")))
                (:alien-module "SPECFUN"
                               :pathname "lib-src/toms715/"
                               :components
                               #.(mapcar (lambda (x)
                                           `(:fortran-source-file ,x))
                                  '("anorm" "besei0" "besei1" "besek0"
                                    "besek1" "besi0" "besi1" "besj0"  
"besj1"
                                    "besk0" "besk1" "besy0" "besy1"  
"calcei"
                                    "calci0" "calci1" "calck0" "calck1"  
"calerf"
                                    "caljy0" "caljy1" "daw" "derf"  
"derfc"
                                    "derfcx" "dgamma" "dlgama" "dsubn"  
"ei"
                                    "eone" "expei" "machar" "psi"  
"ribesl"
                                    "rjbesl" "rkbesl" "rybesl")))))
    (:file "packages")
    #+(or)  ;; asdf now does the loading
    (:module "alien code"
             :pathname "lib/"
             :depends-on ("packages")
             :components
             ((:file "lazy-loader")))
    (:module "foreign-interface"
             :pathname "src/"
             :depends-on ("packages" "alien code")
             :components ((:file "f77-mangling")
                          #+:cmu (:file "ffi-cmu")
                          #+:sbcl (:file "ffi-sbcl")
                          #+:allegro (:file "ffi-acl")
                          ))
    (:module "foreign-functions"
             :pathname "src/"
             :depends-on ("foreign-interface" "alien code")
             :components ((:file "blas")
                          (:file "lapack")
                          #-:mswindows (:file "dfftpack")
                          #+nil (:file "ranlib")))
    (:module "matlisp-essentials"
             :pathname "src/"
             :depends-on ("foreign-interface"
                          "foreign-functions"
                          "alien code")
             :components ((:file "conditions")
                          (:file "matrix")
                          (:file "ref")
                          (:file "print")
                          (:file "copy")))
    (:module "matlisp-blas-wrappers"
             :pathname "src/"
             :depends-on ("foreign-interface"
                          "foreign-functions"
                          "matlisp-essentials"
                          "alien code")
             :components ((:file "axpy")
                          (:file "scal")
                          (:file "swap")
                          (:file "gemm")))

    (:module "matlisp-lapack-wrappers"
             :pathname "src/"
             :depends-on ("foreign-interface"
                          "foreign-functions"
                          "matlisp-essentials"
                          "alien code")
             :components ((:file "gesv")
                          (:file "geev")
                          (:file "getrf")
                          (:file "getrs")))

    (:module "matlisp-functions"
             :pathname "src/"
             :depends-on ("foreign-interface"
                          "foreign-functions"
                          "matlisp-essentials"
                          "matlisp-blas-wrappers"
                          "matlisp-lapack-wrappers"
                          "alien code")
             :components ((:file "compat")
                          (:file "help")
                          (:file "diag")
                          (:file "special")
                          (:file "reader")
                          (:file "trans")
                          (:file "realimag")
                          (:file "reshape")
                          (:file "join")
                          (:file "svd")
                          (:file "sum")
                          (:file "norm")
                          (:file "dot")
                          (:file "trace")
                          (:file "seq")
                          (:file "vec")
                          (:file "map")
                          (:file "mplus")
                          (:file "mminus")
                          (:file "mtimes")
                          (:file "mdivide")
                          (:file "msqrt")
                          #-:mswindows (:file "fft")
                          (:file "geqr")))
    (:module "special-functions"
             :pathname "src/"
             :depends-on ("matlisp-functions" "alien code")
             :components
             ((:file "specfun")))
    ;; Various add-on packages for matlisp
    ;; This is just the f2cl macros we need, not all of f2cl.
    (:module "f2cl-macros"
             :pathname "lib-src/"
                                         ;  :source-extension "l"
             :components
             ((:cl-source-file* "macros")))
    ;; This is Quadpack, converted from the Fortran
    ;; implementation to Lisp via f2cl.
    (:module "quadpack-functions"
             :pathname ""
                                         ; :source-pathname ""
                                         ; :binary-pathname ""
             :depends-on ("f2cl-macros" "alien code")
             :components
             ((:module "quadpack-interface"
                       :pathname "src/"
                       :components
                       ((:file "quadpack")))
              (:module "quadpack-lib"
                       :pathname "lib-src/quadpack/"
                       ;;                  :package "QUADPACK"
                       :components
                       (
                        #+nil
                        (:module mach-par
                                 :components
                                 ((:file "d1mach")
                                  (:file "i1mach")))
                        (:module src
                                 ;; :depends-on ("mach-par")
                                 :pathname ""
                                 :components
                                 (
                                  ;; Support
                                  (:file "dqwgtf")
                                  (:file "dqcheb")
                                  (:file "dqk15w")
                                  (:file "dqwgts")
                                  (:file "dqwgtc")
                                  (:file "dgtsl")
                                  (:file "xerror")

                                  ;; Core integration routines
                                  (:file "dqk15")
                                  (:file "dqk31")
                                  (:file "dqk41")
                                  (:file "dqk51")
                                  (:file "dqk61")
                                  (:file "dqk21")
                                  (:file "dqk15i")
                                  (:file "dqelg")
                                  (:file "dqpsrt")
                                  (:file "dqc25s"
                                         :depends-on ("dqcheb" "dqk15w"))
                                  (:file "dqmomo")
                                  (:file "dqc25c"
                                         :depends-on ("dqcheb"
                                                      "dqk15w"))
                                  (:file "dqc25f"
                                         :depends-on ("dgtsl"
                                                      "dqcheb"
                                                      "dqk15w"
                                                      "dqwgtf"))
                                  ;; Basic integrators
                                  (:file "dqage"
                                         :depends-on ("dqk15"
                                                      "dqk31"
                                                      "dqk41"
                                                      "dqk51"
                                                      "dqk61"
                                                      "dqk21"
                                                      "dqpsrt"))
                                  (:file "dqagie"
                                         :depends-on ("dqelg"
                                                      "dqk15i"
                                                      "dqpsrt"))
                                  (:file "dqagpe"
                                         :depends-on ("dqelg"
                                                      "dqpsrt"
                                                      "dqk21"
                                                      ))
                                  (:file "dqagse"
                                         :depends-on ("dqk21"
                                                      "dqelg"
                                                      "dqpsrt"))
                                  (:file "dqawfe"
                                         :depends-on ("dqagie"
                                                      "dqawoe"
                                                      "dqelg"))
                                  (:file "dqawoe"
                                         :depends-on ("dqc25f"
                                                      "dqpsrt"
                                                      "dqelg"))
                                  (:file "dqawse"
                                         :depends-on ("dqc25s"
                                                      "dqmomo"
                                                      "dqpsrt"))
                                  (:file "dqawce"
                                         :depends-on ("dqc25c"
                                                      "dqpsrt"))
                                  ;; Simplified interface routines
                                  (:file "dqng"
                                         :depends-on ("xerror"))
                                  (:file "dqag"
                                         :depends-on ("dqage"
                                                      "xerror"))
                                  (:file "dqags"
                                         :depends-on ("dqagse"
                                                      "xerror"))
                                  (:file "dqagi"
                                         :depends-on ("dqagie"
                                                      "xerror"))
                                  (:file "dqawf"
                                         :depends-on ("dqawfe"
                                                      "xerror"))
                                  (:file "dqawo"
                                         :depends-on ("dqawoe"
                                                      "xerror"))
                                  (:file "dqaws"
                                         :depends-on ("dqawse"
                                                      "xerror"))
                                  (:file "dqawc"
                                         :depends-on ("dqawce"
                                                      "xerror"))))))))
    (:module "minpack-functions"
             :depends-on ("f2cl-macros" "alien code")
             :pathname ""
             :components
             (
              #+nil
              (:module "quadpack-interface"
                       :pathname "src/"
                       :components
                       ((:file "quadpack")))
              (:module "minpack-lib"
                       :pathname "lib-src/minpack/"
                       ;;    :package "MINPACK"
                       :components
                       ((:file "dpmpar")
                        (:file "enorm")
                        (:file "fdjac2")
                        (:file "qrsolv")
                        (:file "lmpar")
                        (:file "qrfac")
                        (:file "lmdif")
                        (:file "lmdif1")
                        (:file "lmder")
                        (:file "lmder1")
                        (:file "dogleg")
                        (:file "qform")
                        (:file "r1mpyq")
                        (:file "r1updt")
                        (:file "hybrj" :depends-on ("dogleg" "qform"  
"r1mpyq" "r1updt"))
                        (:file "hybrj1" :depends-on ("hybrj"))
                        ))))
    (:module "lib-src"
             :components
             (#+nil
              (:file "d1mach"
                     :package "MATLISP-LIB")
              (:module "cpoly"
                       :components
                       ((:file "cpoly")
                        (:file "zeroin")))
              #+(or :cmu :sbcl)
              (:module "gnuplot"
                       :components
                       ((:file "gnuplot")))))))

;; needed for lazy-loader

(setf (logical-pathname-translations "matlisp")
       (let ((matlisp-pathname
              (asdf:component-pathname (asdf:find-system :matlisp))))
         `(("**;*.*.*"
            ,(namestring (merge-pathnames "**/*.*" matlisp-pathname)))
           ("*.*.*"
            ,(namestring (merge-pathnames "*.*" matlisp-pathname))))))


--
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index
"Politeness, n. The most acceptable hypocrisy." - Ambrose Bierce, The  
Devil's Dictionary

Re: [Matlisp-users] matlisp migration trouble (missing symbol)

[rif <ri...@MI...>]

Thanks for the tip.  I think the problem has to do with the fact that
on my laptop, the ATLAS libraries are dynamic, but on the new machine,
they're static.  So when matlisp itself gets loaded, in the dynamic
library case, it can get at all the symbols, so I can access dpotrf_
later.  Its in the *static* case that if it doesn't already need
dpotrf_, it doesn't bother importing it.  I "fixed" it on the new
machine by explicitly loading the lapack library specifically, and
that did fix the immediate problem.

However, I am beginning to believe (largely for the reasons mentioned
by Tunc) that a better solution is for me to extend matlisp itself
prior to matlisp compilation (and keep patches so that I can apply to
new downloads of matlisp).  At this point, I believe that I can do
this by modifying lazy-loader.c and matlisp.mk.in to add the desired
routine, adding a lisp routine that calls define-fortran-function, and
adding a mention of the file containing this routine to system.dcl.
Is there anything else I should need to touch?  Does this seem like a
reasonable approach?

rif

> Hey,
> 
> Try adding an external declaration and a dummy call to "dpotrf_"
> in the file lazy-loader.c.  Then do a remake.
> 
> I originally picked the name "lazy" loader because, upon loading
> a dynamic library, on some platforms, only those symbols which are
> explicitly referenced were being loaded.  This is the purpose of
> the dummy call.
> 
> ----- Original Message -----
> From: rif <ri...@MI...>
> Date: Monday, December 20, 2004 3:25 pm
> Subject: Re: [Matlisp-users] matlisp migration trouble (missing symbol)
> 
> > 
> > > >>>>> "rif" == rif  <ri...@MI...> writes:
> > > 
> > >     rif> Once matlab is loaded, I have a file where I def-
> > fortran-routine
> > >     rif> dpotrf.  This scheme works fine on my laptop, but on 
> > the other
> > >     rif> machine, when I try to load this file, I get the error:
> > > 
> > >     rif> Undefined foreign symbol: "dpotrf_"
> > >     rif>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> > > 
> > > This sounds like dpotrf is not in the matlisp LAPACK/BLAS library.
> > > Are you sure both platforms have identical libraries?  It may happen
> > > that we don't compile all the LAPACK routines if we don't have a
> > > matlisp interface to them.
> > > 
> > > Ray
> > 
> > OK, my understanding is increasing, but I'm not all the way there yet.
> > As I now understand, matlisp does not by default load all of lapack,
> > but only what it needs.  When you specify --with-atlas= at config
> > time, matlisp loads the atlas lapack library (this is also a 
> > subset of
> > lapack, but it contains the routines I need).  So this explains 
> > why my
> > stuff doesn't work without atlas, on either the laptop or the new
> > machine.
> > 
> > What I still don't get is why, when I specify a --with-atlas=, it
> > works on the laptop but not the new machine.  Looking into
> > lazy-loader.lisp, part of the call to ext::load-foreign includes the
> > arguments (to be tokenized):
> > 
> > "-L/cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4/" " " "-llapack
> > -lcblas -lf77blas -latlas" " "
> > 
> > This code is clearly being run (if I add some made-up library name I
> > get an error), so it's finding (and AFAIK loading) the libraries it
> > wants.  Furthermore, dpotrf_ appears to be in the library:
> > 
> > [rif@node-06 Linux_P4SSE2_4]$ pwd
> > /cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4
> > [rif@node-06 Linux_P4SSE2_4]$ nm liblapack.a  | grep dpotrf_
> > 00000000 T atl_f77wrap_dpotrf__
> >         U atl_f77wrap_dpotrf__
> > 00000000 T dpotrf_
> > 
> > Nevertheless, when I try to compile and then load a file 
> > containing a
> > def-foreign-function for dpotrf, it fails on this machine with an
> > "Undefined symbol dpotrf_ error" (this works on my laptop).  Note that
> > I seem to be able to just load the .lisp file directly, but compiling
> > it then loading it yields the undefined symbol error --- I don't know
> > if this is relevant.
> > 
> > In case anyone wants it, I've put the file matlisp-ext-lapack.lisp in
> > http://fpn.mit.edu/Downloads.  My goal is to, after loading matlisp,
> > be able to compile and load this file.
> > 
> > As a side question, is there any easy way to tell what exactly library
> > files ext::load-foreign is actually picking up?  This could be helpful
> > for debugging purposes.
> > 
> > Again, any help is appreciated.
> > 
> > Cheers,
> > 
> > rif
> > 
> > 
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real 
> > users.Discover which products truly live up to the hype. Start 
> > reading now. 
> > http://productguide.itmanagersjournal.com/
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> > 
> 

Re: [Matlisp-users] matlisp migration trouble (missing symbol)

[<si...@EE...>]

Hey,

Try adding an external declaration and a dummy call to "dpotrf_"
in the file lazy-loader.c.  Then do a remake.

I originally picked the name "lazy" loader because, upon loading
a dynamic library, on some platforms, only those symbols which are
explicitly referenced were being loaded.  This is the purpose of
the dummy call.

----- Original Message -----
From: rif <ri...@MI...>
Date: Monday, December 20, 2004 3:25 pm
Subject: Re: [Matlisp-users] matlisp migration trouble (missing symbol)

> 
> > >>>>> "rif" == rif  <ri...@MI...> writes:
> > 
> >     rif> Once matlab is loaded, I have a file where I def-
> fortran-routine
> >     rif> dpotrf.  This scheme works fine on my laptop, but on 
> the other
> >     rif> machine, when I try to load this file, I get the error:
> > 
> >     rif> Undefined foreign symbol: "dpotrf_"
> >     rif>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> > 
> > This sounds like dpotrf is not in the matlisp LAPACK/BLAS library.
> > Are you sure both platforms have identical libraries?  It may happen
> > that we don't compile all the LAPACK routines if we don't have a
> > matlisp interface to them.
> > 
> > Ray
> 
> OK, my understanding is increasing, but I'm not all the way there yet.
> As I now understand, matlisp does not by default load all of lapack,
> but only what it needs.  When you specify --with-atlas= at config
> time, matlisp loads the atlas lapack library (this is also a 
> subset of
> lapack, but it contains the routines I need).  So this explains 
> why my
> stuff doesn't work without atlas, on either the laptop or the new
> machine.
> 
> What I still don't get is why, when I specify a --with-atlas=, it
> works on the laptop but not the new machine.  Looking into
> lazy-loader.lisp, part of the call to ext::load-foreign includes the
> arguments (to be tokenized):
> 
> "-L/cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4/" " " "-llapack
> -lcblas -lf77blas -latlas" " "
> 
> This code is clearly being run (if I add some made-up library name I
> get an error), so it's finding (and AFAIK loading) the libraries it
> wants.  Furthermore, dpotrf_ appears to be in the library:
> 
> [rif@node-06 Linux_P4SSE2_4]$ pwd
> /cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4
> [rif@node-06 Linux_P4SSE2_4]$ nm liblapack.a  | grep dpotrf_
> 00000000 T atl_f77wrap_dpotrf__
>         U atl_f77wrap_dpotrf__
> 00000000 T dpotrf_
> 
> Nevertheless, when I try to compile and then load a file 
> containing a
> def-foreign-function for dpotrf, it fails on this machine with an
> "Undefined symbol dpotrf_ error" (this works on my laptop).  Note that
> I seem to be able to just load the .lisp file directly, but compiling
> it then loading it yields the undefined symbol error --- I don't know
> if this is relevant.
> 
> In case anyone wants it, I've put the file matlisp-ext-lapack.lisp in
> http://fpn.mit.edu/Downloads.  My goal is to, after loading matlisp,
> be able to compile and load this file.
> 
> As a side question, is there any easy way to tell what exactly library
> files ext::load-foreign is actually picking up?  This could be helpful
> for debugging purposes.
> 
> Again, any help is appreciated.
> 
> Cheers,
> 
> rif
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.Discover which products truly live up to the hype. Start 
> reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] matlisp migration trouble (missing symbol)

[rif <ri...@MI...>]

> >>>>> "rif" == rif  <ri...@MI...> writes:
> 
>     rif> Once matlab is loaded, I have a file where I def-fortran-routine
>     rif> dpotrf.  This scheme works fine on my laptop, but on the other
>     rif> machine, when I try to load this file, I get the error:
> 
>     rif> Undefined foreign symbol: "dpotrf_"
>     rif>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
> 
> This sounds like dpotrf is not in the matlisp LAPACK/BLAS library.
> Are you sure both platforms have identical libraries?  It may happen
> that we don't compile all the LAPACK routines if we don't have a
> matlisp interface to them.
> 
> Ray

OK, my understanding is increasing, but I'm not all the way there yet.
As I now understand, matlisp does not by default load all of lapack,
but only what it needs.  When you specify --with-atlas= at config
time, matlisp loads the atlas lapack library (this is also a subset of
lapack, but it contains the routines I need).  So this explains why my
stuff doesn't work without atlas, on either the laptop or the new
machine.

What I still don't get is why, when I specify a --with-atlas=, it
works on the laptop but not the new machine.  Looking into
lazy-loader.lisp, part of the call to ext::load-foreign includes the
arguments (to be tokenized):

"-L/cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4/" " " "-llapack
-lcblas -lf77blas -latlas" " "

This code is clearly being run (if I add some made-up library name I
get an error), so it's finding (and AFAIK loading) the libraries it
wants.  Furthermore, dpotrf_ appears to be in the library:

[rif@node-06 Linux_P4SSE2_4]$ pwd
/cbcl/cbcl01/rif/Software/ATLAS/lib/Linux_P4SSE2_4
[rif@node-06 Linux_P4SSE2_4]$ nm liblapack.a  | grep dpotrf_
00000000 T atl_f77wrap_dpotrf__
         U atl_f77wrap_dpotrf__
00000000 T dpotrf_

Nevertheless, when I try to compile and then load a file containing a
def-foreign-function for dpotrf, it fails on this machine with an
"Undefined symbol dpotrf_ error" (this works on my laptop).  Note that
I seem to be able to just load the .lisp file directly, but compiling
it then loading it yields the undefined symbol error --- I don't know
if this is relevant.

In case anyone wants it, I've put the file matlisp-ext-lapack.lisp in
http://fpn.mit.edu/Downloads.  My goal is to, after loading matlisp,
be able to compile and load this file.

As a side question, is there any easy way to tell what exactly library
files ext::load-foreign is actually picking up?  This could be helpful
for debugging purposes.

Again, any help is appreciated.

Cheers,

rif

Re: [Matlisp-users] matlisp migration trouble (missing symbol)

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

>>>>> "rif" == rif  <ri...@MI...> writes:

    rif> Once matlab is loaded, I have a file where I def-fortran-routine
    rif> dpotrf.  This scheme works fine on my laptop, but on the other
    rif> machine, when I try to load this file, I get the error:

    rif> Undefined foreign symbol: "dpotrf_"
    rif>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

This sounds like dpotrf is not in the matlisp LAPACK/BLAS library.
Are you sure both platforms have identical libraries?  It may happen
that we don't compile all the LAPACK routines if we don't have a
matlisp interface to them.

Ray

Re: [Matlisp-users] Some questions (LAPACK source, QZ, Debian)

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

>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:

    Nicolas> Nevertheless, it might be nice (and probably faster, if those routines are
    Nicolas> optimized) to use already installed libraries (e.g. from Debian packages).

I think it should be straightforward to allow using precompiled
libraries if they exist.  As long as someone is willing to test
it. :-)

    Nicolas> Are there important differences for the Matlisp version of LAPACK?  I
    Nicolas> remember having read about small changes?

I'd have to check logs to be sure, but LAPACK is basically what comes
from netlib.  There might have been one or two fixes applied for some
bugs. 

Ray

[Matlisp-users] matlisp migration trouble (missing symbol)

[rif <ri...@MI...>]

I've been using matlisp extensively on my debian laptop.  I'm trying
to migrate code to a different linux machine, which I believe is
running RedHat.

I extend matlisp slightly.  In particular, I wrap some additional
commands, among them dpotrf for doing Cholesky factorization.  This
extension is done in code that runs after matlisp is loaded, rather
than matlisp proper.

I'm using the matlisp-2.0beta-2003-10-14, which I believed I used on
my laptop as well.  In both cases, I'm linking against atlas.

Once matlab is loaded, I have a file where I def-fortran-routine
dpotrf.  This scheme works fine on my laptop, but on the other
machine, when I try to load this file, I get the error:

Undefined foreign symbol: "dpotrf_"
   [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

Doing a grep on dpotrf in both the laptop and desktop matlisps yields
identical results:

rif@felix:~/Software/matlisp-atlas-sse2$ egrep -r dpotrf *
lapack.system:     (:file "dpotrf")
Binary file lib/LAPACK.dll matches
lib/LAPACK.h:extern BLAS_API int dpotrf_(char *uplo, integer *n, doublereal *a, integer *lda, integer *info);
Binary file lib/LAPACK.lib matches

I'm not sure what could be different between the two systems, or what
to look for.  On the cluster machine, I've tried it both with and
without the atlas libraries; I get the same error either way.

Any help or suggestions are appreciated.

Cheers,

rif

Re: [Matlisp-users] Some questions (LAPACK source, QZ, Debian)

[Nicolas N. <Nic...@iw...>]

si...@EE... writes:

>> 1. I have just installed CVS matlisp on my Debian system 
>> (everything worked
>> fine).  What I do not understand is the following: although I have
>> configured it to use the ATLAS libraries, the LAPACK source is 
>> compiled.Why is this necessary?
>
> IIRC, Atlas is a fast implementation of BLAS only.  It does not
> contain the LAPACK routines.

Oh, I got that slightly wrong, then.  They write on their homepage:

  At present, it provides C and Fortran77 interfaces to a portably
  efficient BLAS implementation, as well as a few routines from LAPACK.

and I forgot the "few" since I looked last time.

Nevertheless, it might be nice (and probably faster, if those routines are
optimized) to use already installed libraries (e.g. from Debian packages).
Are there important differences for the Matlisp version of LAPACK?  I
remember having read about small changes?

Yours, Nicolas.

[Matlisp-users] Some questions (LAPACK source, QZ, Debian)

[Nicolas N. <Nic...@iw...>]

Hello,

I have some questions:

1. I have just installed CVS matlisp on my Debian system (everything worked
fine).  What I do not understand is the following: although I have
configured it to use the ATLAS libraries, the LAPACK source is compiled.
Why is this necessary?

2. I would need access to LAPACK's QZ method for generalized EVP and I am
thinking about writing a Matlisp interface to it.  Did anyone do something
in this direction already?

3. I am curious about how much work it would be to create a Debian package
for Matlisp.  Does anyone on this list have experience with this?

Thanks for any information,

Nicolas.

Re: [Matlisp-users] help with gross array hack needed

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

>>>>> "rif" == rif  <ri...@MI...> writes:


    rif> Alternately, within matlisp, is there an easy way to extend (for
    rif> example) vector-data-address to work on a (simple-array double-float
    rif> *) in the right way?  Right now, it fails on the check-type, because
    rif> it requires a simple-array.

Yes, it can be extended.  Sufficient uses of array-displacement and
(typep foo 'simple-array) should allow you to track down the real
simple-array so vector-data-address will work.

But this no longer has anything to do with cmucl, so perhaps the
matlisp mailing list is the right place to talk about this?

Ray

Re: [Matlisp-users] help with gross array hack needed

[rif <ri...@MI...>]

> Not necessarily.  Displaced arrays are good for row-major slices.  So 
> if the matrix where (N + 1 x N), then you could "displace away" the 
> first row.  Unfortunately, FORTRAN is column-major.  The only way I see 
> around this is to transpose the array first, and then displace.  
> However, that may cause problems for the algorithm at hand.
> 
> Isn't this fun? :)

> Marco Antoniotti					http://bioinformatics.nyu.edu

Actually, I'm OK with row-major vs. column-major, because all my
matlisp arrays are stored as 1d column-major arrays in CL.

The real problem with displacement is that displacing a (simple-array
double-float *) produces a (vector double-float *), and therefore I
cannot write something like:

(defmethod displaced-matrix ((m real-matrix) (start-column fixnum))
  (let* ((nc (number-of-cols m))
         (nr (number-of-rows m))
         (new-columns (- nc start-column)))
    (make-instance 'real-matrix 
		   :nrows nr
		   :ncols (- nc start-column)
		   :store (make-array (* nr new-columns)
                   :element-type 'double-float
		   :displaced-to (matlisp::store m)
		   :displaced-index-offset (* nr start-column)))))

Is there any (obviously, implementation specific way) to do a
displaced (simple-array double-float *) --- this was my original
question?

Alternately, within matlisp, is there an easy way to extend (for
example) vector-data-address to work on a (simple-array double-float
*) in the right way?  Right now, it fails on the check-type, because
it requires a simple-array.

Cheers,

rif

ps.  Obviously, I can do what I want with sufficient effort.  For
instance, I could define my own interface to the Fortran functions
which take pointers directly, and then do the pointer arithmetic
myself.  This seems like a lot of work, and I'm attempting to avoid
this, though I may have to do it if there's no other way.

Re: [Matlisp-users] help with gross array hack needed

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

On Dec 8, 2004, at 7:43 AM, Raymond Toy wrote:

>>>>>> "rif" == rif  <ri...@MI...> writes:
>
>     rif> Is there any way, in CMUCL, using some implementation-specific
>     rif> construct, to create an "aliased array"?  Suppose I create a
>     rif> double-float array of size 10:
>
>     rif> (make-array 10 :element-type 'double-float)
>
>     rif> I know I can take it's address, with #'system:vector-sap.
>
>     rif> What I want to do is manipulate that address and somehow 
> "invert"
>     rif> vector-sap to create a new double-float array whose first 
> element is
>     rif> (for example) the third element of the original array.
>
>     rif> I need this because I need to pass matlisp a subset of an 
> array.  More
>     rif> specifically, I want to allocate an n by n+1 array, so that I 
> can
>     rif> store half of each of two n by n symmetric arrays in n(n+1) 
> space
>     rif> rather than 2n^2 space.  This is a common technique for using
>     rif> BLAS/LAPACK, but to get at it, I need to be able to give a 
> Fortran
>     rif> matlisp routine a way to get at the square n by n matrix that 
> "starts
>     rif> with the second column" of the n by n+1 matrix, and the way 
> the
>     rif> interface is defined, it wants actual arrays, not pointers.  
> If I can
>     rif> somehow create the appropriate array, I don't have to go 
> mucking about
>     rif> in the internals of matlisp's def-fortran-routine and so 
> forth.
>
> Marc has already mentioned displaced arrays.  This should work, but
> depends on what you are really trying to do.

Not necessarily.  Displaced arrays are good for row-major slices.  So 
if the matrix where (N + 1 x N), then you could "displace away" the 
first row.  Unfortunately, FORTRAN is column-major.  The only way I see 
around this is to transpose the array first, and then displace.  
However, that may cause problems for the algorithm at hand.

Isn't this fun? :)

Cheers



--
Marco Antoniotti					http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group		tel. +1 - 212 - 998 3488
715 Broadway 10th FL				fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

Re: [Matlisp-users] help with gross array hack needed

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

>>>>> "rif" == rif  <ri...@MI...> writes:

    rif> Is there any way, in CMUCL, using some implementation-specific
    rif> construct, to create an "aliased array"?  Suppose I create a
    rif> double-float array of size 10:

    rif> (make-array 10 :element-type 'double-float)

    rif> I know I can take it's address, with #'system:vector-sap.

    rif> What I want to do is manipulate that address and somehow "invert"
    rif> vector-sap to create a new double-float array whose first element is
    rif> (for example) the third element of the original array.

    rif> I need this because I need to pass matlisp a subset of an array.  More
    rif> specifically, I want to allocate an n by n+1 array, so that I can
    rif> store half of each of two n by n symmetric arrays in n(n+1) space
    rif> rather than 2n^2 space.  This is a common technique for using
    rif> BLAS/LAPACK, but to get at it, I need to be able to give a Fortran
    rif> matlisp routine a way to get at the square n by n matrix that "starts
    rif> with the second column" of the n by n+1 matrix, and the way the
    rif> interface is defined, it wants actual arrays, not pointers.  If I can
    rif> somehow create the appropriate array, I don't have to go mucking about
    rif> in the internals of matlisp's def-fortran-routine and so forth.

Marc has already mentioned displaced arrays.  This should work, but
depends on what you are really trying to do.  What matlisp function
are you trying to call?

Ray

[Matlisp-users] Re: help with gross array hack needed

[Marcin T. <mm...@ze...>]

http://www.lisp.org/HyperSpec/Body/glo_d.html#displaced_array

[Matlisp-users] help with gross array hack needed

[rif <ri...@MI...>]

Is there any way, in CMUCL, using some implementation-specific
construct, to create an "aliased array"?  Suppose I create a
double-float array of size 10:

(make-array 10 :element-type 'double-float)

I know I can take it's address, with #'system:vector-sap.

What I want to do is manipulate that address and somehow "invert"
vector-sap to create a new double-float array whose first element is
(for example) the third element of the original array.

I need this because I need to pass matlisp a subset of an array.  More
specifically, I want to allocate an n by n+1 array, so that I can
store half of each of two n by n symmetric arrays in n(n+1) space
rather than 2n^2 space.  This is a common technique for using
BLAS/LAPACK, but to get at it, I need to be able to give a Fortran
matlisp routine a way to get at the square n by n matrix that "starts
with the second column" of the n by n+1 matrix, and the way the
interface is defined, it wants actual arrays, not pointers.  If I can
somehow create the appropriate array, I don't have to go mucking about
in the internals of matlisp's def-fortran-routine and so forth.

(Note that I only need this "aliased array" temporarily, and I'd of
course turn gc off while I needed it.)

Any suggestions or advice are appreciated.  If you respond, please cc
to rif directly --- I think I'm on both these lists, but I'm not 100%
sure.

rif

Re: [Matlisp-users] (SETF (MATRIX-REF ...) ... ) problem?

[Michael A. K. <ma...@ll...>]

Ray,

   tnx for the quick response!

mike
-- 
---------------------
Dr Michael A. Koerber
x3250