axiom-developer
[Top][All Lists]
Advanced

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

RE: [Axiom-developer] letting my mud settle


From: Bill Page
Subject: RE: [Axiom-developer] letting my mud settle
Date: Wed, 9 Nov 2005 13:28:59 -0500

On November 9, 2005 12:57 PM Tim Daly wrote:
> 
> > > 
> > > On Tue, Nov 08, 2005 at 12:09:23PM -0500, Bill Page wrote:
> > > ...
> Mike Dewar wrote:
> > 
> > > I provided copies of the Axiom product to several people on the
> > > list so you would have had no problem bootstrapping the first
> > > open-source versions from the NAG code.
> > 
> > Do you mean that this original "Axiom product" binary - as distinct
> > from the commercial binary version - could have been distributed
> > as part of the original open source distribution? If that is true,
> > it makes me sad that Tim went to all the trouble to embed bootstrap
> > lisp code into the build process.
> 
> Bill, we had this discussion. I asked Mike for permission to
> distribute the commercial version to you and because of contract
> issues the answer was no. There is no "Axiom product" binary
> distinct from the commercial version that I'm aware of. In fact,
> we had a discussion about getting a single commercial copy just
> for you.

Actually I was never really interested in getting a copy of the
commercial version of Axiom as such. I already had a copy of the
demo version of Axiom for Windows that was distributed by NAG as
part of a promotional effort. My experience with Axiom prior to
the open source release was limited to playing with the demo version
on Windows. I was unhappy with the way development was going with
Maple, but I hesitated just a little too long before deciding to
actually purchase Axiom. When I went to the NAG website I found
Axiom was no longer available. :( The demo version is time limited
and so when open source Axiom arrived I found I could no longer
play with the Windows demo version.  Since the Windows version had
several unique features - like a completely re-done HyperDoc done
using an early version Techexplorer - I thought it would be very
useful to use this as a model for what we might eventually do with
the open source version of Axiom. What I asked Mike for was an
extended version of the key for the demo version on Windows, but
NAG was unable to provide that because of licensing conditions,
probably most directly related to techexplorer rather than Axiom,
and I respect their decision about that.

> 
> Mike provided me a copy of the commercial version for development
> purposes but I was unable to distribute it due to contract issues.
> We have him to thank for early progress.
>

So as I said originally: From your point of view you had no
alternative but to do the bootstrap from source because no
runnable binary for Axiom could be distributed with the open
source version of Axiom. Right?

> > 
> > > 
> > > Eliminating the need for a running Axiom was a good thing to 
> > > do, but if anything forced you to do it it was probably the
> > > decision to develop on GCL rather than CCL.
> > > 
> > 
> > Thanks. I really appreciate your input on this.
> 
> And this is a red herring anyway. Open Source is more than just
> the source code. It implies a way of working. Open Source people
> expect to type:
> 
>    ./configure
>    make
>    make install
> 
> from the sources.

That is exactly how the gcc is distributed and built. Of course
it assumes a running version of gcc in order to do that.

> But if we needed to distribute a binary product as part of the
> 'make' step then we'd have to build binaries that ran on every
> possible system so people could build axiom. But if we're going
> to distribute a binary axiom in order to build the system then
> why distribute the sources? Why rebuild?

I don't understand your logic. The reason to distribute the sources
is the same as the reason that GNU distributes the gcc sources -
to make the maintenance and improvement of gcc possible for as
many people as possible, who are interested and willing to do this
kind of work. We want the same thing for Axiom, right?

> 
> And if we don't distribute the binaries then nobody can build it.
>

I understand that the need to distribute binaries along with the
sources in order to re-build from the sources is a significant
requirement, but it does not seem much different than any other
fundamental operating system software. And from the point of view
of doing mathematics on a computer, Axiom is just another piece
of fundamental software of this kind.
 
> So the Axiom build needed to be restructured so it could be built
> from scratch. The commercial version of Axiom was useful for A/B
> testing but would never have become part of the open source
> platform.
> 
> It has nothing to do with CCL/GCL.
> 

Now I am confused. I thought Mike said rather explicitly above that
*if* we had chosen to distribute a ccl-based version of Axiom
then bootstrapping would not have been necessary (although still
perhaps a "good thing" to do anyway for other reasons). But anyway,
please ignore that I ever asked this question. All of this is just
history - not where we are now.

My point is that *now* that we do have freely licensed open source
binaries again, so we could return to the original maintenance model
for Axiom that was based on the having a running version of Axiom
available, as William Sit suggested in another email. I still think
that doing this might have some advantages in terms of making Axiom
development simpler, faster, and possible for people who do not want
to go to the effort of building Axiom from the bootstrap sources.

I guess what this amounts to would be providing an alternate
simplified source distribution of Axiom that started by assuming
that a running Axiom was already available (just like with gcc this
could be either a previously built version or a previously
downloaded binary version). Running 'make' with this distribution
would then use the locally modified Axiom sources to build a new
running version of Axiom including these changes. No Boot or Spad
bootstrapping would be necessary.

Regards,
Bill Page.






reply via email to

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