matlisp-users — General discussion list.

[Matlisp-users] symbol conflicts

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

I'm trying to use the latest version of matlisp, downloaded from CVS
today, under CMUCL 18e.

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

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

Cheers,

rif

Re: [Matlisp-users] Re: Problems compiling latest CVS version

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

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

    Nicolas> wb...@gm... (Wolfhard Bu=DF) writes:
    >> Replacing the line
    >>=20
    >> (setf (find-class 'real) (find-class 'cl:real))
    >>=20
    >> in packages.lisp with:
    >>=20
    >> #+:cmu (setf (pcl:find-class 'real) (pcl:find-class 'cl:real))
    >> #+:allegro (setf (find-class 'real) (find-class 'cl:real))
    >>=20
    >> works for me.
    >>=20
    >> Cheers.

    Nicolas> Thanks, Wolfhard.

I've applied Wolfhard's fix so older versions of CMUCL will still
work.

    Nicolas> This more or less works.  But I get still a conflict for REAL =
when I want
    Nicolas> to use both COMMON-LISP and MATLISP in some package.  There sh=
ould be some
    Nicolas> cleaner remedy.

Shouldn't USE'ing MATLISP in some other package be enough since
MATLISP use's COMMON-LISP?  (I can never remember these package issues
because I don't do it very often.)

    Nicolas> I have no time for the next weeks to examine further.  Thus I =
went back to
    Nicolas> my stable environment with old CMUCL and old Matlisp.  But lat=
er this year,
    Nicolas> I will surely be interested in the new Matlisp.  I think that =
Ray's
    Nicolas> splitting of matrix-ref, for example, is in the right directio=
n for
    Nicolas> improving performance.

If you get a chance, I hope you'll try it again with current CMUCL and
current Matlisp.  I'd appreciate any feedback you might have.

Ray

[Matlisp-users] Re: Problems compiling Matlisp with new CMUCL

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

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

    Nicolas> Hello, Matlisp- and CMUCL-users.

[snip]

    Nicolas> (load "start.lisp")
    Nicolas> ; Loading #p"/home/neuss/CL-HOME/matlisp/start.lisp".
    Nicolas> ; Converted SETLOGICALROOT.
    Nicolas> ; Converted GETLOGICALROOT.
    Nicolas> ; Converted DEFLOGICALPATH.


    Nicolas> Error in function LISP::SUBSTITUTE-INTO:
    Nicolas>    Not enough wildcards in FROM pattern to match TO pattern:
    Nicolas>   #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
    Nicolas>    [Condition of type SIMPLE-ERROR]

I've fixed this in matlisp for now.

The problem is that cmucl gets confused when parsing namestrings with
wildcard versions:

(describe (pathname "/tmp/*.*.*")) =>
#p"/tmp/*.*.*" is a structure of type PATHNAME.
HOST: #<LISP::UNIX-HOST>.
DEVICE: NIL.
DIRECTORY: (:ABSOLUTE "tmp").
NAME: #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>.
TYPE: :WILD.
VERSION: NIL.

In 18e, this returned

#p"/tmp/*.*.~*~" is a structure of type PATHNAME.
HOST: #<COMMON-LISP::UNIX-HOST>.
DEVICE: NIL.
DIRECTORY: (:ABSOLUTE "tmp").
NAME: :WILD.
TYPE: :WILD.
VERSION: :WILD.

I think "/tmp/*.*.*" would be better written "/tmp/*.*.~*~"

Ray

Re: [Matlisp-users] Problems compiling latest CVS version

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

Sorry I didn't reply sooner, I was out of town.
I'm using CMUCL 18e.

rif

> >>>>> "rif" == rif  <ri...@MI...> writes:
> 
>     rif> I downloaded matlisp from CVS today.
>     rif> I configured with
> 
>     rif> ./configure --with-lisp=cmucl --with-lisp-exec=/home/rif/Software/CMUCL/bin/lisp --prefix=`pwd`
> 
> Which version of cmucl?
> 
> I'll try to look into this.  I have been hacking on matlisp a bit
> lately to see if I can get cmucl's PCL to generate better code.  I may
> have messed up something.
> 
> Ray

Re: [Matlisp-users] Re: Problems compiling latest CVS version

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

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

    Nicolas> wb...@gm... (Wolfhard Bu=DF) writes:
    >> Replacing the line
    >>=20
    >> (setf (find-class 'real) (find-class 'cl:real))
    >>=20
    >> in packages.lisp with:
    >>=20
    >> #+:cmu (setf (pcl:find-class 'real) (pcl:find-class 'cl:real))
    >> #+:allegro (setf (find-class 'real) (find-class 'cl:real))
    >>=20
    >> works for me.
    >>=20
    >> Cheers.

    Nicolas> Thanks, Wolfhard.

    Nicolas> This more or less works.  But I get still a conflict for REAL =
when I want
    Nicolas> to use both COMMON-LISP and MATLISP in some package.  There sh=
ould be some
    Nicolas> cleaner remedy.

First, I apologize for not having looked at this yet.  I'm pretty sure
I've run into this problem and have a fix, but have not checked that
in yet.

Probably won't get around to it until next week.

    Nicolas> I have no time for the next weeks to examine further.  Thus I =
went back to
    Nicolas> my stable environment with old CMUCL and old Matlisp.  But lat=
er this year,
    Nicolas> I will surely be interested in the new Matlisp.  I think that =
Ray's
    Nicolas> splitting of matrix-ref, for example, is in the right directio=
n for
    Nicolas> improving performance.

I was hoping Gerd's new stuff would make it faster, and some simple
tests with join (which uses matrix-ref) show that it is somewhat
faster.

Thanks for your patience,

Ray

[Matlisp-users] Re: Problems compiling latest CVS version

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

wb...@gm... (Wolfhard Bu=DF) writes:

> Replacing the line
>=20
>  (setf (find-class 'real) (find-class 'cl:real))
>=20
> in packages.lisp with:
>=20
>  #+:cmu (setf (pcl:find-class 'real) (pcl:find-class 'cl:real))
>  #+:allegro (setf (find-class 'real) (find-class 'cl:real))
>=20
> works for me.
>=20
> Cheers.

Thanks, Wolfhard.

This more or less works.  But I get still a conflict for REAL when I want
to use both COMMON-LISP and MATLISP in some package.  There should be some
cleaner remedy.

I have no time for the next weeks to examine further.  Thus I went back to
my stable environment with old CMUCL and old Matlisp.  But later this year,
I will surely be interested in the new Matlisp.  I think that Ray's
splitting of matrix-ref, for example, is in the right direction for
improving performance.

Nicolas.

P.S.: I dropped deflogicalpath in start.lisp in favor of

(setf (logical-pathname-translations "matlisp")
      `(("**;*.*.*" ,(concatenate 'string *cl-home* "matlisp/" "**/*.*.~*~"=
))))

Of course, a better fix should be found to make it work with new CMUCL.

Re: [Matlisp-users] Problems compiling latest CVS version

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

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

> Which version of cmucl?
> 
> I'll try to look into this.  I have been hacking on matlisp a bit lately
> to see if I can get cmucl's PCL to generate better code.  I may have
> messed up something.
> 
> Ray

The definition

(defmethod fill-matrix ((matrix real-matrix) (fill real))
  (copy! fill matrix))

does not work, because REAL is apparently shadowed somewhere:


;;; Describe real
REAL is an external symbol in the MATLISP package.
It names a class #<BUILT-IN-CLASS COMMON-LISP:REAL (sealed) {2806CA4D}>.
   #<BUILT-IN-CLASS COMMON-LISP:REAL (sealed) {2806CA4D}> is a structure of type BUILT-IN-CLASS.
   CLASS-INFO: #<TYPE-CLASS CLASS>.
   ENUMERABLE: NIL.
   NAME: COMMON-LISP:REAL.
   LAYOUT: #<Layout for COMMON-LISP:REAL {2806CA7D}>.
   STATE: :SEALED.
   DIRECT-SUPERCLASSES: (#<BUILT-IN-CLASS NUMBER (sealed) {280185CD}>).
   SUBCLASSES: #<EQ hash table, 8 entries {2806CAE5}>.
   PCL-CLASS: #<Built-In-Class COMMON-LISP:REAL {28202FE5}>.
   TRANSLATION: #<NUMERIC-TYPE COMMON-LISP:REAL>.
It names a PCL class #<Built-In-Class COMMON-LISP:REAL {28202FE5}>.
   #<Built-In-Class COMMON-LISP:REAL {28202FE5}> is a class, it is an instance
   of . (PCL:BUILT-IN-CLASS)
   Its proper name is COMMON-LISP:REAL.
   The direct superclasses are: (NUMBER), and the direct
   subclasses are: (FLOAT RATIONAL).  The class precedence list is:
   (COMMON-LISP:REAL NUMBER KERNEL::GENERIC-NUMBER T)
   There are 2 methods specialized for this class.
   Its direct slots are:


Using common-lisp:real would work.

Nicolas.

Re: [Matlisp-users] Problems compiling latest CVS version

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

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

    rif> I downloaded matlisp from CVS today.
    rif> I configured with

    rif> ./configure --with-lisp=cmucl --with-lisp-exec=/home/rif/Software/CMUCL/bin/lisp --prefix=`pwd`

Which version of cmucl?

I'll try to look into this.  I have been hacking on matlisp a bit
lately to see if I can get cmucl's PCL to generate better code.  I may
have messed up something.

Ray

[Matlisp-users] Problems compiling Matlisp with new CMUCL

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

Hello, Matlisp- and CMUCL-users.

I have recently updated to a new CMUCL version (not without problems as the
CMUCL users know).  Also Matlisp does not work out of the box (I have
finally succeeded in doing a CVS update for it [1]).

I have the following problems from the beginning:

---------------------------------------------------------------------------

(load "start.lisp")
; Loading #p"/home/neuss/CL-HOME/matlisp/start.lisp".
; Converted SETLOGICALROOT.
; Converted GETLOGICALROOT.
; Converted DEFLOGICALPATH.


Error in function LISP::SUBSTITUTE-INTO:
   Not enough wildcards in FROM pattern to match TO pattern:
  #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of "matlisp:system.dcl".
  1:            Return NIL from load of "start.lisp".
  2: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(LISP::SUBSTITUTE-INTO #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
                       NIL
                       T)
Source: 
; File: target:code/pathname.lisp

; File has been modified since compilation:
;   target:code/pathname.lisp
; Using form offset instead of character position.
(ERROR "Not enough wildcards in FROM pattern to match ~
		       TO pattern:~%  ~S"
       PATTERN)
0] l
LISP::DIDDLE-CASE  =  T
LISP::PATTERN  =  #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
LISP::SUBS  =  NIL

0] d
(LISP::TRANSLATE-COMPONENT "SYSTEM"
                              :WILD
                              #<LISP::PATTERN
                                :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
                              T)
1] l
LISP::DIDDLE-CASE  =  T
LISP::FROM  =  :WILD
LISP::SOURCE  =  "SYSTEM"
LISP::TO  =  #<LISP::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>

1] d
(TRANSLATE-PATHNAME #.(logical-pathname "MATLISP:SYSTEM.DCL")
                       #.(logical-pathname "MATLISP:**;*.*.*")
                       #p"/home/neuss/CL-HOME/matlisp/**/*.*.*")
2] 

---------------------------------------------------------------------------

Apparently something changed in CMUCL's handling of pathnames...

Nicolas.

[1] Sourceforge appears to be quite unreliable.  Would it be reasonable for
    Matlisp to switch to another server, e.g. savannah.gnu.org?  Or
    savannah.nongnu.org?

[Matlisp-users] Problems compiling latest CVS version

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

I downloaded matlisp from CVS today.
I configured with

./configure --with-lisp=cmucl --with-lisp-exec=/home/rif/Software/CMUCL/bin/lisp --prefix=`pwd`

and then tried a make, but I get the following error when CMUCL tries
to load matrix.x86f:

; /home/rif/Software/matlisp/bin/matrix.x86f written.
; Compilation finished in 0:00:01.
;; Loading #p"/home/rif/Software/matlisp/bin/matrix.x86f".


Error in function PCL::FIND-CLASS-FROM-CELL:  No class named: REAL.

Restarts:
  0: [CONTINUE] Return NIL from load of "/home/rif/Software/matlisp/bin/matrix.x86f".
  1:            Return NIL from load of "start.lisp".
  2: [ABORT   ] Skip remaining initializations.

Debug  (type H for help)

(PCL::FIND-CLASS-FROM-CELL REAL NIL T)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:  target:pcl/macros.lisp.
0]

Any suggestions?

Cheers,

rif

Re: [Matlisp-users] Matlisp on OS X

[Jeremy S. <sh...@op...>]

As another aside, I was an OS X fan myself, and used it extensively (did a
lot with Haskell FFI under OS X) for my research and private projects.  The
OS itself is beautiful (although the library system is a little
out-of-the-ordinary and I have no tolerance of Objective C).

DISCLAIMER:  My gripes relate to my experience with an Apple Laptop, which
got regular programmer wear-n-tear.  YMMV.

My problem came from the hardware, which you are stuck using if you like OS
X.  I had a laptop that went through two external power thingies, then the
DVD-ROM drive would not close.  It started becoming very frustrating when
the airport card (or antenna) worked "intermittently", and before I knew it,
the computer wouldn't even turn on.  The power button is basically useless,
no response at all from the machine.

The majority of this happened a few months after my initial AppleCare plan
was done and I don't feel like paying a sixth of the price of the laptop
(when new) again.  I don't know that my work won't be stranded on the drive
again, and that I won't be stopped for weeks while it's being fixed -- this
makes it effectively useless to me.

I paid the premium (and there is one, the laptop was slower than a
price-equivalent x86 in comparison, running the same matrix operations) for
OS X, and to ensure that the laptop's provider was AROUND when it came time
to fix it (as it's not peacemeal-fixable like a desktop).  If I had to do it
all over again, I'd revert to anything Turing-complete with a better
warranty and hardware track record.  OS X is beautiful, but the hardware,
not so much.

In short, I think that the adventurous will "switch", but unless your idea
of fun is porting packages and working 10 months out of 12 while it's being
AppleCared for, the eye candy and peace of mind that Apple will be around to
fix these prevalent problems just aren't worth it.  IMHO.

Jeremy



----- Original Message -----
From: <ju...@mi...>
To: "Raymond Toy" <to...@rt...>
Cc: <si...@EE...>; <mat...@li...>
Sent: Monday, April 21, 2003 4:59 PM
Subject: Re: [Matlisp-users] Matlisp on OS X


> Hi again
>
> Thanks to those who have taken the time to offer me some help. In reply to
> Raymond's email about checking the C compiler is working, I have been able
> to build a C helloworld app fine, and the binary produced using the "gcc
> -c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
> the name b.out is coming from.
>
> In reply to Tunc's email, I guess there are greater forces at play than my
> non-mainstream OS and lack of experience hacking it.
>
> I'd love to get Matlisp going on OS X if possible, and I'm more than
> willing to help out in any way I can, but I guess you guys have more
> experience getting Matlisp to play nice on UNIX.
>
> As an aside, I'm seeing more and more people 'switch' over to OS X (if
> you'll excuse the marketing victim speak), particularly for scientific
> work. I know two academic in my dept. who have moved from Linux to OS X,
> and several others who have fallen in love with Apple's line of laptops
> and are going to 'switch' when they next get a new computer. So, that
> being said, I'd encourage support of OS X by the OSS crowd as far as
> possible.
>
> Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
> so perhaps they might be a useful resource to tap into if there is
> significant work to be done to port Matlisp to OS X *and* you guys think
> this is worth doing.</my .10c>
>
> Thanks again
>
> Chris
>
>
> On 21 Apr 2003, Raymond Toy wrote:
>
> > >>>>> "Chris" == junk2  <ju...@mi...> writes:
> >
> >     Chris> So, again, b.out appears, although I can't actually see that
file on my
> >     Chris> system (nor the conftest.c file) -- perhaps these get cleaned
up in the
> >     Chris> ./configure... script?
> >
> > Yes, configure will clean it up.  Before we can make progress, we'll
> > have to solve this problem.  (I do have an iMac running OSX at home,
> > but don't have acl.)
> >
> > Try looking through the generated configure script.  Find the place
> > where conftest.c is created.  And try to compile that up by hand.
> >
> > Or you could just do a simple "Hello world!" program, and compile it
> > using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> > that b.out is ok.  Then try to run it.
> >
> >     Chris> One thing I have just remembered: When writing C++ code for
OS X, one has
> >     Chris> to explicitly link against libstdc++.a, which, as far as I
understand, is
> >     Chris> not the case on Linux, say. Could a similar problem be to
blame here?
> >
> > Matlisp doesn't use any C++ code.
> >
> > Ray
> >
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>
>

Re: [Matlisp-users] Matlisp on OS X

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

>>>>> "junk2" == junk2  <ju...@mi...> writes:

    Chris> Thanks to those who have taken the time to offer me some help. In reply to
    Chris> Raymond's email about checking the C compiler is working, I have been able
    Chris> to build a C helloworld app fine, and the binary produced using the "gcc
    Chris> -c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
    Chris> the name b.out is coming from.

I'll try to look at this soon on my OSX box at home.

    Chris> Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
    Chris> so perhaps they might be a useful resource to tap into if there is
    Chris> significant work to be done to port Matlisp to OS X *and* you guys think
    Chris> this is worth doing.</my .10c>

I think that will depend mostly on you. :-) I don't have ACL on OSX,
so I can't help there.  Perhaps an openmcl port would be useful, but
I'm not really motivated to do that because I don't use my slow OSX
box for any number crunching.

Ray

Re: [Matlisp-users] Matlisp on OS X

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

Hi again

Thanks to those who have taken the time to offer me some help. In reply to
Raymond's email about checking the C compiler is working, I have been able
to build a C helloworld app fine, and the binary produced using the "gcc
-c -O2 helloworld.c" syntax is called helloworld. So, I don't know where
the name b.out is coming from.

In reply to Tunc's email, I guess there are greater forces at play than my
non-mainstream OS and lack of experience hacking it.

I'd love to get Matlisp going on OS X if possible, and I'm more than
willing to help out in any way I can, but I guess you guys have more
experience getting Matlisp to play nice on UNIX.

As an aside, I'm seeing more and more people 'switch' over to OS X (if
you'll excuse the marketing victim speak), particularly for scientific
work. I know two academic in my dept. who have moved from Linux to OS X,
and several others who have fallen in love with Apple's line of laptops
and are going to 'switch' when they next get a new computer. So, that
being said, I'd encourage support of OS X by the OSS crowd as far as
possible.

Most people use fink (fink.sourceforge.net) to install UNIX apps for OS X,
so perhaps they might be a useful resource to tap into if there is
significant work to be done to port Matlisp to OS X *and* you guys think
this is worth doing.</my .10c>

Thanks again

Chris


On 21 Apr 2003, Raymond Toy wrote:

> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> So, again, b.out appears, although I can't actually see that file on my
>     Chris> system (nor the conftest.c file) -- perhaps these get cleaned up in the
>     Chris> ./configure... script?
>
> Yes, configure will clean it up.  Before we can make progress, we'll
> have to solve this problem.  (I do have an iMac running OSX at home,
> but don't have acl.)
>
> Try looking through the generated configure script.  Find the place
> where conftest.c is created.  And try to compile that up by hand.
>
> Or you could just do a simple "Hello world!" program, and compile it
> using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> that b.out is ok.  Then try to run it.
>
>     Chris> One thing I have just remembered: When writing C++ code for OS X, one has
>     Chris> to explicitly link against libstdc++.a, which, as far as I understand, is
>     Chris> not the case on Linux, say. Could a similar problem be to blame here?
>
> Matlisp doesn't use any C++ code.
>
> Ray
>

Re: [Matlisp-users] allegro heap size limit?

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

>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:

    Jefferson> However, I upgraded Matlisp at the same time that I upgraded Lisp, and
    Jefferson> now I'm running into a new problem.  Well into a several-hour run (but
    Jefferson> beyond the place it was crashing before) Lisp crashes with "corrupted
    Jefferson> internal data structures".  It gives me no debugging options other

Aargh!  We might be scribbling over some arrays; it's happened before.

Please keep us informed if you find anything.

Ray

Re: [Matlisp-users] allegro heap size limit?

[Jefferson P. <jp...@cs...>]

Raymond Toy wrote:
>>>>>>"Jefferson" == Jefferson Provost <jp...@cs...> writes:
>>>>>
> 
>     Jefferson> This is not strictly a MATLISP question, but I though people on this
>     Jefferson> list might have some experience with very large Lisp heaps.
> 
>     Jefferson> I'm using Allegro 6.0, on a P4 machine running RedHat with 1.5GB of
>     Jefferson> RAM and 3GB of swap.  I'm unable to get a heap-size larger than about
>     Jefferson> 500MB. As soon as an allocation attempts to grow the heap above that
>     Jefferson> level, I get something like this:
> 
> I don't know much about ACL.  Perhaps you can ask Franz to see what
> the maximum is or how to change the default?

Well, I upgraded to 6.1 and now I can get heaps bigger than 500MB.

However, I upgraded Matlisp at the same time that I upgraded Lisp, and 
now I'm running into a new problem.  Well into a several-hour run (but 
beyond the place it was crashing before) Lisp crashes with "corrupted 
internal data structures".  It gives me no debugging options other than 
dumping core, and then gives an illegal instruction when it tries to 
dump core.

The error message advises checking "foreign functions and code compiled 
with high speed or low safety".  The only such code in my program is in 
Matlisp.  I've copied a 6-month old Matlisp directory from another 
machine and rebuilt it for ACL 6.1, and I'm running using that.  We'll 
see if I still get the problem.

J.

Re: [Matlisp-users] Matlisp on OS X

[Tunc <si...@ee...>]

Hey folks;  the problems we're trying to solve might need some
deeper thought.  I took a moment to look at the Allegro docs
and here is some notes that raise concerns:

http://www.franz.com/support/documentation/6.1/doc/foreign-functions.htm#ff-
on-macosx-1

It says:
----------------------------------------------------------------------------
------------
Appendix I: Building shared libraries on MacOSX
On MacOSX, you must produce a specific type of .dylib file which can be
loaded into Allegro CL. These are called bundle files on MacOSX, and are
fully packaged shared libraries. Unfortunately, they may not be reused as
input to ld() once they have been created, in contrast with shared-objects
on other architectures. However, they may contain undefined symbols, which
may be resolved lazily when the shared-objects are loaded. These may include
symbols in libacl*.dylib such as lisp_value and lisp_call_address, without
having to link against the library. Compile with the -dynamic flag. As an
example:

% cc -dynamic -c foo.c -o foo.o
% ld -bundle /usr/lib/bundle1.o -undefined suppress -o foo.dylib foo.o
Fortran interfacing is not supported at this time.

The general issue of cross linking is discussed in Section 1.7.1 Linking to
Allegro CL shared library on MacOSX.

----------------------------------------------------------------------------
--------

Since I don't have much experience with MacOSX, I don't know whether this is
a show stopper.  Can someone comment??



Thanks, Tunc







----- Original Message -----
From: "Raymond Toy" <to...@rt...>
To: <ju...@mi...>
Cc: "si...@EE..." <si...@ee...>;
<mat...@li...>
Sent: Monday, April 21, 2003 8:31 AM
Subject: Re: [Matlisp-users] Matlisp on OS X


> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> So, again, b.out appears, although I can't actually see that
file on my
>     Chris> system (nor the conftest.c file) -- perhaps these get cleaned
up in the
>     Chris> ./configure... script?
>
> Yes, configure will clean it up.  Before we can make progress, we'll
> have to solve this problem.  (I do have an iMac running OSX at home,
> but don't have acl.)
>
> Try looking through the generated configure script.  Find the place
> where conftest.c is created.  And try to compile that up by hand.
>
> Or you could just do a simple "Hello world!" program, and compile it
> using "gcc -c -O2 hello.c" and see where the output goes.  It seems
> that b.out is ok.  Then try to run it.
>
>     Chris> One thing I have just remembered: When writing C++ code for OS
X, one has
>     Chris> to explicitly link against libstdc++.a, which, as far as I
understand, is
>     Chris> not the case on Linux, say. Could a similar problem be to blame
here?
>
> Matlisp doesn't use any C++ code.
>
> Ray
>

Re: [Matlisp-users] Matlisp on OS X

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

>>>>> "Chris" == junk2  <ju...@mi...> writes:

    Chris> So, again, b.out appears, although I can't actually see that file on my
    Chris> system (nor the conftest.c file) -- perhaps these get cleaned up in the
    Chris> ./configure... script?

Yes, configure will clean it up.  Before we can make progress, we'll
have to solve this problem.  (I do have an iMac running OSX at home,
but don't have acl.)

Try looking through the generated configure script.  Find the place
where conftest.c is created.  And try to compile that up by hand.  

Or you could just do a simple "Hello world!" program, and compile it
using "gcc -c -O2 hello.c" and see where the output goes.  It seems
that b.out is ok.  Then try to run it.

    Chris> One thing I have just remembered: When writing C++ code for OS X, one has
    Chris> to explicitly link against libstdc++.a, which, as far as I understand, is
    Chris> not the case on Linux, say. Could a similar problem be to blame here?

Matlisp doesn't use any C++ code.

Ray

Re: [Matlisp-users] Matlisp on OS X

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

Hi again

OK, given you're not using aclocal or automake, I've checked a fresh copy
out of CVS. I have make links to Apple's versions of the config.guess and
config.sub files. I ran autoconf. I then ran the

./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/

Command, which gave me pretty much the same output as before:

alisp --prefix=/Users/chris/Desktop/Matlisp/matlisp/
checking build system type... powerpc-apple-darwin6.5
checking host system type... powerpc-apple-darwin6.5
checking target system type... powerpc-apple-darwin6.5
checking for ranlib... ranlib
checking for gcc... gcc
checking for C compiler default output... b.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

So, again, b.out appears, although I can't actually see that file on my
system (nor the conftest.c file) -- perhaps these get cleaned up in the
./configure... script?

One thing I have just remembered: When writing C++ code for OS X, one has
to explicitly link against libstdc++.a, which, as far as I understand, is
not the case on Linux, say. Could a similar problem be to blame here?

I have included config.log below, in case that casts more light on the
problem.

Thanks again.

Chris

-- Contents of config.log --

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.57.  Invocation command line was

  $ ./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/

## --------- ##
## Platform. ##
## --------- ##

hostname = Totty.local.
uname -m = Power Macintosh
uname -r = 6.5
uname -s = Darwin
uname -v = Darwin Kernel Version 6.5: Mon Apr  7 17:05:38 PDT 2003;
root:xnu/xnu-344.32.obj~1/RELEASE_PPC

/usr/bin/uname -p = powerpc
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
hostinfo               = Mach kernel version:
	 Darwin Kernel Version 6.5:
Mon Apr  7 17:05:38 PDT 2003; root:xnu/xnu-344.32.obj~1/RELEASE_PPC


Kernel configured for up to 2 processors.
1 processor is physically available.
Processor type: ppc750 (PowerPC 750)
Processor active: 0
Primary memory available: 256.00 megabytes.
Default processor set: 53 tasks, 148 threads, 1 processors
Load average: 2.33, Mach factor: 0.30
unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1269: checking build system type
configure:1287: result: powerpc-apple-darwin6.5
configure:1295: checking host system type
configure:1309: result: powerpc-apple-darwin6.5
configure:1317: checking target system type
configure:1331: result: powerpc-apple-darwin6.5
configure:1452: checking for ranlib
configure:1468: found /usr/bin/ranlib
configure:1479: result: ranlib
configure:1538: checking for gcc
configure:1564: result: gcc
configure:1808: checking for C compiler version
configure:1811: gcc --version </dev/null >&5
gcc (GCC) 3.1 20020420 (prerelease)
Copyright (C) 2002 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.

configure:1814: $? = 0
configure:1816: gcc -v </dev/null >&5
Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
(prerelease)
configure:1819: $? = 0
configure:1821: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1824: $? = 1
configure:1848: checking for C compiler default output
configure:1851: gcc -c -O2   conftest.c  >&5
configure:1854: $? = 0
configure:1900: result: b.out
configure:1905: checking whether the C compiler works
configure:1911: ./b.out
./configure: ./b.out: No such file or directory
configure:1914: $? = 127
configure:1923: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=powerpc-apple-darwin6.5
ac_cv_build_alias=powerpc-apple-darwin6.5
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-c -O2'
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_F77_set=set
ac_cv_env_F77_value=/sw/bin/g77
ac_cv_env_FFLAGS_set=
ac_cv_env_FFLAGS_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=
ac_cv_host=powerpc-apple-darwin6.5
ac_cv_host_alias=powerpc-apple-darwin6.5
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_ac_ct_RANLIB=ranlib
ac_cv_target=powerpc-apple-darwin6.5
ac_cv_target_alias=powerpc-apple-darwin6.5

## ----------------- ##
## Output variables. ##
## ----------------- ##

ATLAS_DIR=''
ATLAS_LIBS=''
BLAS_OBJS='dgemm.o dswap.o dtrmv.o lsame.o zdotu.o zhemv.o ztrmv.o dgemv.o
dsymv.o  dtrsm.o  zher2.o   ztrsm.o dasum.o  dger.o   dsyr.o   dtrsv.o
zdscal.o zher2k.o ztrsv.o daxpy.o  dsyr2.o  dzasum.o xerbla.o  zgemm.o
zherk.o dcabs1.o dnrm2.o  dsyr2k.o dznrm2.o  zaxpy.o  zgemv.o  zscal.o
dcopy.o  drot.o   dsyrk.o  idamax.o  zcopy.o  zgerc.o  zswap.o ddot.o
dscal.o  dtrmm.o  izamax.o  zdotc.o  zgeru.o  ztrmm.o dsymm.o'
CC='gcc'
CFLAGS='-c -O2'
CLIBS=''
CPPFLAGS=''
DEFS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EXEEXT=''
F77='/sw/bin/g77'
F77_EXTRA_UNDERSCORE=''
F77_LOWER_CASE=''
F77_UNDERSCORE=''
FFLAGS=''
FLIBS=''
LD=''
LDFLAGS=''
LIBOBJS=''
LIBS=''
LISPEVAL='-e'
LISPEXEC='alisp'
LTLIBOBJS=''
NO_ATLAS_LAPACK_OBJS='dgetrf.o zgetrf.o dgetrs.o zgetrs.o dlaswp.o
zlaswp.o dgesv.o zgesv.o'
OBJEXT=''
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PATH_SEPARATOR=':'
RANLIB='ranlib'
SHARED_LIB_LDFLAGS=''
SHELL='/bin/sh'
ac_ct_CC='gcc'
ac_ct_F77=''
ac_ct_RANLIB='ranlib'
bindir='${exec_prefix}/bin'
build='powerpc-apple-darwin6.5'
build_alias=''
build_cpu='powerpc'
build_os='darwin6.5'
build_vendor='apple'
datadir='${prefix}/share'
exec_prefix='NONE'
host='powerpc-apple-darwin6.5'
host_alias=''
host_cpu='powerpc'
host_os='darwin6.5'
host_vendor='apple'
includedir='${prefix}/include'
infodir='${prefix}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localstatedir='${prefix}/var'
mandir='${prefix}/man'
oldincludedir='/usr/include'
prefix='/Users/chris/Desktop/Matlisp/matlisp/'
program_transform_name='s,x,x,'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
srcdir='.'
sysconfdir='${prefix}/etc'
target='powerpc-apple-darwin6.5'
target_alias=''
target_cpu='powerpc'
target_os='darwin6.5'
target_vendor='apple'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""

configure: exit 1



On 21 Apr 2003, Raymond Toy wrote:

> >>>>> "Chris" == junk2  <ju...@mi...> writes:
>
>     Chris> 1. I was using one of the Matlisp releases. I've now checked the latest
>     Chris> version of Matlisp out of CVS.
>
> Good.
>
>     Chris> 2. One of the problems I found was regarding the config.sub and
>     Chris> config.guess files. Apple provides version of these files so porting is
>     Chris> easier (see:
>     Chris> developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
>     Chris> So I did:
>
> I'll take a look at this and see if we can use these instead for the
> other supported platforms.
>
>     Chris> 3. Trying to do the aclocal, autoconf, automake sequence, I got complains
>     Chris> about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
>     Chris> ./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++
>
> We don't use aclocal or automake.  Running autoconf should be enough.
> I don't know what will happen if you run aclocal and automake.
>
>     Chris> [snip]
>     Chris> Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
>     Chris> (prerel
>     Chris> ease)
>     Chris> configure:1819: $? = 0
>     Chris> configure:1821: gcc -V </dev/null >&5
>     Chris> gcc: argument to `-V' is missing
>     Chris> configure:1824: $? = 1
>     Chris> configure:1848: checking for C compiler default output
>     Chris> configure:1851: gcc -c -O2   conftest.c  >&5
>     Chris> configure:1854: $? = 0
>     Chris> configure:1900: result: b.out
>     Chris> configure:1905: checking whether the C compiler works
>     Chris> configure:1911: ./b.out
>     Chris> ./configure: ./b.out: No such file or directory
>
> Can you figure this out?  Does the compiler really put the executable
> in b.out instead of a.out?
>
> Ray
>

Re: [Matlisp-users] Matlisp on OS X

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

>>>>> "Chris" == junk2  <ju...@mi...> writes:

    Chris> 1. I was using one of the Matlisp releases. I've now checked the latest
    Chris> version of Matlisp out of CVS.

Good.

    Chris> 2. One of the problems I found was regarding the config.sub and
    Chris> config.guess files. Apple provides version of these files so porting is
    Chris> easier (see:
    Chris> developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
    Chris> So I did:

I'll take a look at this and see if we can use these instead for the
other supported platforms.

    Chris> 3. Trying to do the aclocal, autoconf, automake sequence, I got complains
    Chris> about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
    Chris> ./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++

We don't use aclocal or automake.  Running autoconf should be enough.
I don't know what will happen if you run aclocal and automake.

    Chris> [snip]
    Chris> Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
    Chris> (prerel
    Chris> ease)
    Chris> configure:1819: $? = 0
    Chris> configure:1821: gcc -V </dev/null >&5
    Chris> gcc: argument to `-V' is missing
    Chris> configure:1824: $? = 1
    Chris> configure:1848: checking for C compiler default output
    Chris> configure:1851: gcc -c -O2   conftest.c  >&5
    Chris> configure:1854: $? = 0
    Chris> configure:1900: result: b.out
    Chris> configure:1905: checking whether the C compiler works
    Chris> configure:1911: ./b.out
    Chris> ./configure: ./b.out: No such file or directory

Can you figure this out?  Does the compiler really put the executable
in b.out instead of a.out?

Ray

Re: [Matlisp-users] allegro heap size limit?

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

>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes:

    Jefferson> This is not strictly a MATLISP question, but I though people on this
    Jefferson> list might have some experience with very large Lisp heaps.

    Jefferson> I'm using Allegro 6.0, on a P4 machine running RedHat with 1.5GB of
    Jefferson> RAM and 3GB of swap.  I'm unable to get a heap-size larger than about
    Jefferson> 500MB. As soon as an allocation attempts to grow the heap above that
    Jefferson> level, I get something like this:

I don't know much about ACL.  Perhaps you can ask Franz to see what
the maximum is or how to change the default?

Ray

Re: [Matlisp-users] Matlisp on OS X

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

Hi again

Thanks for the help. I'm relatively new to UNIX and OS X, so I'd be
grateful for you help *and* patience... :-)

On the makefile front, I am using GNU Make version 3.79 -- I'm not aware
that there are any major differences between this and its Linux/Solaris
counterparts.

If I manage to get Matlisp going on OS X I plan to put together a howto
document. I have made some progress, and I think I've narrowed the problem
down substantially.

1. I was using one of the Matlisp releases. I've now checked the latest
version of Matlisp out of CVS.

2. One of the problems I found was regarding the config.sub and
config.guess files. Apple provides version of these files so porting is
easier (see:
developer.apple.com/techpubs/macosx/Darwin/GettingStarted/PortingUNIX/compiling/chapter_3_section_8.html).
So I did:

mv config.guess config.guess.dist
mv config.sub config.sub.dist
ln -s /usr/share/automake-1.6/config.guess .
ln -s /usr/share/automake-1.6/config.sub .

3. Trying to do the aclocal, autoconf, automake sequence, I got complains
about missing AM_INIT_AUTOMAKE, ./aclocal.m4, ./mkinstalldirs and
./missing. I copied aclocal.m4, mkinstalldirs and missing from a C++
project I had. I guess this is a dodgy step -- I think aclocal.m4 needs to
be generated by doing aclocal (but when I tried that, no aclocal.m4 is
created). Copying in the files missing and mkinstalldirs seemed to placate
autoconf on errors regarding those files, but it complains that "your
implementation of AM_INIT_AUTOMAKE comes from an automake: old Automake
version.  You should recreate aclocal.m4 automake: with aclocal and run
automake again."

4. Doing ./configure --with-lisp=acl --with-lisp-exec=alisp
--prefix=/Users/chris/Desktop/Matlisp/matlisp/ yields the following
problem:

[snip]
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

5. Looking is config.log:

[snip]
Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420
(prerel
ease)
configure:1819: $? = 0
configure:1821: gcc -V </dev/null >&5
gcc: argument to `-V' is missing
configure:1824: $? = 1
configure:1848: checking for C compiler default output
configure:1851: gcc -c -O2   conftest.c  >&5
configure:1854: $? = 0
configure:1900: result: b.out
configure:1905: checking whether the C compiler works
configure:1911: ./b.out
./configure: ./b.out: No such file or directory
configure:1914: $? = 127
configure:1923: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

6. A web search suggested the following potential causes:
a) Using a different compiler than the one used to build Matlisp on the
developer's workstations.
b) LD_LIBRARY_PATH set to something that doesn't work with the default
compiler.
c) If configure was created with the wrong version of autoconf.

I'm using the gcc toolchain, so I guess I'm OK on point a). I don't have
LD_LIBRARY_PATH set in my environment -- perhaps it's set in Matlisp's
build system? I'm not sure about point c) -- Apple install Automake 1.6,
but I've had to upgrate to 1.7 for another project, so there's a potential
conflict between the config.guess and config.sub files brought into the
Matlisp dir from Automake 1.7 and me using the tools from Automake 1.7.

As I said, I'm very appreciative of your help on this matter.

Chris


On Sun, 20 Apr 2003, si...@EE... wrote:

> This looks like a makefile problem.  Although once that is
> fixed I'm sure others will follow.
>
> These two lines in matlisp.mk tell 'make' that dgemm.o should
> be build from dgemm.f or dgemm.c (whichever one it finds)
> Perhaps the make on OS X doesn't understand this.
>
> But before that.  Did you download the released tar'd file or
> did you get the files from the CVS repository.  You should
> get the latter since the released file is way too old and won't
> work with your version of Allegro.
>
>   --Tunc
>
> ----- Original Message -----
> From: ju...@mi...
> Date: Saturday, April 19, 2003 3:06 pm
> Subject: [Matlisp-users] Matlisp on OS X
>
> > Hi all
> >
> > I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> >
> > I installed g77 via fink and set F77 to /sw/bin/g77
> >
> > Ihave installed ATLAS using fink and run:
> >
> > ./configure FreeBSD
> >
> > (as was suggested at
> > http://mail.gnu.org/archive/html/gcl-devel/2002-07/msg00029.html),
> > whichyields output 1 (see below). All seems OK at this point to my
> > untrainedeye.
> >
> > I then do
> >
> > make allegro
> >
> > which fails pretty quickly with output 2 (see below)
> >
> > Has anyone got Matlisp going on OS X? OS X is just UNIX; give that
> > Matlispexists for Linux, it should also be OK with OS X???
> >
> > Your help would be very much appreciated!!!!
> >
> > Chris
> >
> > Output 1 (listing of the configure step):
> >
> > ./configure FreeBSD
> > configure: warning: FreeBSD: invalid host type
> > loading cache ./config.cache
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) works... yes
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> > cross-compiler... no
> > checking whether we are using GNU Fortran 77... (cached) yes
> > checking whether /sw/bin/g77 accepts -g... (cached) yes
> > checking for ranlib... (cached) ranlib
> > checking host system type... Invalid configuration `FreeBSD': machine
> > `FreeBSD' not recognized
> >
> > checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> > lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> > -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc  ) works... yes
> > checking whether the C compiler (gcc  ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > configure: warning: Oops! Matlisp is tested on Solaris, SunOS or Linux
> > configure: warning: Matlisp may not compile on your system .
> > creating ./config.status
> > creating matlisp.mk
> > creating lib/lazy-loader.lisp
> >
> > Output 2 (listing of the make step):
> >
> > make allegro
> > make -f matlisp.mk shared
> > make[1]: *** No rule to make target
> > `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> > make: *** [lib/libmatlispshared.so] Error 2
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> >
>
>

Re: [Matlisp-users] Matlisp on OS X

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

These two lines:

.f.o:
	$(F77) $(FFLAGS) -o $@ -c $<

.c.o:
	$(CC) $(CFLAGS) -o $@ -c $<


----- Original Message -----
From: si...@ee...
Date: Sunday, April 20, 2003 11:50 pm
Subject: Re: [Matlisp-users] Matlisp on OS X

> This looks like a makefile problem.  Although once that is
> fixed I'm sure others will follow.
> 
> These two lines in matlisp.mk tell 'make' that dgemm.o should
> be build from dgemm.f or dgemm.c (whichever one it finds)
> Perhaps the make on OS X doesn't understand this.
> 
> But before that.  Did you download the released tar'd file or 
> did you get the files from the CVS repository.  You should
> get the latter since the released file is way too old and won't
> work with your version of Allegro.
> 
>  --Tunc
> 
> ----- Original Message -----
> From: ju...@mi...
> Date: Saturday, April 19, 2003 3:06 pm
> Subject: [Matlisp-users] Matlisp on OS X
> 
> > Hi all
> > 
> > I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> > 
> > I installed g77 via fink and set F77 to /sw/bin/g77
> > 
> > Ihave installed ATLAS using fink and run:
> > 
> > ./configure FreeBSD
> > 
> > (as was suggested at
> > http://mail.gnu.org/archive/html/gcl-devel/2002-
> 07/msg00029.html), 
> > whichyields output 1 (see below). All seems OK at this point to 
> my 
> > untrainedeye.
> > 
> > I then do
> > 
> > make allegro
> > 
> > which fails pretty quickly with output 2 (see below)
> > 
> > Has anyone got Matlisp going on OS X? OS X is just UNIX; give 
> that 
> > Matlispexists for Linux, it should also be OK with OS X???
> > 
> > Your help would be very much appreciated!!!!
> > 
> > Chris
> > 
> > Output 1 (listing of the configure step):
> > 
> > ./configure FreeBSD
> > configure: warning: FreeBSD: invalid host type
> > loading cache ./config.cache
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) 
> works... yes
> > checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> > cross-compiler... no
> > checking whether we are using GNU Fortran 77... (cached) yes
> > checking whether /sw/bin/g77 accepts -g... (cached) yes
> > checking for ranlib... (cached) ranlib
> > checking host system type... Invalid configuration `FreeBSD': 
> machine> `FreeBSD' not recognized
> > 
> > checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> > lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> > -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> > checking for gcc... (cached) gcc
> > checking whether the C compiler (gcc  ) works... yes
> > checking whether the C compiler (gcc  ) is a cross-compiler... no
> > checking whether we are using GNU C... (cached) yes
> > checking whether gcc accepts -g... (cached) yes
> > configure: warning: Oops! Matlisp is tested on Solaris, SunOS or 
> Linux> configure: warning: Matlisp may not compile on your system .
> > creating ./config.status
> > creating matlisp.mk
> > creating lib/lazy-loader.lisp
> > 
> > Output 2 (listing of the make step):
> > 
> > make allegro
> > make -f matlisp.mk shared
> > make[1]: *** No rule to make target 
> > `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> > make: *** [lib/libmatlispshared.so] Error 2
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Matlisp-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matlisp-users
> > 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

Re: [Matlisp-users] Matlisp on OS X

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

This looks like a makefile problem.  Although once that is
fixed I'm sure others will follow.

These two lines in matlisp.mk tell 'make' that dgemm.o should
be build from dgemm.f or dgemm.c (whichever one it finds)
Perhaps the make on OS X doesn't understand this.

But before that.  Did you download the released tar'd file or 
did you get the files from the CVS repository.  You should
get the latter since the released file is way too old and won't
work with your version of Allegro.

  --Tunc

----- Original Message -----
From: ju...@mi...
Date: Saturday, April 19, 2003 3:06 pm
Subject: [Matlisp-users] Matlisp on OS X

> Hi all
> 
> I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.
> 
> I installed g77 via fink and set F77 to /sw/bin/g77
> 
> Ihave installed ATLAS using fink and run:
> 
> ./configure FreeBSD
> 
> (as was suggested at
> http://mail.gnu.org/archive/html/gcl-devel/2002-07/msg00029.html), 
> whichyields output 1 (see below). All seems OK at this point to my 
> untrainedeye.
> 
> I then do
> 
> make allegro
> 
> which fails pretty quickly with output 2 (see below)
> 
> Has anyone got Matlisp going on OS X? OS X is just UNIX; give that 
> Matlispexists for Linux, it should also be OK with OS X???
> 
> Your help would be very much appreciated!!!!
> 
> Chris
> 
> Output 1 (listing of the configure step):
> 
> ./configure FreeBSD
> configure: warning: FreeBSD: invalid host type
> loading cache ./config.cache
> checking whether the Fortran 77 compiler (/sw/bin/g77  ) works... yes
> checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
> cross-compiler... no
> checking whether we are using GNU Fortran 77... (cached) yes
> checking whether /sw/bin/g77 accepts -g... (cached) yes
> checking for ranlib... (cached) ranlib
> checking host system type... Invalid configuration `FreeBSD': machine
> `FreeBSD' not recognized
> 
> checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -
> lcrt1.o-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
> -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
> checking for gcc... (cached) gcc
> checking whether the C compiler (gcc  ) works... yes
> checking whether the C compiler (gcc  ) is a cross-compiler... no
> checking whether we are using GNU C... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> configure: warning: Oops! Matlisp is tested on Solaris, SunOS or Linux
> configure: warning: Matlisp may not compile on your system .
> creating ./config.status
> creating matlisp.mk
> creating lib/lazy-loader.lisp
> 
> Output 2 (listing of the make step):
> 
> make allegro
> make -f matlisp.mk shared
> make[1]: *** No rule to make target 
> `/usr/local/LAPACK/BLAS/SRC/dgemm.o',needed by `shared'.  Stop.
> make: *** [lib/libmatlispshared.so] Error 2
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
> 

[Matlisp-users] Matlisp on OS X

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

Hi all

I'm trying to get Matlisp going on OS X 10.2.5 under Allegro CL.

I installed g77 via fink and set F77 to /sw/bin/g77

Ihave installed ATLAS using fink and run:

./configure FreeBSD

(as was suggested at
http://mail.gnu.org/archive/html/gcl-devel/2002-07/msg00029.html), which
yields output 1 (see below). All seems OK at this point to my untrained
eye.

I then do

make allegro

which fails pretty quickly with output 2 (see below)

Has anyone got Matlisp going on OS X? OS X is just UNIX; give that Matlisp
exists for Linux, it should also be OK with OS X???

Your help would be very much appreciated!!!!

Chris

Output 1 (listing of the configure step):

./configure FreeBSD
configure: warning: FreeBSD: invalid host type
loading cache ./config.cache
checking whether the Fortran 77 compiler (/sw/bin/g77  ) works... yes
checking whether the Fortran 77 compiler (/sw/bin/g77  ) is a
cross-compiler... no
checking whether we are using GNU Fortran 77... (cached) yes
checking whether /sw/bin/g77 accepts -g... (cached) yes
checking for ranlib... (cached) ranlib
checking host system type... Invalid configuration `FreeBSD': machine
`FreeBSD' not recognized

checking for Fortran 77 libraries... (cached)  -lfrtbegin -lg2c -lcrt1.o
-lcrtbegin.o -L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1
-L/sw/lib/gcc-lib/powerpc-apple-darwin6.2/3.1/../../.. -lSystem
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
configure: warning: Oops! Matlisp is tested on Solaris, SunOS or Linux
configure: warning: Matlisp may not compile on your system .
creating ./config.status
creating matlisp.mk
creating lib/lazy-loader.lisp

Output 2 (listing of the make step):

make allegro
make -f matlisp.mk shared
make[1]: *** No rule to make target `/usr/local/LAPACK/BLAS/SRC/dgemm.o',
needed by `shared'.  Stop.
make: *** [lib/libmatlispshared.so] Error 2

[Matlisp-users] Broken download link

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

Hi

Just to report that there is a broken link on the page at
(http://matlisp.sourceforge.net/): Under the heading "How easy is it to
install Matlisp?" in point 1, the "here" link is broken (one can follow
the link, but it does not take you to the downlaod area).

The link on the side menu is functional, however.

Chris