Menu
▾
▴
matlisp-users — General discussion list.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(8) |
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2002 |
Jan
(2) |
Feb
(7) |
Mar
(14) |
Apr
|
May
|
Jun
(16) |
Jul
(7) |
Aug
(5) |
Sep
(28) |
Oct
(9) |
Nov
(26) |
Dec
(3) |
| 2003 |
Jan
|
Feb
(6) |
Mar
(4) |
Apr
(16) |
May
|
Jun
(8) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
(33) |
Nov
(13) |
Dec
|
| 2004 |
Jan
(2) |
Feb
(16) |
Mar
|
Apr
(2) |
May
(35) |
Jun
(8) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(8) |
Dec
(21) |
| 2005 |
Jan
(7) |
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(18) |
Sep
(2) |
Oct
|
Nov
(3) |
Dec
(31) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
(7) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2014 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marco A. <ma...@cs...> - 2002-06-13 17:08:24
|
> X-Authentication-Warning: edgedsp4.rtp.ericsson.se: toy set sender to to...@rt... using -f > Cc: Mat...@li... > From: Raymond Toy <to...@rt...> > Sender: mat...@li... > X-Original-Date: 13 Jun 2002 12:12:44 -0400 > Date: 13 Jun 2002 12:12:44 -0400 > X-Filter-Version: 1.8 (cat) > > >>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes: > > Marco> the version of MK:DEFSYSTEM distributed with MatLisp is most likely > Marco> out of date. An upgrade is needed. Please substitute it with the > > The version in the file release definitely is, but the one in the CVS > repository isn't too bad. According to the logs, it was synced on > 2001/12/30. At least it works with 18d for me. I just made a new File Release for MK:DEFSYSTEM in the CLOCC. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. |
|
From: Raymond T. <to...@rt...> - 2002-06-13 16:22:14
|
>>>>> "Tunc" == Tunc Simsek <si...@ee...> writes:
Tunc> Hi Ray, Jefferson;
Tunc> I've played with Allegro 6.0 as follows (I asked it to explain
Tunc> the compilation of m.*!):
Tunc> (defmethod m.*! ((a real-matrix) (b real-matrix))
Tunc> (let* ((nxm (number-of-elements b)))
Tunc> (declare (type fixnum nxm)
Tunc> (optimize (speed 3) (safety 0)))
Tunc> (dotimes (k nxm b)
Tunc> (declare (type fixnum k))
Tunc> (let ((a-val (matrix-ref a k))
Tunc> (b-val (matrix-ref b k)))
Tunc> (declare (type real-matrix-element-type a-val b-val)
Tunc> (:explain :calls :types :boxing))
Tunc> (setf (matrix-ref b k) (* a-val b-val))))))
Jefferson, do you still need this optimized? I think Tunc's version
is good enough when both matrices are real. The complex-valued
versions need to be done.
Ray
|
|
From: Raymond T. <to...@rt...> - 2002-06-13 16:13:02
|
>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:
Marco> the version of MK:DEFSYSTEM distributed with MatLisp is most likely
Marco> out of date. An upgrade is needed. Please substitute it with the
The version in the file release definitely is, but the one in the CVS
repository isn't too bad. According to the logs, it was synced on
2001/12/30. At least it works with 18d for me.
Yes, I need to do a new file release for matlisp....
Ray
|
|
From: Tunc S. <si...@ee...> - 2002-06-12 00:31:44
|
Just for the fun of it :) Tunc Marco Antoniotti wrote: > > Hi > > the version of MK:DEFSYSTEM distributed with MatLisp is most likely > out of date. An upgrade is needed. Please substitute it with the > version from the CLOCC. (http://sourceforge.net/projects/clocc). > The CVS version is better. I will put out a new File Release soon, > but not today or tomorrow (real work getting in the way) > > Cheers > > -- > Marco Antoniotti ======================================================== > NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 > 719 Broadway 12th Floor fax +1 - 212 - 995 4122 > New York, NY 10003, USA http://bioinformatics.cat.nyu.edu > "Hello New York! We'll do what we can!" > Bill Murray in `Ghostbusters'. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Matlisp-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlisp-users |
|
From: Marco A. <ma...@cs...> - 2002-06-11 14:34:46
|
Hi the version of MK:DEFSYSTEM distributed with MatLisp is most likely out of date. An upgrade is needed. Please substitute it with the version from the CLOCC. (http://sourceforge.net/projects/clocc). The CVS version is better. I will put out a new File Release soon, but not today or tomorrow (real work getting in the way) Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. |
|
From: Nicolas N. <Nic...@iw...> - 2002-03-28 10:56:42
|
Hello, Ray and other matlisp users.
The problem was that I was using gcc-2.95.4 (which is said to be
broken). I thought that I had done the upgrade to gcc-3.0 already,
but it seems that the links were not updated automatically.
When I changed the links in /usr/bin to gcc-3.0.3, everything worked
fine.
Thanks again and happy Easter,
Nicolas.
__ __
(_ \ / _)
\ \/ /
.____ ('*' ) Hands off dem eggs pal
--=_\===(~ )) if'n ya know
__( )( )__ whats good for
MJP(____) (____) ya.....
|
|
From: Marco A. <ma...@cs...> - 2002-03-26 19:09:48
|
> Cc: Nicolas Neuss <Nic...@iw...>, > Mat...@li... > From: Nicolas Neuss <Nic...@iw...> > Sender: mat...@li... > X-BeenThere: mat...@li... > X-Mailman-Version: 2.0.5 > Precedence: bulk > List-Help: <mailto:mat...@li...?subject=help> > List-Post: <mailto:mat...@li...> > List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/matlisp-users>, > <mailto:mat...@li...?subject=subscribe> > List-Id: Matlisp users mailing list. <matlisp-users.lists.sourceforge.net> > List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/matlisp-users>, > <mailto:mat...@li...?subject=unsubscribe> > List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=matlisp-users> > X-Original-Date: 26 Mar 2002 16:23:34 +0100 > Date: 26 Mar 2002 16:23:34 +0100 > Content-Length: 1612 > > Raymond Toy <to...@rt...> writes: > > > > > Ok, before -lm, can you add -lc? Like so: > > > > " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm")))) > > > > Then try rebuilding. I hope that takes care of the problem. If so, > > then it's my problem to figure out why configure isn't adding -lc. > > > > Ray > > Doesn't work, unfortunately... > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))' > ; Loading #p"/usr/local/src/matlisp/start.lisp". > Converted SETLOGICALROOT. > Converted GETLOGICALROOT. > Converted DEFLOGICALPATH. > ;; Loading #p"/usr/local/src/matlisp/system.dcl". > ;; Loading #p"/usr/local/src/matlisp/config.lisp". > > > Error in function SYSTEM::LOAD-OBJECT-FILE: > Can't open object "/tmp/29938AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat" > > Restarts: > 0: [CONTINUE] Return NIL from load of "start.lisp". > 1: [ABORT ] Skip remaining initializations. > > Debug (type H for help) > > (SYSTEM::LOAD-OBJECT-FILE "/tmp/29938AG0") > Source: Error finding source: > Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: > target:code/foreign.lisp. > 0] > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > The problem could be in defsystem, maybe? I've seen that CMUCL has > some version now integrated, matlisp has another one, and there is the > one at CLOCC, ... How is the connection between those? The connection is the following: the CLOCC version is the official one. The next CMUCL distribution will remove the defsystem. Matlisp should do the same. Cheers -- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'. |
|
From: Raymond T. <to...@rt...> - 2002-03-26 17:34:37
|
>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
Nicolas> Raymond Toy <to...@rt...> writes:
>> If you're sure that the right lazy-loader is being used, then, I'll
>> have to try this on my Linux box at home. It's not debian, but that
>> shouldn't matter when building matlisp.
>>
>> Ray
Nicolas> That would be nice. Thank you.
Hmm. I tried this on a RH 7.1 Linux box with a fairly recent CMUCL
CVS build. I can't reproduce this bug.
And I'm not really motivated to download the Debian CMUCL package.
I'm also surprised that fstat is used by anything in matlisp. I'm
pretty sure none of LAPACK and friends knows or cares about files. It
must be coming from either the lisp binary itself or -lg2c. Adding
-lc should have fixed that.
Maybe the lisp binary needs to be compiled with the export-dynamic (?)
switch. I vaguely recall some discussion about this.
I'm sorry I can't help much here.
Ray
|
|
From: Nicolas N. <Nic...@iw...> - 2002-03-26 16:12:57
|
Raymond Toy <to...@rt...> writes:
> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
>
> Nicolas> Raymond Toy <to...@rt...> writes:
> >>
> >> Ok, before -lm, can you add -lc? Like so:
> >>
> >> " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm"))))
> >>
> >> Then try rebuilding. I hope that takes care of the problem. If so,
> >> then it's my problem to figure out why configure isn't adding -lc.
> >>
> >> Ray
>
> Nicolas> Doesn't work, unfortunately...
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Nicolas> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))'
> Nicolas> ; Loading #p"/usr/local/src/matlisp/start.lisp".
> Nicolas> Converted SETLOGICALROOT.
> Nicolas> Converted GETLOGICALROOT.
> Nicolas> Converted DEFLOGICALPATH.
> Nicolas> ;; Loading #p"/usr/local/src/matlisp/system.dcl".
> Nicolas> ;; Loading #p"/usr/local/src/matlisp/config.lisp".
>
>
> Nicolas> Error in function SYSTEM::LOAD-OBJECT-FILE:
> Nicolas> Can't open object "/tmp/29938AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat"
>
> Are you sure that the new lazy-loader is being loaded? Your output
> doesn't really say.
>
I'm very sure: after the error appeared, I did:
(function-lambda-expression #'matlisp::load-blas-&-lapack-libraries)
with the result:
(LAMBDA ()
(BLOCK MATLISP:LOAD-BLAS-&-LAPACK-LIBRARIES
(LOAD-FOREIGN "matlisp:lib;lazy-loader.o"
:LIBRARIES
(MATLISP::TOKENIZE-LD-ARGS
(CONCATENATE 'STRING
""
" "
""
" "
"-L"
(NAMESTRING
(TRANSLATE-LOGICAL-PATHNAME "matlisp:lib"))
" "
"-R"
(NAMESTRING
(TRANSLATE-LOGICAL-PATHNAME "matlisp:lib"))
" "
"-lmatlisp"
" "
" -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm")))))
NIL
MATLISP:LOAD-BLAS-&-LAPACK-LIBRARIES
> If you're sure that the right lazy-loader is being used, then, I'll
> have to try this on my Linux box at home. It's not debian, but that
> shouldn't matter when building matlisp.
>
> Ray
That would be nice. Thank you.
Nicolas.
|
|
From: Raymond T. <to...@rt...> - 2002-03-26 15:30:56
|
>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
Nicolas> Raymond Toy <to...@rt...> writes:
>>
>> Ok, before -lm, can you add -lc? Like so:
>>
>> " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm"))))
>>
>> Then try rebuilding. I hope that takes care of the problem. If so,
>> then it's my problem to figure out why configure isn't adding -lc.
>>
>> Ray
Nicolas> Doesn't work, unfortunately...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Nicolas> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))'
Nicolas> ; Loading #p"/usr/local/src/matlisp/start.lisp".
Nicolas> Converted SETLOGICALROOT.
Nicolas> Converted GETLOGICALROOT.
Nicolas> Converted DEFLOGICALPATH.
Nicolas> ;; Loading #p"/usr/local/src/matlisp/system.dcl".
Nicolas> ;; Loading #p"/usr/local/src/matlisp/config.lisp".
Nicolas> Error in function SYSTEM::LOAD-OBJECT-FILE:
Nicolas> Can't open object "/tmp/29938AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat"
Are you sure that the new lazy-loader is being loaded? Your output
doesn't really say.
Nicolas> The problem could be in defsystem, maybe? I've seen that CMUCL has
I don't think it's defsystem.
Nicolas> some version now integrated, matlisp has another one, and there is the
Nicolas> one at CLOCC, ... How is the connection between those?
CMUCL 18d is removing the very ancient defsystem that it uses.
The one in matlisp is a copy of the defsystem 3.x in CLOCC. It's
probably a little behind, but should still work.
If you're sure that the right lazy-loader is being used, then, I'll
have to try this on my Linux box at home. It's not debian, but that
shouldn't matter when building matlisp.
Ray
|
|
From: Nicolas N. <Nic...@iw...> - 2002-03-26 15:23:42
|
Raymond Toy <to...@rt...> writes: > > Ok, before -lm, can you add -lc? Like so: > > " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm")))) > > Then try rebuilding. I hope that takes care of the problem. If so, > then it's my problem to figure out why configure isn't adding -lc. > > Ray Doesn't work, unfortunately... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))' ; Loading #p"/usr/local/src/matlisp/start.lisp". Converted SETLOGICALROOT. Converted GETLOGICALROOT. Converted DEFLOGICALPATH. ;; Loading #p"/usr/local/src/matlisp/system.dcl". ;; Loading #p"/usr/local/src/matlisp/config.lisp". Error in function SYSTEM::LOAD-OBJECT-FILE: Can't open object "/tmp/29938AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat" Restarts: 0: [CONTINUE] Return NIL from load of "start.lisp". 1: [ABORT ] Skip remaining initializations. Debug (type H for help) (SYSTEM::LOAD-OBJECT-FILE "/tmp/29938AG0") Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/foreign.lisp. 0] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< The problem could be in defsystem, maybe? I've seen that CMUCL has some version now integrated, matlisp has another one, and there is the one at CLOCC, ... How is the connection between those? Nicolas. |
|
From: Raymond T. <to...@rt...> - 2002-03-26 14:47:39
|
>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
Nicolas> Raymond Toy <to...@rt...> writes:
>> Don't think rebuilding will help, but you never know.
>>
>> Can you tell me what load-blas-&-lapack-libraries in lazy-loader.lisp
>> looks like? We obviously aren't able to find the fstat function, so
>> I'm thinking we aren't linking with libc for some reason.
>>
>> Ray
>>
Nicolas> Sorry, I had overlooked the second part of your first reponse at the
Nicolas> beginning. The function reads:
Nicolas> (defun load-blas-&-lapack-libraries ()
Nicolas> (ext::load-foreign "matlisp:lib;lazy-loader.o"
Nicolas> :libraries (tokenize-ld-args
Nicolas> (concatenate 'string
Nicolas> ""
Nicolas> " "
Nicolas> ""
Nicolas> " "
Nicolas> "-L"
Nicolas> (namestring
Nicolas> (translate-logical-pathname "matlisp:lib"))
Nicolas> " "
Nicolas> "-R"
Nicolas> (namestring
Nicolas> (translate-logical-pathname "matlisp:lib"))
Nicolas> " "
Nicolas> "-lmatlisp"
Nicolas> " "
Nicolas> " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm"))))
Ok, before -lm, can you add -lc? Like so:
" -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lc -lm"))))
Then try rebuilding. I hope that takes care of the problem. If so,
then it's my problem to figure out why configure isn't adding -lc.
Ray
|
|
From: Nicolas N. <Nic...@iw...> - 2002-03-26 14:23:31
|
Raymond Toy <to...@rt...> writes: > Don't think rebuilding will help, but you never know. > > Can you tell me what load-blas-&-lapack-libraries in lazy-loader.lisp > looks like? We obviously aren't able to find the fstat function, so > I'm thinking we aren't linking with libc for some reason. > > Ray > Sorry, I had overlooked the second part of your first reponse at the beginning. The function reads: (defun load-blas-&-lapack-libraries () (ext::load-foreign "matlisp:lib;lazy-loader.o" :libraries (tokenize-ld-args (concatenate 'string "" " " "" " " "-L" (namestring (translate-logical-pathname "matlisp:lib")) " " "-R" (namestring (translate-logical-pathname "matlisp:lib")) " " "-lmatlisp" " " " -L/usr/lib/gcc-lib/i386-linux/2.95.4 -lg2c -lm")))) Bye, Nicolas. -- Dr. Nicolas Neuss Email: Nic...@IW... WWW: <http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss> |
|
From: Raymond T. <to...@rt...> - 2002-03-26 14:16:37
|
>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
Nicolas> Raymond Toy <to...@rt...> writes:
>> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
>>
Nicolas> Hello, Matlisp-Users.
Nicolas> I am trying to compile matlisp (CVS version) with CMUCL (3.0.9).
Nicolas> After having compiled the Fortran files without problems the Lisp part
Nicolas> gives the following error:
>>
>> What platform is this? NetBSD?
>>
>> While I haven't built matlisp in a while, I didn't have any problems.
>>
>> Ray
Nicolas> Oh, I forgot... No, it's Debian.
Nicolas> Nicolas.
Nicolas> P.S.: Maybe I have done something wrong with the installation of my
Nicolas> CMUCL, even if the error looks otherwise. I've just learned from
Nicolas> Christophe Rhodes about dpkg-buildpackage and try now to build CMUCL
Nicolas> from the sources. Hopefully, it compiles also matlisp thereafter...
Don't think rebuilding will help, but you never know.
Can you tell me what load-blas-&-lapack-libraries in lazy-loader.lisp
looks like? We obviously aren't able to find the fstat function, so
I'm thinking we aren't linking with libc for some reason.
Ray
|
|
From: Nicolas N. <Nic...@iw...> - 2002-03-26 14:04:07
|
Raymond Toy <to...@rt...> writes: > >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes: > > Nicolas> Hello, Matlisp-Users. > Nicolas> I am trying to compile matlisp (CVS version) with CMUCL (3.0.9). > Nicolas> After having compiled the Fortran files without problems the Lisp part > Nicolas> gives the following error: > > What platform is this? NetBSD? > > While I haven't built matlisp in a while, I didn't have any problems. > > Ray Oh, I forgot... No, it's Debian. Nicolas. P.S.: Maybe I have done something wrong with the installation of my CMUCL, even if the error looks otherwise. I've just learned from Christophe Rhodes about dpkg-buildpackage and try now to build CMUCL from the sources. Hopefully, it compiles also matlisp thereafter... |
|
From: Raymond T. <to...@rt...> - 2002-03-26 13:43:36
|
>>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
Nicolas> Hello, Matlisp-Users.
Nicolas> I am trying to compile matlisp (CVS version) with CMUCL (3.0.9).
Nicolas> After having compiled the Fortran files without problems the Lisp part
Nicolas> gives the following error:
What platform is this? NetBSD?
While I haven't built matlisp in a while, I didn't have any problems.
Ray
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Nicolas> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))'
Nicolas> ; Loading #p"/usr/local/src/matlisp/start.lisp".
Nicolas> Converted SETLOGICALROOT.
Nicolas> Converted GETLOGICALROOT.
Nicolas> Converted DEFLOGICALPATH.
Nicolas> ;; Loading #p"/usr/local/src/matlisp/system.dcl".
Nicolas> ;;; Loading #p"/usr/local/src/matlisp/defsystem.lisp".
Nicolas> Converted CANONICALIZE-MODULE-NAME.
Nicolas> Converted DEFMODULE.
Nicolas> Converted MODULE-FILES.
Nicolas> Converted PROVIDE.
Nicolas> Converted REQUIRE.
Nicolas> Warning: These variables are undefined:
Nicolas> *LIBRARY* *MODULE-FILES*
Nicolas> Warning: Old-style IN-PACKAGE.
Nicolas> Converted |(PCL::FAST-METHOD PRINT-OBJECT (COMPONENT T))|.
Nicolas> Converted |(PCL::FAST-METHOD PRINT-OBJECT (LANGUAGE T))|.
Nicolas> ;; Loading #p"/usr/local/src/matlisp/config.lisp".
Nicolas> ;; Loading #p"/usr/local/src/matlisp/packages.x86f".
Nicolas> Python version 1.0, VM version Intel x86 on 26 MAR 02 02:01:36 pm.
Nicolas> Compiling: /usr/local/src/matlisp/lib/lazy-loader.lisp 26 MAR 02 01:59:08 pm
Nicolas> ;;; Running /usr/bin/ld...
Nicolas> Error in function SYSTEM::LOAD-OBJECT-FILE:
Nicolas> Can't open object "/tmp/25749AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat"
So when loading the Fortran libraries, we can't find fstat. Where is
fstat? libc? Can you tell me what load-blas-&-lapack-libraries in
lazy-loader.lisp looks like?
Ray
|
|
From: Nicolas N. <Nic...@iw...> - 2002-03-26 13:26:51
|
Hello, Matlisp-Users. I am trying to compile matlisp (CVS version) with CMUCL (3.0.9). After having compiled the Fortran files without problems the Lisp part gives the following error: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /usr/bin/lisp -noinit -eval '(progn (load "start.lisp"))' ; Loading #p"/usr/local/src/matlisp/start.lisp". Converted SETLOGICALROOT. Converted GETLOGICALROOT. Converted DEFLOGICALPATH. ;; Loading #p"/usr/local/src/matlisp/system.dcl". ;;; Loading #p"/usr/local/src/matlisp/defsystem.lisp". Converted CANONICALIZE-MODULE-NAME. Converted DEFMODULE. Converted MODULE-FILES. Converted PROVIDE. Converted REQUIRE. Warning: These variables are undefined: *LIBRARY* *MODULE-FILES* Warning: Old-style IN-PACKAGE. Converted |(PCL::FAST-METHOD PRINT-OBJECT (COMPONENT T))|. Converted |(PCL::FAST-METHOD PRINT-OBJECT (LANGUAGE T))|. ;; Loading #p"/usr/local/src/matlisp/config.lisp". ;; Loading #p"/usr/local/src/matlisp/packages.x86f". Python version 1.0, VM version Intel x86 on 26 MAR 02 02:01:36 pm. Compiling: /usr/local/src/matlisp/lib/lazy-loader.lisp 26 MAR 02 01:59:08 pm ;;; Running /usr/bin/ld... Error in function SYSTEM::LOAD-OBJECT-FILE: Can't open object "/tmp/25749AG0": "/usr/local/src/matlisp/lib/libmatlisp.so: undefined symbol: fstat" Restarts: 0: [CONTINUE] Return NIL from load of "start.lisp". 1: [ABORT ] Skip remaining initializations. Debug (type H for help) (SYSTEM::LOAD-OBJECT-FILE "/tmp/25749AG0") Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/foreign.lisp. 0] <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Can someone help me? Thanks, Nicolas. |
|
From: Isaac S. K. <isa...@ha...> - 2002-03-11 01:30:40
|
At 13:37 -0800 3/10/02, Tunc Simsek wrote: >Hi Zak; > >I'm glad you seem confident in Matlisp. I don't think I've heard >of anyone ever using it on Mac OS. You will certainly need >a fortran 77 compiler. However, you will also need a lisp compiler >and matlisp has only been known to work with "Allegro CL" or "CMU CL". >I don't think CMU CL has a Mac OS port but I believe Allegro does. Well here is a bit of news for you. There was little point in programming on Liso for years until Macintosh OS X came out which is built on top of BSD Unix and subsequently Allegro ported its unix implementation to OS X as well. So, all I have to do is find a f77 compiler and a quick scan with google suggests that there already exist. This is particularly great because Matlab abandoned the Mac last year. -Zak > >Assuming you have Allegro CL, you will need to get hold of the >blas/lapack libraries. the safest way to do this is to get hold >of a fortran 77 compiler and "make" the libraries using the makefiles >in the matlisp distribution. > >Good luck, > Tunc > >"Isaac S. Kohane" wrote: >> >> Your package looks to be just the ticket but when I try to compile it >> using your instructions, it complains about the lack of a F77 >> compiler. This is on Mac OS X. Am I right that I need to get an F77 >> compiler? >> >> Thanks >> >> -Zak >> -- >> >> ---------------------------------------------------------- >> Isaac S. Kohane, MD, PhD >> Director, Children's Hospital Informatics Program >> Associate Professor of Pediatrics, Harvard Medical School >> 300 Longwood Avenue, Room 511.1 >> Children's Hospital >> Boston, MA 02115 >> >> Fax: 617-355-7588 >> Office: 617-355-7821 >> isa...@ha... >> http://www.chip.org/chip/people/isaackohane.html >> >> CHIP Coordinator: Marie Boyle (617-355-7333) |
|
From: Tunc S. <si...@ee...> - 2002-03-10 21:38:01
|
Hi Zak; I'm glad you seem confident in Matlisp. I don't think I've heard of anyone ever using it on Mac OS. You will certainly need a fortran 77 compiler. However, you will also need a lisp compiler and matlisp has only been known to work with "Allegro CL" or "CMU CL". I don't think CMU CL has a Mac OS port but I believe Allegro does. Assuming you have Allegro CL, you will need to get hold of the blas/lapack libraries. the safest way to do this is to get hold of a fortran 77 compiler and "make" the libraries using the makefiles in the matlisp distribution. Good luck, Tunc "Isaac S. Kohane" wrote: > > Your package looks to be just the ticket but when I try to compile it > using your instructions, it complains about the lack of a F77 > compiler. This is on Mac OS X. Am I right that I need to get an F77 > compiler? > > Thanks > > -Zak > -- > > ---------------------------------------------------------- > Isaac S. Kohane, MD, PhD > Director, Children's Hospital Informatics Program > Associate Professor of Pediatrics, Harvard Medical School > 300 Longwood Avenue, Room 511.1 > Children's Hospital > Boston, MA 02115 > > Fax: 617-355-7588 > Office: 617-355-7821 > isa...@ha... > http://www.chip.org/chip/people/isaackohane.html > > CHIP Coordinator: Marie Boyle (617-355-7333) |
|
From: Jefferson P. <jp...@cs...> - 2002-02-02 01:26:37
|
Tunc, Thanks for the help and the code. I'll look at it and see what I can do and let you all know. I may post with some questions on optimization, since I haven't really tried to optimize my code much before. Re: "covariance normalization": I don't know if there's an official name for it, but basically it's an operation on a square matrix A to produce a new matrix B, where B(x,y) = A(x,y)/sqrt(A(x,x)*A(y,y)). If A was a covariance matrix, B will be the corresponding correlation matrix, with 1's on the diagonal and all the other values in the range [-1,1]. (i.e. B(x,y) is the correlation between variable x and variable y.) I have implemented it using MATLISP, but it's not optimized at all... I see how to optimize it now, I think, so hopefully it should speed up a lot. Thanks! Jeff On 2/1/02 4:55 PM, "Tunc Simsek" <si...@ee...> wrote: > Hi Ray, Jefferson; > > I've played with Allegro 6.0 as follows (I asked it to explain > the compilation of m.*!): > > (defmethod m.*! ((a real-matrix) (b real-matrix)) > (let* ((nxm (number-of-elements b))) > (declare (type fixnum nxm) > (optimize (speed 3) (safety 0))) > > (dotimes (k nxm b) > (declare (type fixnum k)) > (let ((a-val (matrix-ref a k)) > (b-val (matrix-ref b k))) > (declare (type real-matrix-element-type a-val b-val) > (:explain :calls :types :boxing)) > (setf (matrix-ref b k) (* a-val b-val)))))) > > > and here is what I get: > > ;;; Compiling file C:\usr\gigascale\shift\src\matlisp\src\mtimes.lisp > ;Examining a (possibly unboxed) call to *_2OP with arguments: > ; symeval A-VAL type (DOUBLE-FLOAT * *) > ; symeval B-VAL type (DOUBLE-FLOAT * *) > ; which returns a value of type (DOUBLE-FLOAT * *) > ;Generating a DOUBLE-FLOAT box > ;Examining a call to FUNCALL with arguments: > ; call to CDR type KNOWN-FUNCTION > ; symeval G16043 type (DOUBLE-FLOAT * *) > ; symeval G16044 type #<STANDARD-CLASS REAL-MATRIX> > ; symeval G16045 type (INTEGER -536870912 536870911) > ; which returns a value of type T > ;Examining a call to CDR with arguments: > ; constant ((EVAL-WHEN-LOADED) SETF-METHOD-LOCATIVE (QUOTE MATRIX-REF) > ...) type TRUE-LIST > ; which returns a value of type KNOWN-FUNCTION > ;;; Writing fasl file C:\usr\gigascale\shift\src\matlisp\bin\mtimes.fasl > > so my conclusion is that the MATRIX-REF used to access the variables is > waaaaay more expensive than AREF. Insomuch that it has the overhead of > a generic function dispatch and also a boxing of the results. > This will explain the performance figures given by Jefferson, which > I was able to duplicate (roughly on the same order) on my Windows 2000 > pentium something machine. > > Now I quickly tried the following change and got a performance increase > of exactly 10 fold (ie. from 1.7 seconds per call to .13 seconds) > and the compiler is still saying that there is boxing. I don't know > the Allegro flags very well, but it seems that the matlisp sources > can be modified so that this performance problem disappears > and there is no need to do m.*! in fortran. (disclaimer: I DIDN'T > TEST IF THE FOLLOWING MODIFICATIONS GIVE CORRECT COMPUTATIONAL > RESULTS OR ARE CONSISTENT WITH MATLISP CODING STANDARDS) > > (defmethod m.*! ((a real-matrix) (b real-matrix)) > (let* ((nxm (number-of-elements b)) > (aa (store a)) > (bb (store b))) > (declare (type fixnum nxm) > (type (real-matrix-store-type (*)) aa bb) > (optimize (speed 3) (safety 0))) > > (dotimes (k nxm b) > (declare (type fixnum k)) > (let ((a-val (aref aa k)) > (b-val (aref bb k))) > (declare (type real-matrix-element-type a-val b-val) > (:explain :calls :types :boxing)) > (setf (aref bb k) (* a-val b-val)))))) > > Good luck and keep this list posted on your results, > I think a tested version of these changes should be checked in > to the repository. > > -- Tunc > > ps. I don't know your terminology on covariance normalization. > But it seems to me that it should be possible using matlisp functions. > > Jefferson Provost wrote: >> >> On 2/1/02 11:34 AM, "Raymond Toy" <to...@rt...> wrote: >> >>>>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes: >>> >>> You are right. A peek at the generated code on Solaris seems to show >>> that we are calling out to generic functions way too often and could >>> be vastly optimized. >>> >>> I know with CMUCL, a Lisp version of m+ was almost as fast (< 5% >>> slower?) than Fortran, so m.* should be as fast, even in Lisp. >>> >>> I'll look in to it soon. >> >> Thanks, though I'd be happy to just write the thing in fortran myself, but >> I'm totally unfamiliar with the foreign function interfaces for Allegro and >> CMUCL. >> >> Actually, I have another routine that I use a lot which I was hoping might >> be in MATLISP, but which I couldn't find. I've had to write it myself (in >> lisp) and it's slower than I'd like it to be. It's basically the >> "covariance normalization" i.e. the normalization that turns a covariance >> matrix into a correlation coefficients matrix. >> >> J. >> >> _______________________________________________ >> Matlisp-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matlisp-users > > _______________________________________________ > Matlisp-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlisp-users > |
|
From: Tunc S. <si...@ee...> - 2002-02-01 22:56:01
|
Hi Ray, Jefferson;
I've played with Allegro 6.0 as follows (I asked it to explain
the compilation of m.*!):
(defmethod m.*! ((a real-matrix) (b real-matrix))
(let* ((nxm (number-of-elements b)))
(declare (type fixnum nxm)
(optimize (speed 3) (safety 0)))
(dotimes (k nxm b)
(declare (type fixnum k))
(let ((a-val (matrix-ref a k))
(b-val (matrix-ref b k)))
(declare (type real-matrix-element-type a-val b-val)
(:explain :calls :types :boxing))
(setf (matrix-ref b k) (* a-val b-val))))))
and here is what I get:
;;; Compiling file C:\usr\gigascale\shift\src\matlisp\src\mtimes.lisp
;Examining a (possibly unboxed) call to *_2OP with arguments:
; symeval A-VAL type (DOUBLE-FLOAT * *)
; symeval B-VAL type (DOUBLE-FLOAT * *)
; which returns a value of type (DOUBLE-FLOAT * *)
;Generating a DOUBLE-FLOAT box
;Examining a call to FUNCALL with arguments:
; call to CDR type KNOWN-FUNCTION
; symeval G16043 type (DOUBLE-FLOAT * *)
; symeval G16044 type #<STANDARD-CLASS REAL-MATRIX>
; symeval G16045 type (INTEGER -536870912 536870911)
; which returns a value of type T
;Examining a call to CDR with arguments:
; constant ((EVAL-WHEN-LOADED) SETF-METHOD-LOCATIVE (QUOTE MATRIX-REF)
...) type TRUE-LIST
; which returns a value of type KNOWN-FUNCTION
;;; Writing fasl file C:\usr\gigascale\shift\src\matlisp\bin\mtimes.fasl
so my conclusion is that the MATRIX-REF used to access the variables is
waaaaay more expensive than AREF. Insomuch that it has the overhead of
a generic function dispatch and also a boxing of the results.
This will explain the performance figures given by Jefferson, which
I was able to duplicate (roughly on the same order) on my Windows 2000
pentium something machine.
Now I quickly tried the following change and got a performance increase
of exactly 10 fold (ie. from 1.7 seconds per call to .13 seconds)
and the compiler is still saying that there is boxing. I don't know
the Allegro flags very well, but it seems that the matlisp sources
can be modified so that this performance problem disappears
and there is no need to do m.*! in fortran. (disclaimer: I DIDN'T
TEST IF THE FOLLOWING MODIFICATIONS GIVE CORRECT COMPUTATIONAL
RESULTS OR ARE CONSISTENT WITH MATLISP CODING STANDARDS)
(defmethod m.*! ((a real-matrix) (b real-matrix))
(let* ((nxm (number-of-elements b))
(aa (store a))
(bb (store b)))
(declare (type fixnum nxm)
(type (real-matrix-store-type (*)) aa bb)
(optimize (speed 3) (safety 0)))
(dotimes (k nxm b)
(declare (type fixnum k))
(let ((a-val (aref aa k))
(b-val (aref bb k)))
(declare (type real-matrix-element-type a-val b-val)
(:explain :calls :types :boxing))
(setf (aref bb k) (* a-val b-val))))))
Good luck and keep this list posted on your results,
I think a tested version of these changes should be checked in
to the repository.
-- Tunc
ps. I don't know your terminology on covariance normalization.
But it seems to me that it should be possible using matlisp functions.
Jefferson Provost wrote:
>
> On 2/1/02 11:34 AM, "Raymond Toy" <to...@rt...> wrote:
>
> >>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:
> >
> > You are right. A peek at the generated code on Solaris seems to show
> > that we are calling out to generic functions way too often and could
> > be vastly optimized.
> >
> > I know with CMUCL, a Lisp version of m+ was almost as fast (< 5%
> > slower?) than Fortran, so m.* should be as fast, even in Lisp.
> >
> > I'll look in to it soon.
>
> Thanks, though I'd be happy to just write the thing in fortran myself, but
> I'm totally unfamiliar with the foreign function interfaces for Allegro and
> CMUCL.
>
> Actually, I have another routine that I use a lot which I was hoping might
> be in MATLISP, but which I couldn't find. I've had to write it myself (in
> lisp) and it's slower than I'd like it to be. It's basically the
> "covariance normalization" i.e. the normalization that turns a covariance
> matrix into a correlation coefficients matrix.
>
> J.
>
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
|
|
From: Jefferson P. <jp...@cs...> - 2002-02-01 18:29:24
|
On 2/1/02 11:34 AM, "Raymond Toy" <to...@rt...> wrote: >>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes: > > You are right. A peek at the generated code on Solaris seems to show > that we are calling out to generic functions way too often and could > be vastly optimized. > > I know with CMUCL, a Lisp version of m+ was almost as fast (< 5% > slower?) than Fortran, so m.* should be as fast, even in Lisp. > > I'll look in to it soon. Thanks, though I'd be happy to just write the thing in fortran myself, but I'm totally unfamiliar with the foreign function interfaces for Allegro and CMUCL. Actually, I have another routine that I use a lot which I was hoping might be in MATLISP, but which I couldn't find. I've had to write it myself (in lisp) and it's slower than I'd like it to be. It's basically the "covariance normalization" i.e. the normalization that turns a covariance matrix into a correlation coefficients matrix. J. |
|
From: Raymond T. <to...@rt...> - 2002-02-01 17:34:18
|
>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:
Jefferson> On 2/1/02 7:28 AM, "Raymond Toy" <to...@rt...> wrote:
Jefferson> D = 1x500 real matrix
>>
>> You do realize that a*b is O(500^3), a+b is O(500^2) and c*d is also
>> O(500^2). So it's not surprising that a*b takes 157 times longer than
>> a+b and 88 times longer than c*d.
Jefferson> Yes, I realize that. But I wasn't doing a*b, I was doing a.*b, which is
Jefferson> O(500x500), same as a+b, and c*d.
Sorry, I missed the dot!
You are right. A peek at the generated code on Solaris seems to show
that we are calling out to generic functions way too often and could
be vastly optimized.
I know with CMUCL, a Lisp version of m+ was almost as fast (< 5%
slower?) than Fortran, so m.* should be as fast, even in Lisp.
I'll look in to it soon.
Ray
|
|
From: Jefferson P. <jp...@cs...> - 2002-02-01 17:25:07
|
On 2/1/02 7:28 AM, "Raymond Toy" <to...@rt...> wrote: > Jefferson> D = 1x500 real matrix > > You do realize that a*b is O(500^3), a+b is O(500^2) and c*d is also > O(500^2). So it's not surprising that a*b takes 157 times longer than > a+b and 88 times longer than c*d. Yes, I realize that. But I wasn't doing a*b, I was doing a.*b, which is O(500x500), same as a+b, and c*d. Looking in mtimes.lisp, m* is implemented by calling GEMM, which is implemented in fortran, but m.* and m.*! are written in lisp. It doesn't surprise me that the routines written in LISP are much slower. I was just surprised to find that function written in lisp. I have to problem writing in myself, but I wanted to make sure I wasn't missing something first. J. |
|
From: Raymond T. <to...@rt...> - 2002-02-01 13:28:25
|
>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:
Jefferson> On 1/31/02 5:40 PM, "Tunc Simsek" <si...@ee...> wrote:
>> what do you mean by native. both allegro and cmucl produce native code.
>> looking at mtimes.lisp; it looks like all the declarations are in place
>> for m.*! so the only reason that it may be slow is if the optimization
>> flags were not set during compilation. I personally never checked that
>> they are. It is worth checking this.
Jefferson> Sorry, I misspoke: by native I meant to say implemented in fortran.
Jefferson> Here are the average times of a few operations.
Jefferson> operation | msecs (mean of 100 runs)
Jefferson> -----------+---------
Jefferson> (m.*! a b) | 1351.6
Jefferson> (m.+! a b) | 8.6
Jefferson> (m* c d) | 15.2
Jefferson> A,B = 500x500 real-matrices
Jefferson> C = 500x1 real matrix
Jefferson> D = 1x500 real matrix
You do realize that a*b is O(500^3), a+b is O(500^2) and c*d is also
O(500^2). So it's not surprising that a*b takes 157 times longer than
a+b and 88 times longer than c*d.
To speed things up, you may want to get a copy of ATLAS and build
matlisp with that if you haven't already.
Ray
|
2 messages has been excluded from this view by a project administrator.
