matlisp-users — General discussion list.

Re: [Matlisp-users] defsystem problems with matlisp

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

Hello Tunc,
hello everybody.

Sorry for not being responsive.

Anyway, I just moved to NYC and I am not all that settled in for the
time being.  I'll look in the problem and try to let you know what is
happening.

Cheers

PS. what files was I supposed to send you? config.guess and?  Sorry,
    but I am still suffering from readjustment shock. :)

-- 
Marco Antoniotti ===========================================

[Matlisp-users] defsystem problems with matlisp

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

This question should actually go out to the defsystem maintainers. 
Since the
current maintainer is on this list I'll post it here.

The defsystem form of matlisp is in the file start.lisp.  It turns out
that
the form is correct but defsystem does not work correctly.

Eg.
----
Suppose everything is built.  Touch the file src/fortran.lisp.  It has
dependencies
blas.lisp and lapack.list.  But when you do a *minimal load* with
operate-on-system
only fortran.lisp gets recompiled.  

Its been pointed out that most people use defsystem either at file level
or system level.
The dependencies here are at *module* level.  That may be the reason.

Anyway, defsystem people (Marco, that's you): help??

Thanks,
Tunc

Re: [Matlisp-users] Licensing and portability

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

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

Marco, please send me these files and I will use them.
I am attaching mine if you need them.

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

o.k., I suppose they read the c.l.l, so I'll post a question there,
otherwise, I could contact them directly.

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

This is fine. However, in reality, there is no difference between
putting
#+:cmu in the file or in system.dcl.  But, I understand that a good
directory structure is an integral part of a winning startegy.  Still,
I will refrain from doing this until serious work is done with
fortran.lisp.
I don't want to mess around with the CVS repository unless it is needed.

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

The reason I put defsystem in there is because it is practically
impossible
to find defsystem (unless you had told me to get it directly from CVS,
which
is not something I would have done on my own). 

My general take on external systems is to not put them in the
repository,
but to include them with each distribution.  This was you are
distributing something
that you know works when 'make' is executed, do you agree?


p.s. I may have a few things to contribute to defsystem, if you're
interested.
Thanks,
Tunc

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

[Matlisp-users] Licensing and portability

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

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

[Matlisp-users] Here we go....

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

Hello Tunc, hello everyboby

very nice job.

Just a few comments.

What is the license?  You have a GPL file in the top-level, but then
all (most) the files contain the BDS like license?

Could you make it consistently LGPL or BSD?

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?

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

[Matlisp-users] test, please disregard...

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

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

[Matlisp-users] [matlisp] test again

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

sorry, but testing again ...

[Matlisp-users] [matlisp] test message

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

This is a test, please ignore.

Tunc

[Matlisp-users] Testing matlisp

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

testing 1,2,3 ...

[Matlisp-users] [matlisp] Testing matlisp-users

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