matlisp-users — General discussion list.

Re: [Matlisp-users] Terminating make

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

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

> all : $(MATLIB) lib/lazy-loader.o
>         $(LISPEXEC) -eval "(ext:save-lisp \"matlisp\" :print-herald t)" -eval "(quit)"

Better something like:

all : $(MATLIB) lib/lazy-loader.o
	$(LISPEXEC) -eval "(ext:save-lisp \"matlisp.core\")" -eval "(quit)"
	echo "#!/bin/sh" > matlisp
	echo "exec $(LISPEXEC) -core matlisp-core"  >> matlisp
	chmod +x matlisp

Nicolas.

Re: [Matlisp-users] Terminating Makefile

[<ma...@ll...>]

> This is acceptable to me.  However, I think we need to think about
> adding a script or something for the user to run to do the necessary
> magic to get him into matlisp.  We may also want to create a
> matlisp.core, which I don't think currently happens.  But I tend not
> to save cores and instead load up the individual fasls.  But matlisp
> is big so loading these is a bit slow....

Saving the Matlisp core (as well as the sample Matlisp startup script) 
is, IMHO, required at least as a user selectable option.  If changes
are to be made to the make file, having a "make intall" would be 
nice.

mike
**************************************************
Dr Michael A. Koerber    	Micro$oft Free Zone
MIT/Lincoln Laboratory	 	

Re: [Matlisp-users] Terminating Makefile

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

Raymond Toy <to...@rt...> writes:

> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
> 
>     Nicolas> For my Femlisp installation shell script I cannot build Matlisp via
>     Nicolas> configure/make, because the Makefile remains hanging in CMUCL until the
>     Nicolas> user types (quit).
> 
> [snip]
> 
>     Nicolas> This is not optimal, so that I suggest to change matlisp.mk.in as follows:
> 
>     Nicolas> all : $(MATLIB) lib/lazy-loader.o
>     Nicolas> 	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp"))'
> 
>     Nicolas> becomes
> 
>     Nicolas> all : $(MATLIB) lib/lazy-loader.o
>     Nicolas> 	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp") (ext:quit))'
> 
>     Nicolas> What do you think?
> 
> This is acceptable to me.  However, I think we need to think about
> adding a script or something for the user to run to do the necessary
> magic to get him into matlisp.  We may also want to create a
> matlisp.core, which I don't think currently happens.  But I tend not
> to save cores and instead load up the individual fasls.  But matlisp
> is big so loading these is a bit slow....
> 
> Ray

You could do (for CMUCL, I don't know ACL) something like:

all : $(MATLIB) lib/lazy-loader.o
        $(LISPEXEC) -eval "(ext:save-lisp \"matlisp\" :print-herald t)" -eval "(quit)"

BTW: does this work on all platforms?  Recently, I observed that my
restarted core did not find "dcopy_" anymore.  On the other hand, I
remember having saved CMUCL/Matlisp successfully before.

Nicolas.

Re: [Matlisp-users] Terminating Makefile

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

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

    Nicolas> For my Femlisp installation shell script I cannot build Matlisp via
    Nicolas> configure/make, because the Makefile remains hanging in CMUCL until the
    Nicolas> user types (quit).

[snip]

    Nicolas> This is not optimal, so that I suggest to change matlisp.mk.in as follows:

    Nicolas> all : $(MATLIB) lib/lazy-loader.o
    Nicolas> 	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp"))'

    Nicolas> becomes

    Nicolas> all : $(MATLIB) lib/lazy-loader.o
    Nicolas> 	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp") (ext:quit))'

    Nicolas> What do you think?

This is acceptable to me.  However, I think we need to think about
adding a script or something for the user to run to do the necessary
magic to get him into matlisp.  We may also want to create a
matlisp.core, which I don't think currently happens.  But I tend not
to save cores and instead load up the individual fasls.  But matlisp
is big so loading these is a bit slow....

Ray

Re: [Matlisp-users] Terminating Makefile^Wmake

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

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

Replace
> configure/make, because the Makefile remains hanging in CMUCL until the

by
> configure/make, because make remains hanging in CMUCL until the

[Matlisp-users] Terminating Makefile

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

For my Femlisp installation shell script I cannot build Matlisp via
configure/make, because the Makefile remains hanging in CMUCL until the
user types (quit).

What I do at the moment is to do

./configure --with-lisp=cmucl --with-lisp-exec=$CMUCL_BINARY $WITH_ATLAS --prefix=`pwd`
make -f matlisp.mk lib/libmatlisp.so;
make -f matlisp.mk lib/lazy-loader.o;
$CMUCL_BINARY -noinit -nositeinit -load "start.lisp" -eval "(quit)"

This is not optimal, so that I suggest to change matlisp.mk.in as follows:

all : $(MATLIB) lib/lazy-loader.o
	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp"))'

becomes

all : $(MATLIB) lib/lazy-loader.o
	$(LISPEXEC) $(LISPEVAL) '(progn (load "start.lisp") (ext:quit))'

What do you think?

Nicolas.

[Matlisp-users] Comflict of MATLISP:REAL and COMMON-LISP:REAL

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

Hello,

the real part of a matrix is obtained by MATLISP:REAL which conflicts with
the type COMMON-LISP:REAL when both MATLISP and COMMON-LISP are used in a
defpackage form.  I think that this should be possible without such
problems.  The naming is also not perfect because the function would better
fit with CLs function REALPART.

Therefore I suggest to change the name of REAL in MATLISP to MREALPART (or
something else not colliding with COMMON-LISP symbols.  One might keep an
alias MATLISP:REAL (marked as deprecated) which is not exported.  This
might keep some existing code working in spite of this change.

What do developers and users think about this?

Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

On Tuesday, Oct 14, 2003, at 12:22 America/New_York, Nicolas Neuss 
wrote:
>

> Fine.  Another question: Marco Antoniotti has mailed me privately that 
> one
> of my bugs might be due to an old defsystem in Matlisp.

Sorry.  I meant to send the message to the list.



>  He suggested that
> I should try a newer version.  Wouldn't it be the best if Matlisp 
> would use
> some defsystem from CLOCC?  OK, this would mean that Matlisp needs 
> CLOCC
> installed (at least partially), but CLOCC works on more systems than
> Matlisp anyway.

You do not need CLOCC installed to use DEFSYSTEM.  You can get it 
separatedly.

>
> Aside: I do not include Ilisp which does not work for the new CMUCL.  
> What
> do people on this list use?  Ilisp appears to me as a rather fragile 
> tool.

Ahem!  ILISP is a very stable system.  However it assumes some 
implementation dependent things.
If it does not work with the latest and greatest CMUCL, send an email 
to the ILISP-HELP mailing list.

Most likely it is going to be a very simple feature problem.

Cheers

--
Marco Antoniotti
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] Snapshot/Release?

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

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

> I looked and GENERIC-FUNCTION-PRETTY-ARGLIST is used in my ILISP version.

Sorry, I didn't look good enough.  Seems that PCL::GF-PRETTY-ARGLIST has to
be called.  Will try.

Nicolas.

[Matlisp-users] Matlisp snapshot release 2003-10-14 available

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

A snapshot of the matlisp CVS sources is now available for your
perusal.  If you have been using the CVS version, then this is nothing
new.  If you haven't been able to use the CVS version, this is a
simple snapshot of the current CVS sources.  

It includes many changes and bug fixes from the very old 1.0b release,
but should still be backward compatible with 1.0b.  Basic
functionality is the same.  I did not keep good track of what's
changed between the releases, unfortunately, and a diff is too big for
me to sort out.

Hope this is useful to you.

Ray

Re: [Matlisp-users] Snapshot/Release?

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

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

    Nicolas> Users, hear!
    Nicolas> I vote for MREALPART.

Ask again with a different message, so users (and developers) who
weren't following this will see it. :-)  Try both users and developers
mailing lists.

    Nicolas> See http://www.femlisp.org.  My wishful thinking is that it might become a
    Nicolas> better alternative to Femlab some day, at least for hard problems where
    Nicolas> Lisp shines.  I guess I will announce it this year on c.l.l., but it has to
    Nicolas> be accelerated quite a bit before it can be recommended to ordinary
    Nicolas> numerical analysts.

Neat pictures, but I don't understand FEM.

    >> I use Ilisp.  May switch to SLIME.  

    Nicolas> I searched for SLIME today, but didn't find it.  Where is its home?

You'll have to wait.  It was accidentally deleted from sourcforge, but
it is being revived.  But it is also being registered on savannah.org,
so I don't know where its real home will be.

It sounds pretty nice, but only works for CMUCL/SBCL/OpenMCL.  Tightly
integrated with the underlying Lisp.

    Nicolas> I looked and GENERIC-FUNCTION-PRETTY-ARGLIST is used in my ILISP version.

If it's still not working for you, you can ask me questions (but not
preferably not here on this list).

    Nicolas> Somehow I do not understand this whole problem of putting together a stable
    Nicolas> CL enviroment in Emacs.  Why is the interface defined by inferior-lisp,
    Nicolas> ILISP and ELI not kept up-to-date BY THE CL-IMPLEMENTATIONS which want to
    Nicolas> use them?

Well, I do send reports and/or fixes to ilisp when something is
broken, but I don't use the latest snapshots so I don't know what's
happening there.

Ray

Re: [Matlisp-users] Snapshot/Release?

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

Raymond Toy <to...@rt...> writes:

> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
> 
>     Nicolas> Why does it have to be REAL?  If you shadow CL-symbols (which you should
>     Nicolas> not do here, IMO) you should shadow REALPART for this purpose :-)
> 
>     Nicolas> I would suggest some other name, e.g. REAL-PART or MREALPART.
> 
> You will have to ask existing users what they think about this
> change.  I'm guessing they won't be happy either.

Users, hear!
I vote for MREALPART.

> Nice!  (What is Femlisp again?)

See http://www.femlisp.org.  My wishful thinking is that it might become a
better alternative to Femlab some day, at least for hard problems where
Lisp shines.  I guess I will announce it this year on c.l.l., but it has to
be accelerated quite a bit before it can be recommended to ordinary
numerical analysts.

>     Nicolas> Aside: I do not include Ilisp which does not work for the new CMUCL.  What
>     Nicolas> do people on this list use?  Ilisp appears to me as a rather fragile tool.
>     Nicolas> At the moment, I still use an old version (with a February CMUCL), and I
>     Nicolas> have noticed that I use more or less only keybindings which standard
>     Nicolas> inferior-lisp-mode has as well.  If this mode could be somewhat enhanced,
>     Nicolas> it might very well replace Ilisp for me...
> 
> I use Ilisp.  May switch to SLIME.  

I searched for SLIME today, but didn't find it.  Where is its home?

> Ilisp may not work with current CMUCL because ilisp was using some PCL
> internal function which doesn't exist anymore.  I'm not exactly sure
> what the change was, but look for pcl: in cmulisp.lisp.  I think the
> function should be generic-function-pretty-arglist instead of whatever
> it's using now.

I looked and GENERIC-FUNCTION-PRETTY-ARGLIST is used in my ILISP version.

Somehow I do not understand this whole problem of putting together a stable
CL enviroment in Emacs.  Why is the interface defined by inferior-lisp,
ILISP and ELI not kept up-to-date BY THE CL-IMPLEMENTATIONS which want to
use them?

Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

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

    Nicolas> Why does it have to be REAL?  If you shadow CL-symbols (which you should
    Nicolas> not do here, IMO) you should shadow REALPART for this purpose :-)

    Nicolas> I would suggest some other name, e.g. REAL-PART or MREALPART.

You will have to ask existing users what they think about this
change.  I'm guessing they won't be happy either.

    >> Maybe today, if I can remember how to do this....

    Nicolas> Fine.  Another question: Marco Antoniotti has mailed me privately that one
    Nicolas> of my bugs might be due to an old defsystem in Matlisp.  He suggested that
    Nicolas> I should try a newer version.  Wouldn't it be the best if Matlisp would use
    Nicolas> some defsystem from CLOCC?  OK, this would mean that Matlisp needs CLOCC
    Nicolas> installed (at least partially), but CLOCC works on more systems than
    Nicolas> Matlisp anyway.

The defsystem that Matlisp uses is a copy of the CLOCC version.  I've
just updated Matlisp version with the latest from CLOCC so it should
work fine with the latest CMUCL CVS versions.  We decided just
manually updated defsystem once in a while was better than forcing
users to get defsystem on their own.

    Nicolas> P.S.: I have a really nice setup script for Femlisp now.  Simply run it and
    Nicolas> CMUCL, Matlisp, CL-PPCRE, infix, and Femlisp are installed automatically on
    Nicolas> a Linux/x86 architecture in some directory of your choice.  I want to test
    Nicolas> it here a little more and then put it out.

Nice!  (What is Femlisp again?)

    Nicolas> Aside: I do not include Ilisp which does not work for the new CMUCL.  What
    Nicolas> do people on this list use?  Ilisp appears to me as a rather fragile tool.
    Nicolas> At the moment, I still use an old version (with a February CMUCL), and I
    Nicolas> have noticed that I use more or less only keybindings which standard
    Nicolas> inferior-lisp-mode has as well.  If this mode could be somewhat enhanced,
    Nicolas> it might very well replace Ilisp for me...

I use Ilisp.  May switch to SLIME.  

Ilisp may not work with current CMUCL because ilisp was using some PCL
internal function which doesn't exist anymore.  I'm not exactly sure
what the change was, but look for pcl: in cmulisp.lisp.  I think the
function should be generic-function-pretty-arglist instead of whatever
it's using now.

Ray

Re: [Matlisp-users] Snapshot/Release?

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

Raymond Toy <to...@rt...> writes:

> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
> 
>     Nicolas> I do not use REAL at all, so I think it is somewhat ugly that my
>     Nicolas> packages have to be changed to accomodate this problem.  (And there
>     Nicolas> are other packages of mine using MATLISP, and I would have to change
>     Nicolas> those as well.)  Is it really necessary to export MATLISP:REAL?
> 
> Ok, I looked into this.  MATLISP:REAL is a function to get the real
> part of a matrix.  I think we need to export this.
> 
> I am, however, open to other suggestions, but I just don't see how we
> can get around your desire of not exporting REAL.

Why does it have to be REAL?  If you shadow CL-symbols (which you should
not do here, IMO) you should shadow REALPART for this purpose :-)

I would suggest some other name, e.g. REAL-PART or MREALPART.

> Maybe today, if I can remember how to do this....

Fine.  Another question: Marco Antoniotti has mailed me privately that one
of my bugs might be due to an old defsystem in Matlisp.  He suggested that
I should try a newer version.  Wouldn't it be the best if Matlisp would use
some defsystem from CLOCC?  OK, this would mean that Matlisp needs CLOCC
installed (at least partially), but CLOCC works on more systems than
Matlisp anyway.

> Ray

P.S.: I have a really nice setup script for Femlisp now.  Simply run it and
CMUCL, Matlisp, CL-PPCRE, infix, and Femlisp are installed automatically on
a Linux/x86 architecture in some directory of your choice.  I want to test
it here a little more and then put it out.

Aside: I do not include Ilisp which does not work for the new CMUCL.  What
do people on this list use?  Ilisp appears to me as a rather fragile tool.
At the moment, I still use an old version (with a February CMUCL), and I
have noticed that I use more or less only keybindings which standard
inferior-lisp-mode has as well.  If this mode could be somewhat enhanced,
it might very well replace Ilisp for me...

Re: [Matlisp-users] Snapshot/Release?

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

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

    Nicolas> I do not use REAL at all, so I think it is somewhat ugly that my
    Nicolas> packages have to be changed to accomodate this problem.  (And there
    Nicolas> are other packages of mine using MATLISP, and I would have to change
    Nicolas> those as well.)  Is it really necessary to export MATLISP:REAL?

Ok, I looked into this.  MATLISP:REAL is a function to get the real
part of a matrix.  I think we need to export this.

I am, however, open to other suggestions, but I just don't see how we
can get around your desire of not exporting REAL.

    Nicolas> I'm looking forward to that snapshot...
    >> 
    >> Soon.  Hopefully before the end of the week.
    >> 
    >> Ray

    Nicolas> Fine.

Maybe today, if I can remember how to do this....

Ray

Re: [Matlisp-users] Snapshot/Release?

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

Raymond Toy <to...@rt...> writes:

> Obviously this is because matlisp defines a REAL function that
> conflicts with the COMMON-LISP version.  Matlisp does a
> shadowing-import (I think) to get this to work.  You may have to do
> the samething in your ALGEBRA package to select the right one.  Of
> course, then you'll have to use a package qualifier to get REAL from
> the other package.

I do not use REAL at all, so I think it is somewhat ugly that my
packages have to be changed to accomodate this problem.  (And there
are other packages of mine using MATLISP, and I would have to change
those as well.)  Is it really necessary to export MATLISP:REAL?

>     Nicolas> I'm looking forward to that snapshot...
> 
> Soon.  Hopefully before the end of the week.
> 
> Ray

Fine.

Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

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

    Nicolas> I encounter the following problems with Matlisp:

    Nicolas> 1. With the snapshot cmucl-2003-10-x86-linux.tar.bz2, I get the following

[snip]

    Nicolas> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
    Nicolas>    #() is not of type (OR CONS
    Nicolas>                           BASE-STRING
    Nicolas>                           LISP::PATTERN
    Nicolas>                           (MEMBER NIL :UNSPECIFIC :WILD))
    Nicolas>    [Condition of type TYPE-ERROR]

I think this is fixed in CVS now.

    Nicolas> 2. This works with cmucl-2003-09-14-x86-linux.tar.bz2.  I still get a
    Nicolas>    conflict when loading the following package definition:

    Nicolas> (defpackage "ALGEBRA"
    Nicolas>   (:use "COMMON-LISP" "GENERAL" "MACROS" "UTILITIES" "MATLISP")
    Nicolas>   (:import-from "EXTENSIONS" "REQUIRED-ARGUMENT")
    Nicolas>   (:export
    Nicolas>     ...))

    Nicolas> Namely:

    Nicolas> ---------------------------------------------------------------------------
    Nicolas> Error in function USE-PACKAGE:
    Nicolas>    Use'ing package COMMON-LISP results in name conflicts for these symbols:
    Nicolas> (MATLISP:REAL MATLISP:REAL)
    Nicolas>    [Condition of type SIMPLE-ERROR]

Obviously this is because matlisp defines a REAL function that
conflicts with the COMMON-LISP version.  Matlisp does a
shadowing-import (I think) to get this to work.  You may have to do
the samething in your ALGEBRA package to select the right one.  Of
course, then you'll have to use a package qualifier to get REAL from
the other package.

    Nicolas> Yes, "ref.lisp" looks a little messy now.  Did it help in performance?  I

Found and fixed one a couple of silly typo bugs this weekend.  

When I last tested it using JOIN as the test function and enabling
Gerd's PCL changes (included in recent CMUCL snapshots), it did help.
The gain wasn't huge though---maybe a few percent?

    Nicolas> think that the separation in 1d and 2d access is right, at least it fitted
    Nicolas> well with my extensions.

That's good.  So the changes, even if they don't help with speed, is
helping you!

    Nicolas> I'm looking forward to that snapshot...

Soon.  Hopefully before the end of the week.

Ray

[Matlisp-users] Saving core with matlisp

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

Hello.

I have run across another problem.  I want to save a core including Matlisp
and Femlisp which I do using

(ext:save-lisp "/home/neuss/FEMLISP/bin/femlisp-core" :site-init NIL
               :print-herald t)

When I use this core I get the error message:

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

Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(KERNEL:UNDEFINED-FOREIGN-SYMBOL-ERROR-HANDLER "<error finding name>"
                                               #.(SYSTEM:INT-SAP #x3FFFCA50)
                                               #<Alien (* #) at #x3FFFC6E8>
                                               (14))
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
---------------------------------------------------------------------------

Does anyone know what is the problem here?

Thanks, Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

Nicolas Neuss <Nic...@iw...> writes:
> 
> Restarts:
>   0: [CONTINUE] Unintern the conflicting symbols in the ALGEBRA package.
>   1:            Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/algebra/algebra-defp.lisp".
>   2:            Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/start.lisp".
>   3: [ABORT   ] Skip remaining initializations.
> ---------------------------------------------------------------------------
> 
> After pressing RETURN here, everything works fine.

"0 RETURN", of course.

Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

Raymond Toy <to...@rt...> writes:

> >>>>> "Nicolas" == Nicolas Neuss <Nic...@iw...> writes:
> 
>     Nicolas> Nicolas Neuss <Nic...@iw...> writes:
>     >> Dear maintainers.
>     >> 
>     >> I would find it nice if a new release or a snapshot of a recent version
>     >> would be available for download.  I am just writing an installation
>     >> script for my PDE tool box Femlisp where also Matlisp is needed.  Since
>     >> V1.0b does not work any more with Femlisp this would require obtaining a
>     >> recent
> 
>     Nicolas> Correction: "... does not work with new CMUCL versions anymore ..."
> 
> Femlisp or Matlisp?  If the latter, I thought I had tried it out
> (slightly) with a fairly recent version.  (Ooh, maybe it's a defsystem
> problem?)

Matlisp almost works (Femlisp had more problems).

I encounter the following problems with Matlisp:

1. With the snapshot cmucl-2003-10-x86-linux.tar.bz2, I get the following

---------------------------------------------------------------------------
; Loading #p"/home/neuss/FEMLISP/matlisp/start.lisp".
; Converted SETLOGICALROOT.
; Converted GETLOGICALROOT.
; Converted DEFLOGICALPATH.
;; Loading #p"/home/neuss/FEMLISP/matlisp/system.dcl".
;;; Loading #p"/home/neuss/FEMLISP/matlisp/defsystem.lisp".
Warning:  Old-style IN-PACKAGE.
; Compiling LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. KERNEL::OBJECT STREAM): 
; Compiling Top-Level Form: 
; Compiling LAMBDA (PCL::.PV-CELL. PCL::.NEXT-METHOD-CALL. KERNEL::OBJECT STREAM): 
; Compiling Top-Level Form: 

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
   #() is not of type (OR CONS
                          BASE-STRING
                          LISP::PATTERN
                          (MEMBER NIL :UNSPECIFIC :WILD))
   [Condition of type TYPE-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of "matlisp:system.dcl".
  1:            Return NIL from load of "start.lisp".
  2: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

("DEFUN MAKE-PATHNAME" 268431142 8)[:OPTIONAL]
Source: Error finding source: 
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:code/pathname.lisp.
0] 
---------------------------------------------------------------------------

2. This works with cmucl-2003-09-14-x86-linux.tar.bz2.  I still get a
   conflict when loading the following package definition:

(defpackage "ALGEBRA"
  (:use "COMMON-LISP" "GENERAL" "MACROS" "UTILITIES" "MATLISP")
  (:import-from "EXTENSIONS" "REQUIRED-ARGUMENT")
  (:export
    ...))

Namely:

---------------------------------------------------------------------------
Error in function USE-PACKAGE:
   Use'ing package COMMON-LISP results in name conflicts for these symbols:
(MATLISP:REAL MATLISP:REAL)
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [CONTINUE] Unintern the conflicting symbols in the ALGEBRA package.
  1:            Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/algebra/algebra-defp.lisp".
  2:            Return NIL from load of "/home/neuss/FEMLISP/femlisp/src/start.lisp".
  3: [ABORT   ] Skip remaining initializations.
---------------------------------------------------------------------------

After pressing RETURN here, everything works fine.

>     Nicolas> Maybe it would be time for a new release anyhow.  1.0b is about 3 years
>     Nicolas> old!
> 
> Sorry, laziness on my part.  And now it's in an somewhat incomplete
> state because I've been modifying the matrix-ref methods to use clos
> to dispatch instead of the hand-written dispatcher.

Yes, "ref.lisp" looks a little messy now.  Did it help in performance?  I
think that the separation in 1d and 2d access is right, at least it fitted
well with my extensions.

> I will however create a snapshot sometime soon, after some testing
> with a recent CMUCL version.
> 
> Ray
> 

I'm looking forward to that snapshot...

Nicolas.

Re: [Matlisp-users] Snapshot/Release?

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

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

> Dear maintainers.
> 
> I would find it nice if a new release or a snapshot of a recent version
> would be available for download.  I am just writing an installation
> script for my PDE tool box Femlisp where also Matlisp is needed.  Since
> V1.0b does not work any more with Femlisp this would require obtaining a
> recent

Correction: "... does not work with new CMUCL versions anymore ..."

> version by CVS, which requires user interaction (pressing return).  I
> would like to avoid that.

Maybe it would be time for a new release anyhow.  1.0b is about 3 years
old!

Nicolas.

[Matlisp-users] Snapshot/Release?

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

Dear maintainers.

I would find it nice if a new release or a snapshot of a recent version
would be available for download.  I am just writing an installation script
for my PDE tool box Femlisp where also Matlisp is needed.  Since V1.0b does
not work any more with Femlisp this would require obtaining a recent
version by CVS, which requires user interaction (pressing return).  I would
like to avoid that.

Thank you, Nicolas.

Re: [Matlisp-users] Porting Matlisp?

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

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

    Nicolas> Hello,
    Nicolas> I would like to ask how difficult you would consider porting Matlisp to
    Nicolas> other platforms than ACL or CMUCL.  Especially SBCL (and maybe CLISP) are
    Nicolas> interesting for me now.

SBCL should not be hard, but I haven't tried.  Clisp is doable, but
there will be a speed penalty, I think, because you can't directly
access Clisp's internal array layout.  Thus, every matrix operation
will do a copy in and copy out.  But perhaps that's still a win for
Clisp. 

In terms of porting, I think you only need to update the FFI code to
do the right thing for your desired platform.

Ray

[Matlisp-users] Porting Matlisp?

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

Hello,

I would like to ask how difficult you would consider porting Matlisp to
other platforms than ACL or CMUCL.  Especially SBCL (and maybe CLISP) are
interesting for me now.

Yours, Nicolas.

Re: [Matlisp-users] symbol conflicts

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

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

    rif> I can compile OK, but I (use :matlisp) encounters the problem that
    rif> there is already a symbol "real" in the common-lisp-user package.  I
    rif> can unintern it manually, but I don't know whether this is safe (I'm
    rif> not sure how to figure out what it does, it seems to be the name of a
    rif> class, rather than a function).  What's the right approach?

I thought I had fixed this so that the matlisp REAL symbol didn't
collide with the COMMON-LISP symbol.  Perhaps this is messed up?

The obvious work-around is not to do (use :matlisp), and do your work
in the matlisp package.


    rif> Also, for anyone using cllib (which I'd think could be many people),
    rif> there's also conflicts with "norm" and "dot".

I think that's what packages are for.  If you're going to do (use
:matlisp) and (use :cllib), you'll get this problem.  You have to
decide which NORM and DOT functions you really want by importing (or
shadow-importing) from the desired package.

Ray