matlisp-users — General discussion list.

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

Marco Antoniotti wrote:
> 
> On Wednesday, May 26, 2004, at 00:48 America/New_York, Robert Sedgewick 
> wrote:
> 
>> On May 26, 2004, at 12:05 AM, si...@EE... wrote:
>>
> 
> There has been a very recent change in MK:DEFSYSTEM w.r.t. logical 
> pathnames and Matlisp.  You should not use the Matlisp included version 
> but use instead the latest release from the CLOCC.
> 

I'll have to check that out....


>>> BTW, what is 'asdf'?
>>
>>
> 
> 
> MK:DEFSYSTEM handles Fortran files.  Also, REQUIRE is deprecated in the 
> ANSI Spec.

You mean handling of Fortran files is built in, or easily added?

Yeah, it seems to me that asdf and mk:defsystem are pretty equally 
matched.  I just know asdf better because of it being bundled with sbcl.....

Either way, I think it would be nice to remove the matlisp's build 
dependence on make (to make libmatlisp.so) and replace it with a more 
sophisticated mk:defsystem or asdf system definition.  But that is 
project for another day.


--Robbie

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

On Wednesday, May 26, 2004, at 00:48 America/New_York, Robert Sedgewick 
wrote:

> On May 26, 2004, at 12:05 AM, si...@EE... wrote:
>
>> A while back I had tried to compile matlisp
>> on linux and sbcl.  I went the defsystem way
>> and had no problems.  So perhaps this is indeed something
>> to look into.  I'm sure it's something simple.
>
> Yeah, I had that working at one point too.  I think the sbcl 
> developers have made their handling
> logical pathnames stricter recently.  I bet you are right and it is 
> some simple 1 line change somewhere.

There has been a very recent change in MK:DEFSYSTEM w.r.t. logical 
pathnames and Matlisp.  You should not use the Matlisp included version 
but use instead the latest release from the CLOCC.

>> BTW, what is 'asdf'?
>
> Its a competitor to defsystem.  Claimed to be more modern/extendable.  
> It is used by debian to load lisp packages for different 
> implementations.
>
> I like it because it comes built in to sbcl so only "(require 
> :foo-library)" is needed to load a library and because it can be 
> taught to handle fortran files.

MK:DEFSYSTEM handles Fortran files.  Also, REQUIRE is deprecated in the 
ANSI Spec.

Cheers

Marco
--
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.


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

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

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

    Tunc> I'll update the website.  So AFAIK, the current situation is:

    Tunc> Solaris ??:  CMU CL v??,  Allegro 6.0, 6.1, 6.2 based on libmatlisp.so
    Tunc>            which is compiled from the fortran sources using gcc and g77.
    Tunc>            It is also possible to link in Atlas.

Solaris 7 and 8 definitely works.  Probably 9 and later as well.  Not
sure about the CMUCL version, but I'm pretty 18e and later work.  Can
also use Sun's f77 compiler.

    Tunc> Linux:  CMU CL v??, SBCL v?? based on libmatlisp.so
    Tunc>            which is compiled from the fortran sources using gcc and g77.
    Tunc>            Is it possible to link in Atlas??

Same CMUCL versions as for Solaris.

    Tunc> MacOSX: SBCL v??
    Tunc>           I have no idea how you compile the fortran sources.

You can get g77 for MacOSX.  I might try it with CMUCL on MacOSX
sometime soon, since I just got g77.

    Tunc> The distributed configure file is compiled for Solaris and needs to
    Tunc> be recompiled using autoconf 2.5 or later for Linux and MacOS.

Does that really matter?  Isn't configure supposed to be able to run
on any Unix?  I'm pretty sure I run it on Linux without problems.

Ray

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

Yes.  But I have not been able to compile ATLAS on my machine.
I can get it to work with precompiled ATLAS's that are
available on the web.
  --tunc

> I use Matlisp/CMUCL on Debian with Atlas (no problem at all, and impressive
> performance gains for GEMM and GETRF for larger matrices).  However, I have
> not tried the CVS version of Matlisp yet.
>
> Out of curiosity: is using Atlas possible with Windows?
>
> Nicolas.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

si...@EE... writes:

> I'll update the website.  So AFAIK, the current situation is:
> 
> Windows 2000, XP:  Allegro 6.0, 6.1, 6.2 based on libmatlisp.dll
>            which is compiled from the fortran sources using MinGW.
> 
> Solaris ??:  CMU CL v??,  Allegro 6.0, 6.1, 6.2 based on libmatlisp.so
>            which is compiled from the fortran sources using gcc and g77.
>            It is also possible to link in Atlas.
> 
> Linux:  CMU CL v??, SBCL v?? based on libmatlisp.so
>            which is compiled from the fortran sources using gcc and g77.
>            Is it possible to link in Atlas??

I use Matlisp/CMUCL on Debian with Atlas (no problem at all, and impressive
performance gains for GEMM and GETRF for larger matrices).  However, I have
not tried the CVS version of Matlisp yet.

Out of curiosity: is using Atlas possible with Windows?

Nicolas.

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

On May 26, 2004, at 12:05 AM, si...@EE... wrote:

> A while back I had tried to compile matlisp
> on linux and sbcl.  I went the defsystem way
> and had no problems.  So perhaps this is indeed something
> to look into.  I'm sure it's something simple.

Yeah, I had that working at one point too.  I think the sbcl developers 
have made their handling
logical pathnames stricter recently.  I bet you are right and it is 
some simple 1 line change somewhere.


> BTW, what is 'asdf'?

Its a competitor to defsystem.  Claimed to be more modern/extendable.  
It is used by debian to load lisp packages for different 
implementations.

I like it because it comes built in to sbcl so only "(require 
:foo-library)" is needed to load a library and because it can be taught 
to handle fortran files.

Check out:
http://www.cliki.net/asdf
http://constantly.at/lisp/asdf/

Also there is a sample (not quite ready for public consumption, got 
some hard coded paths) asdf file for matlisp at
http://mercury.chem.pitt.edu/~rds/
If you like I can clean this up some....

--Robbie


>   --Tunc
>

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

A while back I had tried to compile matlisp
on linux and sbcl.  I went the defsystem way
and had no problems.  So perhaps this is indeed something
to look into.  I'm sure it's something simple.

BTW, what is 'asdf'?

  --Tunc

----- Original Message -----
From: Robert Sedgewick <rd...@me...>
Date: Tuesday, May 25, 2004 7:52 pm
Subject: Re: [Matlisp-users] Configuration failure on Linux/SBCL

> 
> On May 25, 2004, at 8:33 PM, si...@EE... wrote:
> 
> >
> > I'll update the website.  So AFAIK, the current situation is:
> >
> > Linux:  CMU CL v??, SBCL v?? based on libmatlisp.so
> >            which is compiled from the fortran sources using gcc 
> and 
> > g77.
> >            Is it possible to link in Atlas??
> 
> Works with SBCL 8.10.48 on x86 with asdf  doing the loading and 
> compiling (I wrote my own matlisp.asd file so I didn't have to 
> fiddle 
> with defsystem and the makefile)
> 
> Trying the makefile/defsystem loading mechanism there are some 
> problems.  It gives this error
> """debugger invoked on a SIMPLE-ERROR in thread 18119:
>   cannot specify the version without a type: #<LOGICAL-PATHNAME
>                                                :HOST 
> #<SB-KERNEL:LOGICAL-HOST
>                                                        "MATLISP">
>                                                :DIRECTORY 
> (:ABSOLUTE 
> "BIN")
>                                                :NAME NIL
>                                                :TYPE NIL
>                                                :VERSION :NEWEST>"""
> 
> 
> This used to work so I think sbcl changed the way they handle 
> logical 
> pathnames.  I'll look into it
> 
> 
> Should be possible to link with Atlas, although I haven't tried this.
> 
> 
> >
> > MacOSX: SBCL v??
> >           I have no idea how you compile the fortran sources.
> >
> 
> Works on SBCL 8.8.0 with asdf loading. Although I get a weird 
> error 
> about a bogus file discriptor?  Seems to work if I choose the 
> "Remove 
> them" restart.  I think this is a sbcl problem and not a matlisp 
> one.....
> 
> There is also some weird problem with configure giving an error 
> (even 
> after being rebuilt).  autoconf can be frustrating.  I think fixed 
> this 
> before but I forget how.  I'll work on this sometime when I get a 
> chance.
> 
>  Requires Apple dev tool and g77 installed to compile the sources.
> Mine is installed with fink (fink.sf.net) but other versions such 
> as 
> darwinports
> (http://darwinports.opendarwin.org/) probably work too...
> 
> Should be possible to link with Atlas.
> 
> Sorry I didn't find these issues before I sent in the patch.  I'll 
> work 
> on these problems when I have some free time (probably this weekend).
> 
> --Robbie
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... 
> Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

On May 25, 2004, at 8:33 PM, si...@EE... wrote:

>
> I'll update the website.  So AFAIK, the current situation is:
>
> Linux:  CMU CL v??, SBCL v?? based on libmatlisp.so
>            which is compiled from the fortran sources using gcc and 
> g77.
>            Is it possible to link in Atlas??

Works with SBCL 8.10.48 on x86 with asdf  doing the loading and 
compiling (I wrote my own matlisp.asd file so I didn't have to fiddle 
with defsystem and the makefile)

Trying the makefile/defsystem loading mechanism there are some 
problems.  It gives this error
"""debugger invoked on a SIMPLE-ERROR in thread 18119:
   cannot specify the version without a type: #<LOGICAL-PATHNAME
                                                :HOST 
#<SB-KERNEL:LOGICAL-HOST
                                                        "MATLISP">
                                                :DIRECTORY (:ABSOLUTE 
"BIN")
                                                :NAME NIL
                                                :TYPE NIL
                                                :VERSION :NEWEST>"""


This used to work so I think sbcl changed the way they handle logical 
pathnames.  I'll look into it


Should be possible to link with Atlas, although I haven't tried this.


>
> MacOSX: SBCL v??
>           I have no idea how you compile the fortran sources.
>

Works on SBCL 8.8.0 with asdf loading. Although I get a weird error 
about a bogus file discriptor?  Seems to work if I choose the "Remove 
them" restart.  I think this is a sbcl problem and not a matlisp 
one.....

There is also some weird problem with configure giving an error (even 
after being rebuilt).  autoconf can be frustrating.  I think fixed this 
before but I forget how.  I'll work on this sometime when I get a 
chance.

  Requires Apple dev tool and g77 installed to compile the sources.
Mine is installed with fink (fink.sf.net) but other versions such as 
darwinports
(http://darwinports.opendarwin.org/) probably work too...

Should be possible to link with Atlas.

Sorry I didn't find these issues before I sent in the patch.  I'll work 
on these problems when I have some free time (probably this weekend).

--Robbie

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

I'll update the website.  So AFAIK, the current situation is:

Windows 2000, XP:  Allegro 6.0, 6.1, 6.2 based on libmatlisp.dll
           which is compiled from the fortran sources using MinGW.

Solaris ??:  CMU CL v??,  Allegro 6.0, 6.1, 6.2 based on libmatlisp.so
           which is compiled from the fortran sources using gcc and g77.
           It is also possible to link in Atlas.

Linux:  CMU CL v??, SBCL v?? based on libmatlisp.so
           which is compiled from the fortran sources using gcc and g77.
           Is it possible to link in Atlas??


MacOSX: SBCL v??
          I have no idea how you compile the fortran sources.

The distributed configure file is compiled for Solaris and needs to
be recompiled using autoconf 2.5 or later for Linux and MacOS.

Please correct these and I will update the homepages.

  --Tunc


----- Original Message -----
From: Robbie Sedgewick <rd...@me...>
Date: Tuesday, May 25, 2004 10:05 am
Subject: Re: [Matlisp-users] Configuration failure on Linux/SBCL

> Raymond Toy wrote:
> > Patch applied without problems.  I'm checking it in now, so I'd
> > appreciate it if you could test it out when you get a chance.
> > 
> 
> Great, it seems to work here (sbcl on linux/x86), I'll try it on 
> darwin/ppc when I get home, but it should work there too.
> 
> Now the only thing left to change is the website to let people 
> know that 
> it works with sbcl and on Mac OS X......
> 
> 
> Thanks,
> Robbie
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... 
> Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

Raymond Toy wrote:
> Patch applied without problems.  I'm checking it in now, so I'd
> appreciate it if you could test it out when you get a chance.
> 

Great, it seems to work here (sbcl on linux/x86), I'll try it on 
darwin/ppc when I get home, but it should work there too.

Now the only thing left to change is the website to let people know that 
it works with sbcl and on Mac OS X......


Thanks,
Robbie

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

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

    Robert> Let me know when you get the patch applied and I'll test it....

Patch applied without problems.  I'm checking it in now, so I'd
appreciate it if you could test it out when you get a chance.

Ray

Re: [Matlisp-users] Matlisp subset in pure CL

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

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

>     Nicolas> I have thought about this, but I am completely uncertain how to do such a
>     Nicolas> thing in a well-behaved way within ANSI CL.  The best thing would probably
>     Nicolas> be to pay Gerd Moellmann for implementing method inlining in CMUCL.  But
> 
> According to the CMUCL User's manual, Section 2.23.4 says that
> effective methods can be inlined.  Perhaps that is good enough.
> 
> Ray

Thanks for the pointer (I had to update my CMUCL manual to read it,
probably I should switch to a more recent CMUCL version).  I am not sure if
it helps me because of:

   "Please note that this form of inlining has no noticeable effect for
   effective methods that consist of a primary method only, which doesn't
   have keyword arguments. In such cases, PCL uses the primary method
   directly for the effective method."

Since I avoided method combination for BLAS routines anyhow, this might not
change much.  Anyway, I think I will be able to phrase my needs more
precisely when I have some working code.

Yours, Nicolas.

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

On May 21, 2004, at 8:51 AM, Raymond Toy wrote:

>>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:
>
>
> I would appreciate it if you could redo the patch and send it again.
> I'll make sure it gets applied.

Because of the earlier problem with the patch being too large for the 
sourceforge mailing list, I put the patch up on the web.

Its up at http://mercury.chem.pitt.edu/~rds/matlisp.sbcl.patch
the sources I generated the patch from are at
http://mercury.chem.pitt.edu/~rds/matlisp.sbcl.tar.gz
If there is any problem with the patch.

It is diffed off the current cvs so applying it shouldn't be a problem. 
  In addition to the sbcl support I also added a in-package statement to 
lib-src/cpoly/zeroin.lisp.  It's nice to have that in the file if you 
ask me.....

Let me know when you get the patch applied and I'll test it....

Thanks,
Robbie

Re: [Matlisp-users] Configuration failure on Linux/SBCL

[<dm...@ui...>]

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

> You need autoconf 2.50 or later, I think.  That macro was added around
> that time.  Maybe a little earlier.

It's all coming back to me now...well, what I ever knew of autoconf
is coming back to me....

It appears I have both versions 2.13 and 2.58 installed in /usr/bin,
while autoconf is a link to a wrapper that invokes one or the other:

dmmcf@ness% ls -l /usr/bin/autoconf*
    Apr 19 19:46 /usr/bin/autoconf -> ../lib/autoconf/ac-wrapper.pl
    Apr 19 19:46 /usr/bin/autoconf-2.13
    Apr 19 19:46 /usr/bin/autoconf-2.58

dmmcf@ness% autoconf --version
    Autoconf version 2.13

dmmcf@ness% WANT_AUTOCONF=2.5 autoconf --version
    autoconf (GNU Autoconf) 2.58

Sure enough,

    WANT_AUTOCONF=2.5 autoconf configure.in > configure

runs fine with Robbie's code.

Thanks, Ray.  I feel a little better now.

Cheers,
Michael

Re: [Matlisp-users] Configuration failure on Linux/SBCL

[<dm...@ui...>]

Robbie Sedgewick <rd...@me...> writes:

> Well, if you got this far then the configure script is probably
> fine. This must have happened after you tried to make it, right?
> Just remove all the .fasl files in the distribution and try it
> again. It should work.

After a little more brute-force cleanup and a fresh attempt, things
seem to be working.  Thanks for the code (and your interest).

Best regards,
Michael

-- 
D. Michael McFarland
Department of Aerospace Engineering
University of Illinois at Urbana-Champaign
mailto:dm...@ui... https://netfiles.uiuc.edu/dmmcf/www/

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

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

    Robbie> D. Michael McFarland wrote:

    >> The command
    >> autoconf configure.in > configure
    >> produced
    >> autoconf: Undefined macros:
    >> configure.in:259:AC_F77_FUNC(f77_name)
    >> It's certainly possible this is a symptom of a broader configuration
    >> problem, but I don't recall seeing any similar behavior in the past.
    >> 

    Robbie> It probably has something to do with your version of autoconf.  I
    Robbie> don't know much about it.

You need autoconf 2.50 or later, I think.  That macro was added around
that time.  Maybe a little earlier.

Ray

RE: [Matlisp-users] Matlisp subset in pure CL

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

Ah, yes, Nicolas, I would like to see that :-)

Ernst

> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...]On Behalf Of Nicolas
> Neuss
> Sent: 21 May 2004 15:04
> To: mat...@li...
> Subject: Re: [Matlisp-users] Matlisp subset in pure CL
>
>
> Raymond Toy <to...@rt...> writes:
>
> >     simsek> Having said that, matlisp has evolved along the
> way, with contributions
> >     simsek> from select individuals like yourself.  I think it
> may be time to
> >     simsek> consider more drastic functionality of the kind
> you're suggesting.
> >
> > I also think this is a good idea.  It would be nice if this approach
> > could be made seamless with Matlisp, so the user wouldn't have to know
> > unless he wanted to.  If it also means changing some Matlisp
> > functions, that would also be ok.  We might want to ask other users
> > about that, though. :-)
> >
> > We probably also want to do an official 2.0 release before adding such
> > features for the "3.0" release.
> >
> >     simsek> I, unfortunately, personally would not be able to
> participate in the development
> >     simsek> but I think there are people out there who might be.
> >
> > I can help some, but I don't use matlisp that much anymore.
> >
> > Ray
>
> When my sparse matrix code works, and the BLAS code generation has evolved
> to a satisfactory state, I'll come back on this...
>
> Yours, Nicolas.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

D. Michael McFarland wrote:

> 
> 
> The command
> 
>     autoconf configure.in > configure
> 
> produced
> 
>     autoconf: Undefined macros:
>     configure.in:259:AC_F77_FUNC(f77_name)
> 
> It's certainly possible this is a symptom of a broader configuration
> problem, but I don't recall seeing any similar behavior in the past.
> 

It probably has something to do with your version of autoconf.  I don't 
know much about it.


> I then tried the existing configure script, but that led to
> 
> /----
> | debugger invoked on a SB-FASL::INVALID-FASL-IMPLEMENTATION in thread 25305:
> |   #<FILE-STREAM for "file \"/home/dmmcf/lisp/lib/matlisp.sbcl/packages.fasl\""
> |     {98C8C69}> was compiled for implementation PPC, but this is a X86.
> \----
> 
> which is hard to argue with. :-)
> 

Well, if you got this far then the configure script is probably fine. 
This must have happened after you tried to make it, right?
Just remove all the .fasl files in the distribution and try it again. 
It should work.

--Robbie

> 
>>Let me know if you have any problems.....
> 
> 
> Oh, I can break anything.  Thanks for the help.
> 
> Michael
> 

Re: [Matlisp-users] Configuration failure on Linux/SBCL

[<dm...@ui...>]

Robbie Sedgewick <rd...@me...> writes:

> Hi,
>
> I did the port of matlisp to sbcl.

Thanks!

> Unfortunately, there were some problems with the patch (it got messed
> up by the sourceforge mailing list) so it wasn't completely applied to
> the cvs tree.  Parts of the patch were correctly applied, and others
> not.
>
> I have a copy of my sources up at
> http://mercury.chem.pitt.edu/~rds/matlisp.sbcl.tar.gz
>
> If you download these sources they should work out of the box. The
> only thing you might have to do is rebuild the configure script
> ("autoconf configure.in > configure").  After this the installation
> directions should work.

The command

    autoconf configure.in > configure

produced

    autoconf: Undefined macros:
    configure.in:259:AC_F77_FUNC(f77_name)

It's certainly possible this is a symptom of a broader configuration
problem, but I don't recall seeing any similar behavior in the past.

I then tried the existing configure script, but that led to

/----
| debugger invoked on a SB-FASL::INVALID-FASL-IMPLEMENTATION in thread 25305:
|   #<FILE-STREAM for "file \"/home/dmmcf/lisp/lib/matlisp.sbcl/packages.fasl\""
|     {98C8C69}> was compiled for implementation PPC, but this is a X86.
\----

which is hard to argue with. :-)

> Let me know if you have any problems.....

Oh, I can break anything.  Thanks for the help.

Michael

-- 
D. Michael McFarland
Department of Aerospace Engineering
University of Illinois at Urbana-Champaign
mailto:dm...@ui... https://netfiles.uiuc.edu/dmmcf/www/

Re: [Matlisp-users] Matlisp subset in pure CL

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

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

    Nicolas> Raymond Toy <to...@rt...> writes:
    Nicolas> 1. Use the CL-implemented version, if there is any, and if the matrices
    Nicolas> are small.
    >> 
    >> And the nice thing is we can even get rid of the call overhead if the
    >> function could be inlined.  That's a huge win for small
    >> matrices/vectors. 
    >> 
    >> Ray

    Nicolas> I have thought about this, but I am completely uncertain how to do such a
    Nicolas> thing in a well-behaved way within ANSI CL.  The best thing would probably
    Nicolas> be to pay Gerd Moellmann for implementing method inlining in CMUCL.  But

According to the CMUCL User's manual, Section 2.23.4 says that
effective methods can be inlined.  Perhaps that is good enough.

Ray

Re: [Matlisp-users] Matlisp subset in pure CL

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

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

>     simsek> Having said that, matlisp has evolved along the way, with contributions
>     simsek> from select individuals like yourself.  I think it may be time to
>     simsek> consider more drastic functionality of the kind you're suggesting.
> 
> I also think this is a good idea.  It would be nice if this approach
> could be made seamless with Matlisp, so the user wouldn't have to know
> unless he wanted to.  If it also means changing some Matlisp
> functions, that would also be ok.  We might want to ask other users
> about that, though. :-)
> 
> We probably also want to do an official 2.0 release before adding such
> features for the "3.0" release.
> 
>     simsek> I, unfortunately, personally would not be able to participate in the development
>     simsek> but I think there are people out there who might be.
> 
> I can help some, but I don't use matlisp that much anymore.
> 
> Ray

When my sparse matrix code works, and the BLAS code generation has evolved
to a satisfactory state, I'll come back on this...

Yours, Nicolas.

Re: [Matlisp-users] Matlisp subset in pure CL

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

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

>     Nicolas>   1. Use the CL-implemented version, if there is any, and if the matrices
>     Nicolas>      are small.
> 
> And the nice thing is we can even get rid of the call overhead if the
> function could be inlined.  That's a huge win for small
> matrices/vectors. 
> 
> Ray

I have thought about this, but I am completely uncertain how to do such a
thing in a well-behaved way within ANSI CL.  The best thing would probably
be to pay Gerd Moellmann for implementing method inlining in CMUCL.  But
for the moment, the call overhead on small matrices is not (any more) the
show-stopper for Femlisp.  At least, there are other bottlenecks which will
have to be optimized next.

Yours, Nicolas.

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

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


    Robbie> Unfortunately, there were some problems with the patch (it got messed
    Robbie> up by the sourceforge mailing list) so it wasn't completely applied to
    Robbie> the cvs tree.  Parts of the patch were correctly applied, and others
    Robbie> not.

I would appreciate it if you could redo the patch and send it again.
I'll make sure it gets applied.

Ray

Re: [Matlisp-users] Configuration failure on Linux/SBCL

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

Hi,

I did the port of matlisp to sbcl.

Unfortunately, there were some problems with the patch (it got messed up 
by the sourceforge mailing list) so it wasn't completely applied to the 
cvs tree.  Parts of the patch were correctly applied, and others not.

I have a copy of my sources up at 
http://mercury.chem.pitt.edu/~rds/matlisp.sbcl.tar.gz

If you download these sources they should work out of the box. The only 
thing you might have to do is rebuild the configure script ("autoconf 
configure.in > configure").  After this the installation directions 
should work.

There is also in there an .asd system definition file, so if you want to 
use asdf to load matlisp you can just run configure as you did before, 
symlink matlisp.asd to the right place, and "(require :matlisp)" and it 
should compile and load everything.

Let me know if you have any problems.....

--Robbie

D. Michael McFarland wrote:
> Hello,
> 
>     After a long period of little lisp activity, I've just downloaded
> the CVS version of matlisp via
> 
>     cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matlisp\
>         co matlisp
> 
> to try it with SBCL running on Gentoo Linux.  The INSTALL file begins
> 
> /----
> | Requirements:
> | =============
> | Either CMUCL (version 18b), SBCL (version 0.8.5) or 
> | Allegro CL (version 5.0 or later) is required.
> 
> No mention of SBCL there...
> 
> | * Allegro CL: Matlisp should compile on Linux, Solaris, Windows.
> |               In particular, Matlisp relies on the foreign
> |               function interface of Allegro CL.
> | 
> | * CMU CL: Matlisp should compile on Linux, Solaris.
> |           In particular, Matlisp relies on the foreign function
> |           interface of CMU CL and the built-in type 
> |           kernel::complex-double-float.
> | 
> | * SBCL: Matlisp should compile on Linux and MacOS X
> |         In particular, Matlisp relies on the foreign function
> |         interface of SBCL.
> \----
> 
> ...but that last paragraph is encouraging.  The detailed instructions
> include
> 
> /----
> | 4. Configure the system.
> |    o If you're using Allegro CL, specify --with-lisp=acl.
> |    o If you're using CMU CL, specify --with-lisp=cmucl
> |    o If you're using SBCL, specify --with-lisp=sbcl
> |    o Give the name of the Lisp executable via --with-lisp-exec=<name>
> |    o Run configure:
> | 
> |    ./configure --with-lisp=<lisp> --with-lisp-exec=<exec> --prefix=`pwd`
> \----
> 
> so I tried
> 
> # ./configure --with-lisp=sbcl --with-lisp-exec=/usr/bin/sbcl --prefix=`pwd`
> 
> only to be told
> 
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> configure: error: Unknown Lisp system:  sbcl.  Supported systems are acl and cmucl
> 
>     Now, I know one plays with CVS versions at his own risk, and I'm
> probably being dense to boot, but there's enough there to suggest
> matlisp ought to work with SBCL that I thought it might be worth a
> note.  Will someone please enlighten me about the status of SBCL
> compatibility, or point out where I've gone wrong in the ./configure
> line?  Thanks!
> 
> Michael
> 

[Matlisp-users] Configuration failure on Linux/SBCL

[<dm...@ui...>]

Hello,

    After a long period of little lisp activity, I've just downloaded
the CVS version of matlisp via

    cvs -z3 -d:pserver:ano...@cv...:/cvsroot/matlisp\
        co matlisp

to try it with SBCL running on Gentoo Linux.  The INSTALL file begins

/----
| Requirements:
| =============
| Either CMUCL (version 18b), SBCL (version 0.8.5) or 
| Allegro CL (version 5.0 or later) is required.

No mention of SBCL there...

| * Allegro CL: Matlisp should compile on Linux, Solaris, Windows.
|               In particular, Matlisp relies on the foreign
|               function interface of Allegro CL.
| 
| * CMU CL: Matlisp should compile on Linux, Solaris.
|           In particular, Matlisp relies on the foreign function
|           interface of CMU CL and the built-in type 
|           kernel::complex-double-float.
| 
| * SBCL: Matlisp should compile on Linux and MacOS X
|         In particular, Matlisp relies on the foreign function
|         interface of SBCL.
\----

...but that last paragraph is encouraging.  The detailed instructions
include

/----
| 4. Configure the system.
|    o If you're using Allegro CL, specify --with-lisp=acl.
|    o If you're using CMU CL, specify --with-lisp=cmucl
|    o If you're using SBCL, specify --with-lisp=sbcl
|    o Give the name of the Lisp executable via --with-lisp-exec=<name>
|    o Run configure:
| 
|    ./configure --with-lisp=<lisp> --with-lisp-exec=<exec> --prefix=`pwd`
\----

so I tried

# ./configure --with-lisp=sbcl --with-lisp-exec=/usr/bin/sbcl --prefix=`pwd`

only to be told

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
configure: error: Unknown Lisp system:  sbcl.  Supported systems are acl and cmucl

    Now, I know one plays with CVS versions at his own risk, and I'm
probably being dense to boot, but there's enough there to suggest
matlisp ought to work with SBCL that I thought it might be worth a
note.  Will someone please enlighten me about the status of SBCL
compatibility, or point out where I've gone wrong in the ./configure
line?  Thanks!

Michael

-- 
D. Michael McFarland
Department of Aerospace Engineering
University of Illinois at Urbana-Champaign
mailto:dm...@ui... https://netfiles.uiuc.edu/dmmcf/www/