From: Tunc S. <si...@ro...> - 2000-04-19 19:43:45
|
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 > 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. > 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). Tunc |