axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] CCL maintenance.


From: Stephen Wilson
Subject: Re: [Axiom-developer] CCL maintenance.
Date: 30 May 2007 12:47:55 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

"Bill Page" <address@hidden> writes:

> On May 30, 2007 11:38 AM Stephen Wilson
> > 
> > Waldek Hebisch <address@hidden> writes:
> > > Stephen Wilson wrote:
> > > > Are any of the current maintainers working with CCL at all?
> > > > Is maintaining compatability with this Lisp of importance to
> > > > anyone?
> > > > 
> > > 
> > > I checked that CCL from Nag Cdrom builds OK.  ATM I do not intend
> > > to do any serious work on CCL, but I intend to check if current
> > > Axiom is still compatible with CCL.
> 
> As part of the open source release NAG (Mike Dewar) claimed that
> they had delivered Axiom to Tim Daly in a form that would compile
> using CCL on Linux. I have never tested this and I think it would
> be good to know since it at least gives us a standard benchmark
> for comparison.

I assume you mean comparison against other Lisp hosts?   Im curious
about the benefit in that.  

It would be one thing if Axiom was targeting one Lisp implementation
in an attempt to exploit all of the extensions and non-standard
features that particular Lisp provides.  But in this case it would
most assuredly not be CCL.

On the other hand, targeting multiple Lisps is of main benefit to the
user (and a non-negligible burdon on the Axiom developers).  IFAIK,
there are effectively no users of CCL, and no user we cant reach via
one of the `standard' open source lisp systems.

In either case, we get the support of the development teams.  We do
not have that, AFAICT, with CCL.

> CCL was the Lisp that was used to implement the commercial version
> of Axiom on Windows. As such it might be a good source to mine for
> Windows compatibility issues. For example CCL was extended with a
> lisp-callable GREP command specifically for Windows compatibility
> since grep is not available on native Windows. 

Unfortunately I cant really comment on this aspect.  I have not used
windows for many, many years.

I assume what your saying is that CCL provided a means to emulate the
missing unix functionality on windows without the need for a
compatibility layer like msys or cigwin?  I could see how that would
be an advantage for the average windows user as they are only
interested in a binary blob that works for them.  We would need to
figure out how to effectively cross-compile axiom into a native
windows app.  I dont see any of that happening myself so I would
simply rely on my clouded perspective that all the world is unix, and
let msys/cigwin take care of the rest.

> Other things that might be for some use in CCL relate to the
> "saturn" browser interface for Windows which unfortunately was not
> part of the open source release but might be important for future
> attempts to rivive this kind of interface on Windows and Linux.

I never saw "saturn", so i dont really know what it is. I have no way
to resurect it or test it.  I doubt I will spend time
reverse-engineering something like that.

Besides, I thought the whole Axiom-in-a-browser was the preferred route
towards a cross-platform interface?

> > > IMHO we should choose one of possible directions:
> > > 
> > > 1) Make sure that CCL really works for building Axiom
> > > 2) Drop CCL support completly
> > 
> > It was in thinking about these two options exactly which promoted
> > my email.
> 
> If resources permitted, I would opt for 1) but I cannot offer more
> than just some support for testing such a configuration.

Initially, supporting CCL would not be terribly expensive.  I belive
the build amchinery is present in all the branches to support it.  Its
the long term cost of having to maintain both Axiom _and_ CCL that is
convincing me the resources are not available. Esp. since Axiom wants
to be Ansi compliant and CCL is certanly not.

> > > Current state, that is having a lot of code to support CCL, but
> > > no testing of this code gives us the combined disadvantages of
> > > the possibilities above: we are spending time on CCL support code,
> > > but CCL does not work out of the box.
> > > 
> > > From my point of view main advantage of CCL is that it is quite
> > > portable.  Also, it looks that CCL can be cross-compiled with
> > > basically the same effort as for native build.  There is also
> > > licencing issue: IIUC CCL licence is pretty liberal when somebody
> > > wants to deliver closed source program on top of CCL, but is
> > > GPL incompatible.  
> > 
> > I am not a fan of the license myself.  I doubt Codemist Ltd would
> > let it go under three-clause BSD.  Im not interested in improving
> > software under a license like this.
> 
> As far as I know, Arthur Norman, the author of CCL is still a
> member of this email list. *If* we were to choose to continue some
> support for Axiom in CCL I think he might be interested and may
> be quite flexible about license issues.

I probably should not have made a satement about the licence anyways.

But any input from Arthur would certainly be appreciated.

> 
> > ...
> 
> Regards,
> Bill Page.


Thanks,
Steve





reply via email to

[Prev in Thread] Current Thread [Next in Thread]