Menu
▾
▴
matlisp-users
|
From: <si...@EE...> - 2004-05-26 00:33:43
|
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
>
|
|
From: <si...@EE...> - 2004-05-26 04:05:41
|
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 > |
|
From: Robert S. <rd...@me...> - 2004-05-26 04:48:39
|
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 > |
|
From: Marco A. <ma...@cs...> - 2004-05-26 13:20:44
|
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. |
|
From: Robbie S. <rd...@me...> - 2004-05-26 16:31:58
|
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 |
|
From: Raymond T. <to...@rt...> - 2004-05-26 17:32:18
|
>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:
Robbie> Either way, I think it would be nice to remove the matlisp's build
Robbie> dependence on make (to make libmatlisp.so) and replace it with a more
Robbie> sophisticated mk:defsystem or asdf system definition. But that is
Robbie> project for another day.
I had a defsystem definition that could compile all code in matlisp,
including the Fortran code. This was easy. The hard part is figuring
out the calling conventions and naming conventions of the Fortran
compiler, which is what configure is used for. (We don't currently
check the calling conventions, I think, but we should.)
Ray
|
|
From: Robbie S. <rd...@me...> - 2004-05-26 19:34:51
|
Raymond Toy wrote: >>>>>>"Robbie" == Robbie Sedgewick <rd...@me...> writes: > > > Robbie> Either way, I think it would be nice to remove the matlisp's build > Robbie> dependence on make (to make libmatlisp.so) and replace it with a more > Robbie> sophisticated mk:defsystem or asdf system definition. But that is > Robbie> project for another day. > > I had a defsystem definition that could compile all code in matlisp, > including the Fortran code. This was easy. The hard part is figuring > out the calling conventions and naming conventions of the Fortran > compiler, which is what configure is used for. (We don't currently > check the calling conventions, I think, but we should.) Yeah, I agree with what you are saying. As much as I don't like configure, there is really no other portable way to get that information. So we are stuck with configure, but is there any reason not to use your defsystem code to do the compiling of the fortran in matlisp by default? And remove the makefile from the picture? --Robbie |
|
From: Raymond T. <to...@rt...> - 2004-05-26 20:13:32
|
>>>>> "Robbie" == Robbie Sedgewick <rd...@me...> writes:
Robbie> Yeah, I agree with what you are saying. As much as I don't like
Robbie> configure, there is really no other portable way to get that
Robbie> information. So we are stuck with configure, but is there any reason
Robbie> not to use your defsystem code to do the compiling of the fortran in
Robbie> matlisp by default? And remove the makefile from the picture?
Look at blas.system and lapack.system. These will compile up the
Fortran code.
However, it's not really very well integrated at this point. Lisp
doesn't really know how to call the Fortran compiler with the right
arguments to compile the code to make a shared library. Configure
would need to pass that info on somehow.
This could be added, I suppose, but I don't really see much point
anymore. By the time you've done the work, you're 99 44/100% of the
way there for making make do it, so let make do it. :-)
Patches would probably be accepted, however. :-)
And since the Fortran code almost never changes, I compile it up once
and forget it. Then I just use xemacs + slime + mk:defsystem to
compile up the Lisp code, which changes a lot more often.
Ray
|
|
From: Robert S. <rd...@me...> - 2004-05-27 02:39:58
|
On May 26, 2004, at 4:09 PM, Raymond Toy wrote: > > > And since the Fortran code almost never changes, I compile it up once > and forget it. Then I just use xemacs + slime + mk:defsystem to > compile up the Lisp code, which changes a lot more often. yeah, this is a good point. I guess it matters a lot less here than in other projects where the c/fortran source is changing frequently..... --Robbie > Ray > |
|
From: Robert S. <rd...@me...> - 2004-05-26 02:52:47
|
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
|
|
From: Nicolas N. <Nic...@iw...> - 2004-05-26 09:50:54
|
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. |
|
From: Tunc S. <si...@EE...> - 2004-05-26 10:51:26
|
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 > |
|
From: Raymond T. <to...@rt...> - 2004-05-26 12:13:59
|
>>>>> "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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X