Re: [Matlisp-users] Licensing and portability

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

> Delivery-Date: Wed, 19 Apr 2000 21:38:24 +0200 Date: Wed, 19 Apr
> 2000 12:36:12 -0700 From: Tunc Simsek
> <si...@ro...> Reply-To:
> si...@ro... Organization: UC Berkeley
> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii
> Sender: mat...@li... X-Mailman-Version:
> 1.1 Precedence: bulk List-Id: Matlisp users mailing
> list. <matlisp-users.lists.sourceforge.net> X-BeenThere:
> mat...@li...
> 
> Hi Marco,
> 
> Sorry for the late reply but I don't seem to get messages from
> matlisp-users although I am subscribed. I'll try to fix this.
> 
> > What is the license?  You have a GPL file in the top-level, but
> > then all (most) the files contain the BDS like license?
> 
> The license is UC Berkeley.  The gpl file on the top-level is to
> satisfy the demand of the headers in config.guess and congif.sub

Why is that?  I have a 'config.guess' and a 'config.sub' which do not
require this.  Do you want them?

> > Could you make it consistently LGPL or BSD?
> 
> Perhaps.  But why, do you think LGPL works well with CL code.  It
> sort of inhibits all successors of the code (even if they only use
> it) and discourages development.

I have no preference.  LGPL is better than GPL for CL code.  I just
think that the gpl.txt file at the top level is misleading if you just
plan to use a BSD license.

> > Also, what would it take to make it work under a different CL
> > system?  Are all the CL implementation dependecies in the
> > fortran.lisp file?
> 
> It should be easy to make it work with Allegro (which I've looked
> into) but did not pursue, since Allegro is not a free
> implementation.  It will work immediately with CLISP as soon as
> CLISP has arrays specialized to DOUBLE-FLOAT with the specialization
> having a contiguous allocation of DOUBLE-FLOAT's the same size as a
> C double (I have some ideas on checking these sizes with configure
> and writing fortran.lisp automatically).
> 
> All dependecies were tried to put in fortran.lisp but this is only
> partially true.  This is true if the lisp has arrays specialized to
> double-floats.  I think, it is possible to avoid this dependency (at
> least conceptually by naming functions differently) but I'd rather
> wait to do this to see if there is some serious interest in matlisp.
> 
> As an example, look at src/copy.lisp and see the use of a global
> specialized 1 element double-float array.  This should also be
> defined in fortran.lisp.  But that is about all there is to
> non-portability issues.
> 
> Otherwise, the setup (IMO) is pretty compact and seems to work well
> under CMUCL (solaris,linux).

Understood.  A few comments.

Have you talked to Bruno Haible and Sam Steingold about CLisp and the
double-float specialized arrays?  I am sure they'd be glad to help.

May I suggest to put fortran.lisp in a separate, per implementation
directory?  I.e. having something like

	    src/impl-dependent/
		               cmucl/fortran.lisp
		               allegro/fortran.lisp
			       ...
		               clisp/fortran.lisp

Then you could conditionalize the DEFSYSTEM forms instead of filling
the fortran.lisp file with a bunch of conditionals.

Please remove defsystem.lisp from your distribution.  The DEFSYSTEM in
the CLOCC is being constantly updated and yours may fall behind.  This
would lead to a separate "matlisp version" of DEFSYSTEM.  You can see
the problems here.

Cheers

-- 
Marco Antoniotti =========================================== PARADES,
Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17,
fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa