matlisp-users — General discussion list.

[Matlisp-users] Re: Problem with function geev

[Paul L. I. <aea...@gm...>]

>
> Ah, thanks for digging into this.  A little googling finds the LAPACK
> FAQ (http://www.netlib.org/lapack/faq.html) which indicates that dlamch
> (and its dependent routines dlamc[1-5]) should be compiled without
> optimization?  Can you compile dlamch.f by hand without optimization and
> see if that makes a difference for you?
>
> I'd really appreciate if you could, since I don't seem to have this
> problem on my linux boxes.
>

I recompiled with an unoptimized dlamch and this solved the problem as
well.  So now we have found multiple ways to solve the problem, and
this should do well for anyone wanting to use geev.  But in the
following I argue that we still haven't found the real issue.

I have to admit I'm afraid that this still treats the effect just as
the other modifications do.  I have linked the optimized/faulty
dlamch.o to a fortran program which calls on dgeev with non-tivial
arguments.  There was no problem with dlamch then (defeating my hope
to isolate the bug from the lisp fortran interaction).  Now, since the
same object file has an error depending on who calls on its
functions,I have to think the problem is in the caller not the object
file.

Even if the error were in the object file, I can't imagine
optimization could cause the error we're seeing.  I could understand
optimization causing a miscalculation of some machine parameters.  But
we are seeing the logical (C .EQ A) evaluating to false (or being
completely skipped), when it is in fact true.  If you tell me some
optimization would do this, I could believe you, but I don't think I
could ever trust optimization again.

Paul

[Matlisp-users] Re: Problem with function geev

[Thibault L. <tl...@di...>]

On Wed, 2005-08-10 at 09:32 -0400, Raymond Toy wrote:
> Paul Ledbetter III wrote:
> > I would like to know if the patch at the bottom of this email solves
> > the geev problem for the other people who have reported it.  It solves
> > mine.
> [snip]
> > The logical effect of this patch is to cause the LAPACK routines to
> > assume the base of the machine is at least binary.
> > 
> 
> Ah, thanks for digging into this.  A little googling finds the LAPACK 
> FAQ (http://www.netlib.org/lapack/faq.html) which indicates that dlamch 
> (and its dependent routines dlamc[1-5]) should be compiled without 
> optimization?  Can you compile dlamch.f by hand without optimization and 
> see if that makes a difference for you?
> 
> I'd really appreciate if you could, since I don't seem to have this 
> problem on my linux boxes.
> 
> Thanks!
> 
> Ray

Bingo ! It works.

After "make" I did

g77 -g -o LAPACK/SRC/dlamch.o -c LAPACK/SRC/dlamch.f

then make again and it worked.

Thibault

[Matlisp-users] Re: Problem with function geev

[Raymond T. <rt...@ea...>]

Paul Ledbetter III wrote:
> I would like to know if the patch at the bottom of this email solves
> the geev problem for the other people who have reported it.  It solves
> mine.
[snip]
> The logical effect of this patch is to cause the LAPACK routines to
> assume the base of the machine is at least binary.
> 

Ah, thanks for digging into this.  A little googling finds the LAPACK 
FAQ (http://www.netlib.org/lapack/faq.html) which indicates that dlamch 
(and its dependent routines dlamc[1-5]) should be compiled without 
optimization?  Can you compile dlamch.f by hand without optimization and 
see if that makes a difference for you?

I'd really appreciate if you could, since I don't seem to have this 
problem on my linux boxes.

Thanks!

Ray

Re: [Matlisp-users] Re: Problem with function geev

[Paul L. I. <aea...@gm...>]

My email probably seemed somewhat strange coming after yours, since we
came to similar conclusions.  My first email was delayed by more than
a day(for moderation purposes?) and you verified what I was asking for
before it could arrive :)

As I think we have both found, just about any change in the code
before that loop causes dlamch to behave correctly.  I chose to set
B=3D2 because it's a trivial improvement to the LAPACK code(it
eliminates an unnecessary loop iteration).

I have witnessed the error on two computers, one with a celeron cpu,
and the other with a pentium III.  In both cases I am using cmucl-19b
on FreeBSD 5.4.  My f77 on both is 3.4.2.

This bug is annoying.  I hope this helps.

Paul

[Matlisp-users] Re: Problem with function geev

[Thibault L. <tl...@di...>]

On Mon, 2005-08-08 at 22:15 -0500, Paul Ledbetter III wrote:
> I would like to know if the patch at the bottom of this email solves
> the geev problem for the other people who have reported it.  It solves
> mine.
> 
> I have been having the same issue with geev.  Calling it causes cmucl
> to go into an infinite loop.  In slime I can interrupt the program,
> and then call geev again.  The second time no infinite loop occurs,
> but the results are corrupted (i.e. The resulting matrices are
> populated with silent-NaNs).
> 
> I have tracked the source of these problems down to a heisenbug in the
> subroutines which determine parameters of the machine.  Unfortunately,
> this patch could not possibly affect the real cause of the problem,
> but if it works for other people besides me, it may help lead to the
> real problem.
> 
> The logical effect of this patch is to cause the LAPACK routines to
> assume the base of the machine is at least binary.
> 
> Index: dlamch.f
> ===================================================================
> RCS file: /cvsroot/matlisp/matlisp/LAPACK/SRC/dlamch.f,v
> retrieving revision 1.1
> diff -u -w -r1.1 dlamch.f
> --- dlamch.f	15 Apr 2000 00:24:53 -0000	1.1
> +++ dlamch.f	9 Aug 2005 02:47:52 -0000
> @@ -231,7 +231,7 @@
>  *
>  *           fl( a + b ) .gt. a.
>  *
> -         B = 1
> +         B = 2
>           C = DLAMC3( A, B )
>  *
>  *+       WHILE( C.EQ.A )LOOP
> 

It works for me but this one works too :-/

--- ../matlisp-2_0beta-2003-10-14/LAPACK/SRC/dlamch.f   2000-04-15
01:24:53.000000000 +0100
+++ LAPACK/SRC/dlamch.f 2005-08-10 12:13:27.167199885 +0100
@@ -234,6 +234,7 @@
          B = 1
          C = DLAMC3( A, B )
 *
+         PRINT *, ''
 *+       WHILE( C.EQ.A )LOOP
    20    CONTINUE
          IF( C.EQ.A ) THEN

The bug is more likely to be in gcc/g77/glibc or in the way 
the libraries are called from lisp. Here are the versions I use:

wok$ gcc --version
gcc (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wok$ g77 --version
GNU Fortran (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)
Copyright (C) 2004 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
or type the command `info -f g77 Copying'.

wok$ rpm -q glibc
glibc-2.3.3-74


Thibault

[Matlisp-users] Re: Problem with function geev

[Paul L. I. <aea...@gm...>]

I would like to know if the patch at the bottom of this email solves
the geev problem for the other people who have reported it.  It solves
mine.

I have been having the same issue with geev.  Calling it causes cmucl
to go into an infinite loop.  In slime I can interrupt the program,
and then call geev again.  The second time no infinite loop occurs,
but the results are corrupted (i.e. The resulting matrices are
populated with silent-NaNs).

I have tracked the source of these problems down to a heisenbug in the
subroutines which determine parameters of the machine.  Unfortunately,
this patch could not possibly affect the real cause of the problem,
but if it works for other people besides me, it may help lead to the
real problem.

The logical effect of this patch is to cause the LAPACK routines to
assume the base of the machine is at least binary.

Index: dlamch.f
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/matlisp/matlisp/LAPACK/SRC/dlamch.f,v
retrieving revision 1.1
diff -u -w -r1.1 dlamch.f
--- dlamch.f=0915 Apr 2000 00:24:53 -0000=091.1
+++ dlamch.f=099 Aug 2005 02:47:52 -0000
@@ -231,7 +231,7 @@
 *
 *           fl( a + b ) .gt. a.
 *
-         B =3D 1
+         B =3D 2
          C =3D DLAMC3( A, B )
 *
 *+       WHILE( C.EQ.A )LOOP

Re: [Matlisp-users] Problem with function geev

[Thibault L. <tl...@di...>]

On Wed, 2005-07-27 at 16:29 -0400, Raymond Toy wrote: 
> >>>>> "Thibault" == Thibault Langlois <tl...@di...> writes:
> 
>     Thibault> #<The MATLISP-USER package, 1/9 internal, 0/2 external>
>     Thibault> * (setq m (make-real-matrix '((1 1 2) (2 2 4) (3 3 6))))
> 
>     Thibault> Warning:  Declaring M special.
> 
>     Thibault> #<REAL-MATRIX  3 x 3
>     Thibault>     1.0000      1.0000      2.0000     
>     Thibault>     2.0000      2.0000      4.0000     
>     Thibault>     3.0000      3.0000      6.0000     >
>     Thibault> * (geev m)
> 
> Just tried this (finally) using cvs matlisp and cmucl 2005-07.
> (geev m) returns
> 
> #<REAL-MATRIX  3 x 1
>     0.0000     
>     9.0000     
>    -5.24537E-16 >
> 
> which is pretty close to what matlab returns.
> 
> I'll have to look at the code some more.  Perhaps it's doing something
> wrong.  (There used to be a memory corruption error in some eigenvalue
> routine, but that's been fixed.)
> 
> Ray
> 

I have been trying to find where this bug occurs. First surprise, it
seems to be in fortran code, somewhere in the DLAMCH routine. I tried to
put some "PRINT *, 'some string'" in the code in order to localize the
point. Doing so I ended with a version of the file that make matlisp
work correctly ! 

Then I went to #lisp to see if someone involved was online. Consulting
the log at http://meme.b9.com I noticed that someone (aeacides) was also
looking at the same file and at the same point in the file ...

So, if I add the prints arround the loop, it works:

         PRINT *, 'before loop 2'
*+       WHILE( C.EQ.A )LOOP
   20    CONTINUE
         IF( C.EQ.A ) THEN
            B = 2*B
            C = DLAMC3( A, B )
            GO TO 20
         END IF
*+       END WHILE
         PRINT *, 'after loop 2'

if I comment the first and last lines it does not work. 

It looks like a nasty memory corruption bug. 

Thibault

PS: the problem is not related to the geev function and should affect
other matlisp functions.

Re: [Matlisp-users] Problem with function geev

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

>>>>> "Thibault" == Thibault Langlois <tl...@di...> writes:

    Thibault> #<The MATLISP-USER package, 1/9 internal, 0/2 external>
    Thibault> * (setq m (make-real-matrix '((1 1 2) (2 2 4) (3 3 6))))

    Thibault> Warning:  Declaring M special.

    Thibault> #<REAL-MATRIX  3 x 3
    Thibault>     1.0000      1.0000      2.0000     
    Thibault>     2.0000      2.0000      4.0000     
    Thibault>     3.0000      3.0000      6.0000     >
    Thibault> * (geev m)

Just tried this (finally) using cvs matlisp and cmucl 2005-07.
(geev m) returns

#<REAL-MATRIX  3 x 1
    0.0000     
    9.0000     
   -5.24537E-16 >

which is pretty close to what matlab returns.

I'll have to look at the code some more.  Perhaps it's doing something
wrong.  (There used to be a memory corruption error in some eigenvalue
routine, but that's been fixed.)

Ray

Re: Re: [Matlisp-users] Problem with function geev

[Thibault L. <tl...@di...>]

On Wed, 2005-07-27 at 08:48 -0400, Raymond Toy wrote:
> >>>>> "Thibault" == Thibault Langlois <tl...@di...> writes:
> 
>     Thibault> Ray, I saw your memo on #lisp. I downloaded the csv version and
>     Thibault> installed it without problem. But I continue to get the same behavior :-
>     Thibault> ( : when I use (geev ..) it starts computing and never ends. 
>     Thibault> I am still using an "old" version of cmucl (19apre3) could it be the
>     Thibault> cause of my problem ? 
> 
> Hmm.  I guess I'll have to try on x86.  19apre3 (why not just 19a?)

No particular reason except that I have been lazy ...

> shouldn't really matter.
> 
>     Thibault> What can I do to track the problem?
> 
>     Thibault> * (geev m)
>     Thibault> Terminated
> 
> Why does it say "Terminated"?  It dies by itself?  You killed it?
> Linux's out-of-memory killer killed it?  Is there a core dump?
> 

Sorry, I should have explained that. I killed the process after it ran
for several minutes using 100% of cpu.
 
> Ray
> 

Re: [Matlisp-users] Problem with function geev

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

>>>>> "Thibault" == Thibault Langlois <tl...@di...> writes:

    Thibault> Ray, I saw your memo on #lisp. I downloaded the csv version and
    Thibault> installed it without problem. But I continue to get the same behavior :-
    Thibault> ( : when I use (geev ..) it starts computing and never ends. 
    Thibault> I am still using an "old" version of cmucl (19apre3) could it be the
    Thibault> cause of my problem ? 

Hmm.  I guess I'll have to try on x86.  19apre3 (why not just 19a?)
shouldn't really matter.

    Thibault> What can I do to track the problem?

    Thibault> * (geev m)
    Thibault> Terminated

Why does it say "Terminated"?  It dies by itself?  You killed it?
Linux's out-of-memory killer killed it?  Is there a core dump?

Ray

RE: [Matlisp-users] Problem with function geev

[Ernst v. W. <ev...@in...>]

Hey, I have had the same problem with geev for years.  I use Allegro.  SVD
has always been a perfect replacement for me: it works and is more than fast
enough for my purposes.  Maybe wrong of me not to heve mentioned this
before.

Kind regards,

Ernst van Waning

> -----Oorspronkelijk bericht-----
> Van: mat...@li... 
> [mailto:mat...@li...] Namens 
> Thibault Langlois
> Verzonden: 27 July 2005 12:49
> Aan: mat...@li...
> Onderwerp: [Matlisp-users] Problem with function geev
> 
> Hi,
> Ray, I saw your memo on #lisp. I downloaded the csv version 
> and installed it without problem. But I continue to get the 
> same behavior :- ( : when I use (geev ..) it starts computing 
> and never ends. 
> I am still using an "old" version of cmucl (19apre3) could it 
> be the cause of my problem ? 
> What can I do to track the problem?
> 
> wok:/usr/local/src/matlisp$ cmucl
> ; Loading #p"/home/tl/init.lisp".
> ;; Loading #p"/home/tl/comp/lang/lisp/code/asdf/asdf.x86f".
> CMU Common Lisp 19a-pre3, running on wok With core: 
> /usr/local/cmucl-19a/lib/cmucl/lib/lisp.core
> Dumped on: Wed, 2004-06-30 18:13:25+01:00 on lorien 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
> * (load "/usr/local/src/matlisp/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".
> 
> [...]
> 
>  ** MATLISP is loaded.  Type (HELP MATLISP)
>     to see a list of available symbols.
>     To use matlisp:
> 
>           (use-package "MATLISP")
> 
>     or
> 
>           (in-package "MATLISP-USER")
> 
>  ** The logical pathname matlisp has been
>     set to:
> 
>           /usr/local/src/matlisp/
> 
> ; T
> * (in-package :matlisp-user)
> 
> #<The MATLISP-USER package, 1/9 internal, 0/2 external>
> * (setq m (make-real-matrix '((1 1 2) (2 2 4) (3 3 6))))
> 
> Warning:  Declaring M special.
> 
> #<REAL-MATRIX  3 x 3
>     1.0000      1.0000      2.0000     
>     2.0000      2.0000      4.0000     
>     3.0000      3.0000      6.0000     >
> * (geev m)
> Terminated
> wok:/usr/local/src/matlisp$ 
> 
> I am not using the last version of cmucl:
>  
> CL-USER> (lisp-implementation-version)
> "19a-pre3"
> 
> 
> --
> Thibault Langlois <tl...@di...>
> FCUL / DI
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

[Matlisp-users] Problem with function geev

[Thibault L. <tl...@di...>]

Hi,
Ray, I saw your memo on #lisp. I downloaded the csv version and
installed it without problem. But I continue to get the same behavior :-
( : when I use (geev ..) it starts computing and never ends. 
I am still using an "old" version of cmucl (19apre3) could it be the
cause of my problem ? 
What can I do to track the problem?

wok:/usr/local/src/matlisp$ cmucl
; Loading #p"/home/tl/init.lisp".
;; Loading #p"/home/tl/comp/lang/lisp/code/asdf/asdf.x86f".
CMU Common Lisp 19a-pre3, running on wok
With core: /usr/local/cmucl-19a/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2004-06-30 18:13:25+01:00 on lorien
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
* (load "/usr/local/src/matlisp/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".

[...]

 ** MATLISP is loaded.  Type (HELP MATLISP)
    to see a list of available symbols.
    To use matlisp:

          (use-package "MATLISP")

    or

          (in-package "MATLISP-USER")

 ** The logical pathname matlisp has been
    set to:

          /usr/local/src/matlisp/

; T
* (in-package :matlisp-user)

#<The MATLISP-USER package, 1/9 internal, 0/2 external>
* (setq m (make-real-matrix '((1 1 2) (2 2 4) (3 3 6))))

Warning:  Declaring M special.

#<REAL-MATRIX  3 x 3
    1.0000      1.0000      2.0000     
    2.0000      2.0000      4.0000     
    3.0000      3.0000      6.0000     >
* (geev m)
Terminated
wok:/usr/local/src/matlisp$ 

I am not using the last version of cmucl:
 
CL-USER> (lisp-implementation-version)
"19a-pre3"


-- 
Thibault Langlois <tl...@di...>
FCUL / DI

Re: [Matlisp-users] SBCL Problems (odd number of &KEY arguments)

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

>>>>> "Ryan" == Ryan Adams <rp...@ca...> writes:

    Ryan> On Tue, 2005-06-14 at 12:04 -0400, Raymond Toy wrote:
    >> It's probably not a good idea to (use-package "MATLISP") when you're
    >> in the CL-USER package.  You probably want to do (in-package
    >> "MATLISP").
    >> 
    >> Second, try it without slime.  

    Ryan> I've tried this with both (in-package "MATLISP") and (in-package
    Ryan> "MATLISP-USER") with the same result (below).  One observation: at home,
    Ryan> on my Gentoo machine, I have SBCL 0.8.21 and have gone through the same
    Ryan> procedure.  It complains identically down to the bit about "printed 5
    Ryan> notes", but then prints the correct help output.  Also, it *seems* that
    Ryan> in both cases, the installation itself is alright.  If I type (rand 1),
    Ryan> for example, I get an appropriate output.  Would indicate that it is
    Ryan> just something broken with the man system?

Not sure, but if the same version of matlisp and sbcl works on one
machine but not another, then the machines are somehow different.

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

    Ryan> restarts (invokable by number or by possibly-abbreviated name):
    Ryan>   0: [ABORT] Exit debugger, returning to top level.

    Ryan> ((SB-PCL::FAST-METHOD DOCUMENTATION (SYMBOL (EQL 'STRUCTURE)))
    Ryan>  #<unavailable argument>
    Ryan>  #<unavailable argument>
    Ryan>  MATLISP::A
    Ryan>  #<unavailable argument>)
    Ryan> 0] 


Can you "backtrace" here to get a backtrace?

I think help should be a smaller macro, but that's an implementation
issue.

Ray

Re: [Matlisp-users] SBCL Problems (odd number of &KEY arguments)

[Ryan A. <rp...@ca...>]

On Tue, 2005-06-14 at 12:04 -0400, Raymond Toy wrote:

> It's probably not a good idea to (use-package "MATLISP") when you're
> in the CL-USER package.  You probably want to do (in-package
> "MATLISP").
> 
> Second, try it without slime.  

I've tried this with both (in-package "MATLISP") and (in-package
"MATLISP-USER") with the same result (below).  One observation: at home,
on my Gentoo machine, I have SBCL 0.8.21 and have gone through the same
procedure.  It complains identically down to the bit about "printed 5
notes", but then prints the correct help output.  Also, it *seems* that
in both cases, the installation itself is alright.  If I type (rand 1),
for example, I get an appropriate output.  Would indicate that it is
just something broken with the man system?

* (in-package "MATLISP-USER")
#<PACKAGE "MATLISP-USER">

* (help MATLISP)
; in: LAMBDA NIL
;     (FIRST MATLISP::ITEM)
; --> CAR 
; ==>
;   MATLISP::ITEM
; 
; note: deleting unreachable code

;     (SECOND MATLISP::ITEM)
; --> CADR CAR CDR 
; ==>
;   MATLISP::ITEM
; 
; note: deleting unreachable code

;     (DOLIST (MATLISP::I MATLISP::ITEM) (MATLISP::MAN MATLISP::I))
; --> BLOCK LET 
; ==>
;   MATLISP::ITEM
; 
; note: deleting unreachable code

;     (MATLISP::MAN MATLISP::I)
; ==>
;   MATLISP::I
; 
; note: deleting unreachable code

;     (ERROR "don't know how to help ~a" MATLISP::ITEM)
; ==>
;   "don't know how to help ~a"
; 
; note: deleting unreachable code
; 
; compilation unit finished
;   printed 5 notes

debugger invoked on a SIMPLE-ERROR in thread 21588:
  MATLISP::A is not the name of a structure type.

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD DOCUMENTATION (SYMBOL (EQL 'STRUCTURE)))
 #<unavailable argument>
 #<unavailable argument>
 MATLISP::A
 #<unavailable argument>)
0] 

Re: [Matlisp-users] SBCL Problems (odd number of &KEY arguments)

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

>>>>> "Ryan" == Ryan Adams <rp...@ca...> writes:

    Ryan> I've been trying to get Matlisp working with SBCL 0.9.1.28 on Debian.  I
    Ryan> have checked out the latest version of Matlisp from CVS, and I have
    Ryan> replaced the defsystem.lisp in that source with the latest version from
    Ryan> the CLOCC CVS repository.  I've also changed the 'LOAD-1-FOREIGN' to
    Ryan> 'LOAD-SHARED-OBJECT' in lazy-loader.lisp.in.  I've put a diff of this
    Ryan> here: 

Yes, I think that's the basic fix for sbcl.  I'll try to get those
changes checked in soon.

    Ryan> I start the REPL in SLIME, and run (load "/home ... /start.lisp"), it
    Ryan> runs to completion, finishing with the message about using (HELP
    Ryan> MATLISP) and (use-package "MATLISP"), but when I actually try to do
    Ryan> either of these things, I get errors.

It's probably not a good idea to (use-package "MATLISP") when you're
in the CL-USER package.  You probably want to do (in-package
"MATLISP").

Second, try it without slime.  

Ray

[Matlisp-users] SBCL Problems (odd number of &KEY arguments)

[Ryan A. <rp...@ca...>]

I've been trying to get Matlisp working with SBCL 0.9.1.28 on Debian.  I
have checked out the latest version of Matlisp from CVS, and I have
replaced the defsystem.lisp in that source with the latest version from
the CLOCC CVS repository.  I've also changed the 'LOAD-1-FOREIGN' to
'LOAD-SHARED-OBJECT' in lazy-loader.lisp.in.  I've put a diff of this
here: 

http://www.inference.phy.cam.ac.uk/rpa23/misc/sbcl-matlisp.rpa23.diff

I start the REPL in SLIME, and run (load "/home ... /start.lisp"), it
runs to completion, finishing with the message about using (HELP
MATLISP) and (use-package "MATLISP"), but when I actually try to do
either of these things, I get errors.

When I run:

CL-USER> (use-package "MATLISP")
debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread 17646: odd
number of &KEY arguments

CL-USER> (help MATLISP)

; in: LAMBDA NIL
;     (HELP MATLISP)
; 
; caught STYLE-WARNING:
;   undefined function: HELP
; 
; caught WARNING:
;   undefined variable: MATLISP

; 
; caught WARNING:
;   This variable is undefined:
;     MATLISP

; 
; caught STYLE-WARNING:
;   This function is undefined:
;     HELP
; 
; compilation unit finished
;   caught 2 WARNING conditions
;   caught 2 STYLE-WARNING conditions

debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread 17646: odd
number of &KEY arguments

Can anyone give me any advice as to where to start resolving this?  I am
a Lisp noob, so it may be something simple.

Thanks in advance...

Ryan


-- 
Ryan Adams <rp...@ca...>

Re: [Matlisp-users] Re: Matlisp-users digest, Vol 1 #121 - 2 msgs

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

>>>>> "CR" == C Rose <ju...@mi...> writes:

    CR> Further to my previous mail, in order to fix the LOAD-1-FOREIGN error, 
    CR> I edited lib/lazy-loader.lisp and lib/lazy-loader.lisp.in and replaced

    CR>    (sb-alien:load-1-foreign "matlisp:lib;libmatlisp.so"))

    CR> with

    CR>    (sb-alien:load-shared-object "matlisp:lib;libmatlisp.so"))

    CR> in each of the files. LOAD-1-FOREIGN is now deprecated in SBCL and is 
    CR> replaced by LOAD-SHARED-OBJECT. I wonder if one of the developers could 
    CR> commit this fix to CVS?

I'll look into this.  Are there other Matlisp and SBCL users?  I don't
use SBCL very often, so I need help and guidance here.

    CR> (I'm a bit new to CL, so I'm not sure what the difference between .lisp 
    CR> and .lisp.in files are. Anyone care to educate me?)

They bear the same relationship as configure.in and configure:
autoconf takes <foo>.lisp.in and processes it to create a <foo>.lisp.

Ray

Re: [Matlisp-users] Re: Matlisp on SBCL

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

>>>>> "Marco" == Marco Antoniotti <ma...@cs...> writes:

    Marco> Matlisp should just upload the new MK:DEFSYSTEM version.  Besides, the  
    Marco> latest version includes several improvements that make it easier to  
    Marco> support a modularized system as Matlisp.

I'll do this soon.

Ray

[Matlisp-users] Re: Matlisp-users digest, Vol 1 #121 - 2 msgs

[C R. <ju...@mi...>]

Hi all

Further to my previous mail, in order to fix the LOAD-1-FOREIGN error, 
I edited lib/lazy-loader.lisp and lib/lazy-loader.lisp.in and replaced

   (sb-alien:load-1-foreign "matlisp:lib;libmatlisp.so"))

with

   (sb-alien:load-shared-object "matlisp:lib;libmatlisp.so"))

in each of the files. LOAD-1-FOREIGN is now deprecated in SBCL and is 
replaced by LOAD-SHARED-OBJECT. I wonder if one of the developers could 
commit this fix to CVS?

(I'm a bit new to CL, so I'm not sure what the difference between .lisp 
and .lisp.in files are. Anyone care to educate me?)

Superficially, Matlisp now appears to work fine under SBCL (version 
0.9) on Linux x86 (haven't tried OS X yet).

One potential buglet appears when using the HELP function: before the 
documentation for the specified function is displayed, there are a 
series of 'notes' displayed (shown below). Not sure if this is a 
significant problem or not.

Thanks to those who assisted,

Chris

The following are the notes that get displayed when HELP is used:

;     (FIRST MATLISP::ITEM)
; --> CAR
; ==>
;   MATLISP::ITEM
;
; note: deleting unreachable code

;     (SECOND MATLISP::ITEM)
; --> CADR CAR CDR
; ==>
;   MATLISP::ITEM
;
; note: deleting unreachable code

;     (DOLIST (MATLISP::I MATLISP::ITEM) (MATLISP::MAN MATLISP::I))
; --> BLOCK LET
; ==>
;   MATLISP::ITEM
;
; note: deleting unreachable code

;     (MATLISP::MAN MATLISP::I)
; ==>
;   MATLISP::I
;
; note: deleting unreachable code

;     (ERROR "don't know how to help ~a" MATLISP::ITEM)
; ==>
;   "don't know how to help ~a"
;
; note: deleting unreachable code
;
; compilation unit finished
;   printed 5 notes

[Matlisp-users] Re: Matlisp-users digest, Vol 1 #121 - 2 msgs

[C R. <ju...@mi...>]

Thanks for the help, but I'm getting another error now (see below). 
Looks like it's caused by a change in SBCL. I'd be really grateful if 
someone could give me a hand sorting this out (putting a fix in the 
latest version of Matlisp to accommodate the change?).

Thanks again,,

Chris



; compiling (DEFUN TOKENIZE-LD-ARGS ...)
; compiling (DEFUN LOAD-BLAS-&-LAPACK-LIBRARIES ...)
; compiling (LOAD-BLAS-&-LAPACK-LIBRARIES)
debugger invoked on a SB-INT:UNSUPPORTED-OPERATOR in thread 22268:
   SB-ALIEN:LOAD-1-FOREIGN is unsupported as of SBCL 0.8.13. Please use 
LOAD-SHARED-OBJECT.

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

restarts (invokable by number or by possibly-abbreviated name):
   0: [ABORT] Exit debugger, returning to top level.

(SB-ALIEN:LOAD-1-FOREIGN)
0]

Re: [Matlisp-users] Re: Matlisp on SBCL

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

Yep.  The bug should be fixed in the latest file release.

Matlisp should just upload the new MK:DEFSYSTEM version.  Besides, the  
latest version includes several improvements that make it easier to  
support a modularized system as Matlisp.

Cheers
--
Marco






On May 28, 2005, at 2:52 AM, Vincent Arkesteijn wrote:

> Hi,
>
> In article <429...@mi...>, C Rose wrote:
>> I have got Matlisp going on CMUCL (and it looks great, BTW) but
>> I get an error when evaluating (load "start.lisp") on SBCL (on x86,
>> haven't tried OS X yet).
>
> I've had the same problem some time ago, and found it was caused by
> a bug in the defsystem.lisp that comes with matlisp. I reported it
> to the defsystem developers:
> http://sourceforge.net/mailarchive/forum.php? 
> thread_id=6505791&forum_id=6764
>
> I think the problem has been fixed since then, so I would suggest
> you to replace matlisp's defsystem.lisp with the the latest
> defsystem.lisp from clocc (in the src/defsystem-3.x directory) and
> see if that improves things.
>
> Good luck.
> Vincent.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit  
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>
--
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.

[Matlisp-users] Re: Matlisp on SBCL

[Vincent A. <vi...@ar...>]

Hi,

In article <429...@mi...>, C Rose wrote:
> I have got Matlisp going on CMUCL (and it looks great, BTW) but 
> I get an error when evaluating (load "start.lisp") on SBCL (on x86, 
> haven't tried OS X yet).

I've had the same problem some time ago, and found it was caused by
a bug in the defsystem.lisp that comes with matlisp. I reported it
to the defsystem developers:
http://sourceforge.net/mailarchive/forum.php?thread_id=6505791&forum_id=6764

I think the problem has been fixed since then, so I would suggest
you to replace matlisp's defsystem.lisp with the the latest
defsystem.lisp from clocc (in the src/defsystem-3.x directory) and
see if that improves things.

Good luck.
Vincent.

[Matlisp-users] Matlisp on SBCL

[C R. <ju...@mi...>]

Hi

I'd like to be able to use Matlisp on SBCL (on Linux x86 and OS X). The 
Matlisp front page says that Matlisp is not supported on SBCL, but the 
mailing lists and CVS version suggest that it is possible to run Matlisp 
on SBCL. I have got Matlisp going on CMUCL (and it looks great, BTW) but 
I get an error when evaluating (load "start.lisp") on SBCL (on x86, 
haven't tried OS X yet). The error as it is reported by SBCL is given 
below. I'd be very grateful if someone would let me know the status of 
Matlisp and SBCL and if possible, tell me what I'd need to do to get 
Matlisp going on SBCL (again, both Linux x86 and OS X).

Thanks in advance,

Chris


I am using SBCL 0.8.19 and get the following error:

;  - Loading defsystem "lazy-loader"
debugger invoked on a TYPE-ERROR in thread 13357:
  The value #<SB-IMPL::UNIX-HOST {5019611}>
  is not of type
    (OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME FILE-STREAM).

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

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT   ] Reduce debugger level (leaving debugger, returning to 
toplevel).
  1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
(PATHNAME-HOST 1 #<SB-IMPL::UNIX-HOST {5019611}>)[:EXTERNAL]
0]

Re: [Matlisp-users] [Patch] 2 enhancement for MatLISP

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

>>>>> "Goffioul" == Goffioul Michael <gof...@im...> writes:

    Goffioul> 1) Implement "colon"-like behavior of Matlab, but use #\| instead (to
    Goffioul> avoid clash
    Goffioul> with the package separator. So you can write something like: [1|10]
    Goffioul> (sent on matlisp-devel, but there are more people subscribed here)

This is neat.  Does it also work if you have [n|m]?

One thing I've wanted to do with matlisp is to have a matlisp repl
that would be a bit more like matlab's repl.  But I don't really know
how to write parsers and such for that.  

    Goffioul> 2) Implement colon index. A Matlab matrix access like a(:,2) would
    Goffioul> translate in
    Goffioul> MatLISP into (matrix-ref a :all 1). It uses the keyword :all.

I'll have to look into this.  matrix-ref is a method so adding a
keyword might complicate things.

Thanks,

Ray

[Matlisp-users] [Patch] 2 enhancement for MatLISP

[Goffioul M. <gof...@im...>]

Hi all,

Attached are 2 patches:

1) Implement "colon"-like behavior of Matlab, but use #\| instead (to =
avoid clash
with the package separator. So you can write something like: [1|10]
(sent on matlisp-devel, but there are more people subscribed here)

2) Implement colon index. A Matlab matrix access like a(:,2) would =
translate in
MatLISP into (matrix-ref a :all 1). It uses the keyword :all.

Enjoy.

Michael.