\start
Date: Fri, 01 Oct 2010 22:54:39 -0400
From: Tim Daly
To: list
Subject: ACL2 and Axiom

  Well you've finally given me an example to motivate me.

We've had the "in-plan" task to embed ACL2 under Axiom (since
both run in common lisp) so we can use the facilities of ACL2
in our computer algebra system. I suspect there will be a bit of
dancing to get the initialization correct and to hide the top
level interface but Axiom and ACL2 live in different packages
so there shouldn't be much conflict.

In particular, this facility is of interest as a reasoning mechanism
behind a "proviso" facility, that is, "1/x provided x != 0".

Does ACL2 handle reasoning about interval arithmetic?
Are there particular books in ACL2 I should study?

Also, the SUBSETP test failed in GCL-2.6.8.
I will pull the latest GCL sources and try again.

Tim Daly
Axiom Lead Developer


On 10/1/2010 12:11 PM, Matt Kaufmann wrote:
> The following works.  (I got the set-default-hints form from output of
> the include-book form.)
>
> (encapsulate
>   ()
>   (local (include-book "arithmetic-5/top" :dir :system))
>   (local (set-default-hints
>           '((nonlinearp-default-hint stable-under-simplificationp
>                                      hist pspv))))
>   (defthm russinoff
>     (implies (and (rationalp a)
>                   (rationalp b)
>                   (rationalp c)
>                   (<= 1 a)
>                   (<  0 b)
>                   (<  0 c)
>                   (<= (expt a 2) (* b (+ c 1)))
>                   (<= b (* 4 c)))
>              (<  (expt (- a 1) 2) (* b c)))))
>
> -- Matt
>     From: David Russinoff
>     Date: Fri, 1 Oct 2010 10:58:19 -0500
>
>     Sorry, I meant to say a>= 1.
>     ________________________________________
>     From: Pete Manolios 
>     Sent: Friday, October 01, 2010 10:55 AM
>     To: Russinoff, David
>     Cc: acl2@utlists.utexas.edu
>     Subject: Re: algebra problem
>
>     David,
>
>     Here is the formalization of your conjecture in ACL2.
>
>     (thm (implies (and (rationalp a)
> 		      (rationalp b)
> 		      (rationalp c)
> 		      (<  0 a)
> 		      (<  0 b)
> 		      (<  0 c)
> 		      (<= (expt a 2) (* b (+ c 1)))
> 		      (<= b (* 4 c)))
> 		 (<  (expt (- a 1) 2) (* b c))))
>
>     I tried it in ACL2s, the ACL2 Sedan (the one I hinted you might want to try).
>
>     After 0 seconds, here is what it returned:
>
>     We falsified the conjecture. Here is the counterexample:
>      -- (A 1/4), (B 13/23) and (C 9/47)
>
>
>
>     On Fri, Oct 1, 2010 at 11:39 AM, Russinoff, David
>     David Russinoff  wrote:
>     >  Here is a high school algebra problem that I've been staring at for
>     >  a couple of hours and is making me feel pretty stupid.
>     >
>     >  Proposition: Let a, b, and c be positive rationals.  If a^2<= b*(c+1)
>     >  and b<= 4*c, then (a-1)^2<  b*c.
>     >
>     >  Proof: sqrt(b*(c+1)) - sqrt(b*c)<= sqrt(4*c*(c+1)) - sqrt(4*c*c)
>     >                                   <  sqrt(4*c*c + 4*c + 1) - 2*c
>     >                                   = 2*c + 1 - 2*c
>     >                                   = 1.
>     >  Therefore, a<= sqrt(b*(c+1))<  sqrt(b*c) + 1 and a - 1<  sqrt(b*c).
>     >
>     >  I need an ACL2 proof. I should be able to prove it without mentioning
>     >  square roots.  As J says (I paraphrase), "If it's true, you can prove it.
>     >  So what?"  But I'm still staring and feeling stupid.
>     >
>     >

\start
Date: Sat, 2 Oct 2010 03:29:59 -0500
From: J Moore
To: Tim Daly
Subject: ACL2 and Axiom

Hi Tim.  You asked

> Does ACL2 handle reasoning about interval arithmetic?
> Are there particular books in ACL2 I should study?

I am not aware of an interval arithmetic book.  There have been
several undergraduate student projects to build simple interval
arithmetic books but none made it into the distribution.  Of course, I
presume you're aware of ACL2's extensive collection of rational and
integer arithmetic books, e.g., arithmetic-5/top and the modulo
arithmetic of ihs and the register-transfer/floating point stuff of
rtl (most recently rtl8).

\start
Date: Sat, 02 Oct 2010 11:56:02 -0400
From: Tim Daly
To: J Moore
Subject: Re: ACL2 and Axiom

  J

Ok. Once I climb the learning curve I'll look at that
in more detail.

I've put up a git repository to contain the changes I need to make to
embed ACL2. Both Axiom and ACL2 can sit in the same lisp image. I have
to figure out some Axiom "cover" domains that export things like a
"prove" function and a compatible set of domains to cover the data
representation.

I looked at the code a bit last night. Most of the code changes would
involve things like #- conditionally removing the ACL2 user I/O and
GCL initialization.

On 10/2/2010 4:29 AM, J Strother Moore wrote:
> Hi Tim.  You asked
>
>> Does ACL2 handle reasoning about interval arithmetic?
>> Are there particular books in ACL2 I should study?
> I am not aware of an interval arithmetic book.
> There have been several undergraduate student
> projects to build simple interval arithmetic books
> but none made it into the distribution.  Of
> course, I presume you're aware of ACL2's extensive
> collection of rational and integer arithmetic
> books, e.g., arithmetic-5/top and the modulo
> arithmetic of ihs and the
> register-transfer/floating point stuff of rtl
> (most recently rtl8).

\start
Date: Sat, 2 Oct 2010 08:47:59 -0500
From: Matt Kaufmann
To: Tim Daly
Subject: Re: ACL2 and Axiom
Cc: J Moore

Hi, Tim --

I wonder if another possibility might be to view Axiom as a sort of
slave to ACL2, rather than the other way around.  The sequence of
steps would be: (1) build ACL2 as usual; (2) start up ACL2 and exit
its read-eval-print loop (by typing :q); (3) load the Axiom files; and
(4) save an image.  The Axiom user could then do his usual stuff, but
when necessary, enter ACL2 to do whatever is necessary to discharge
proof obligations.  With such an approach, if ACL2 cannot prove a goal
automatically, then at least one could enter the ACL2 read-eval-print
loop and interact with it to come up with a proof.

I see two other potential advantages I can see for keeping ACL2
intact.  The first is that by avoiding modifications to ACL2, even in
small ways that you have in mind, you avoid the risk of unforeseen
tricky issues (after many years I'm still often surprised by
subtleties that arise when modifying ACL2), and you avoid having to
maintain your mods over time as ACL2 evolves.  The second is that an
ACL2 user could perhaps employ Axiom as a trusted oracle (using the
so-called "trust tag" mechanism for external tools), so that
computations done by Axiom are stored as ACL2 theorems (input =
output).

By the way, I suspect though that Axiom traffics in real (and complex)
numbers, or at least floating point numbers.  ACL2, however, is
restricted to rational (and complex rational) numbers.  So you might
want to consider instead Ruben Gamboa's modification ACL2(r) of ACL2,
which is distributed with ACL2 but built with a different "make"
command.  That system supports reals and complexes, though still not
floats.

I'd be happy to discuss any of this with you further, either on the
list if you think others want to join in, or individually.

-- Matt

     J

   Ok. Once I climb the learning curve I'll look at that
   in more detail.

   I've put up a git repository to contain the changes I
   need to make to embed ACL2. Both Axiom and ACL2 can sit
   in the same lisp image. I have to figure out some Axiom
   "cover" domains that export things like a "prove" function
   and a compatible set of domains to cover the data representation.

   I looked at the code a bit last night. Most of the code changes
   would involve things like #- conditionally removing the ACL2
   user I/O and GCL initialization.

   Tim

   On 10/2/2010 4:29 AM, J Strother Moore wrote:
   > Hi Tim.  You asked
   >
   >> Does ACL2 handle reasoning about interval arithmetic?
   >> Are there particular books in ACL2 I should study?
   > I am not aware of an interval arithmetic book.
   > There have been several undergraduate student
   > projects to build simple interval arithmetic books
   > but none made it into the distribution.  Of
   > course, I presume you're aware of ACL2's extensive
   > collection of rational and integer arithmetic
   > books, e.g., arithmetic-5/top and the modulo
   > arithmetic of ihs and the
   > register-transfer/floating point stuff of rtl
   > (most recently rtl8).

\start
Date: Sat, 02 Oct 2010 14:24:08 -0400
From: Tim Daly
To: list
Subject: Re: ACL2 and Axiom
Cc: J Moore, Matt Kaufmann

On 10/2/2010 9:47 AM, Matt Kaufmann wrote:
> Hi, Tim --
>
> I wonder if another possibility might be to view Axiom as a sort of
> slave to ACL2, rather than the other way around.  The sequence of
> steps would be: (1) build ACL2 as usual; (2) start up ACL2 and exit
> its read-eval-print loop (by typing :q); (3) load the Axiom files; and
> (4) save an image.  The Axiom user could then do his usual stuff, but
> when necessary, enter ACL2 to do whatever is necessary to discharge
> proof obligations.  With such an approach, if ACL2 cannot prove a goal
> automatically, then at least one could enter the ACL2 read-eval-print
> loop and interact with it to come up with a proof.
I see a few uses for ACL2/Axiom. One is as a build-time proof checker
to raise the level of system quality. A second is as a basis for some
research ideas I have about provisos. A third is as an end-user set of
Axiom domains for doing proofs (e.g. exporting a "prove" function)

The first issue of raising the level of system quality would involve
build-time proof checking which, if it failed, would be expected to
stop the build. There would be no need for a user interface.

The second issue of proviso work is "unpublished ideas" involving
interactions between Axiom domains. I have some ideas for symbolic
intervals and I think that ACL2 would be useful there. This also does
not involve a user interface since it only interacts with dynamically
created Axiom objects. This involves a pile of "scope issues" since
sets of provisos would live in a tree structure which Axiom needs to
manage.

The third issue of the end-user "cover" functions would capture and
expose the ACL2 functionality (e.g. prove) applied to Axiom objects
(e.g.  rationals, aka Fraction(Integer) in Axiom-speak). This might
involve user interaction with ACL2 but I haven't given that issue any
thought.  It may be that the interactive portion "just works"
depending on who is reading the user input at the time. If the system
falls into an ACL interactive loop doing its own reads then Axiom
won't know or care.  There is no such thing as a simple job, of
course.


In the long term plan I want Axiom to have a solid, proven set of
algorithms but the proofs are static. The build times would be much
longer but the end user wouldn't see that. They would only see
"certified" results. I would consider it a milestone if I could
automatically prove that Axiom's Euclidean algorithm was correct. Just
getting this right would be a whole PhD thesis :-)

So the long term goal is a computer algebra system with proven
algorithms rather than a system that proves things and uses a computer
algebra system.  Hence ACL2 lives "inside" Axiom by design.

> I see two other potential advantages I can see for keeping ACL2
> intact.  The first is that by avoiding modifications to ACL2, even in
> small ways that you have in mind, you avoid the risk of unforeseen
> tricky issues (after many years I'm still often surprised by
> subtleties that arise when modifying ACL2), and you avoid having to
> maintain your mods over time as ACL2 evolves.  The second is that an
> ACL2 user could perhaps employ Axiom as a trusted oracle (using the
> so-called "trust tag" mechanism for external tools), so that
> computations done by Axiom are stored as ACL2 theorems (input =
> output).
I've created a git repository to track changes. That way I can pull the
latest ACL2 and merge my patches over your master code. I expect that there
will be several kinds of changes.

The first would be some #-Axiom conditionals to remove things like GCL
specific configurations that Axiom already does. Since we live in different
packages I don't think there will be function/macro name collisions. These
will not be of interest to you upstream.

The second will be adding bi-directional functions to convert ACL2 data
(e.g. rationals) and Axiom data (Fraction(Integer)). These will not be of
interest to you upstream.

The third will be some work on "proviso" or "interval" books.
These would be of interest to you and I'd push them upstream.

Another issue, from the Axiom side, is that Axiom is a literate program.
I'd like the proofs to also be literate since the intended audience for
the proofs is a human. I'm not yet familiar enough with the ACL2 code base
to have an informed opinion on this.
> By the way, I suspect though that Axiom traffics in real (and complex)
> numbers, or at least floating point numbers.  ACL2, however, is
> restricted to rational (and complex rational) numbers.  So you might
> want to consider instead Ruben Gamboa's modification ACL2(r) of ACL2,
> which is distributed with ACL2 but built with a different "make"
> command.  That system supports reals and complexes, though still not
> floats.
Axiom supports a lot of number types, including roman numerals :-)
My initial interest is intervals with a mixture of rational and symbolic
endpoints.

Machine reals (aka Axiom DoubleFloats) are of interest in that I'm
working on some numerics. It would be of interest to prove that no
reordering of Axiom-defined arithmetic operators causes results to
deviate by more than a small bounded number of low-order bits.

I've spent the last 5 years of my professional life at CMU (Axiom
is a hobby not related to work) developing the Intel machine level
semantics of instructions. We can now reason about machine code
sequences using conditional-concurrent assignments (CCAs). This
research is part of the Linger-Mills-Witt function semantics. It
will be interesting to see if there is a useful connection between
the function extraction semantics work and ACL2 machine-level proofs.

Floats (Axiom floats, that is) just make my head hurt. I don't think
I'm man enough to prove anything about them :-)

Tim

> I'd be happy to discuss any of this with you further, either on the
> list if you think others want to join in, or individually.
>
> -- Matt

>       J
>
>     Ok. Once I climb the learning curve I'll look at that
>     in more detail.
>
>     I've put up a git repository to contain the changes I
>     need to make to embed ACL2. Both Axiom and ACL2 can sit
>     in the same lisp image. I have to figure out some Axiom
>     "cover" domains that export things like a "prove" function
>     and a compatible set of domains to cover the data representation.
>
>     I looked at the code a bit last night. Most of the code changes
>     would involve things like #- conditionally removing the ACL2
>     user I/O and GCL initialization.
>
>     Tim
>
>     On 10/2/2010 4:29 AM, J Strother Moore wrote:
>     >  Hi Tim.  You asked
>     >
>     >>  Does ACL2 handle reasoning about interval arithmetic?
>     >>  Are there particular books in ACL2 I should study?
>     >  I am not aware of an interval arithmetic book.
>     >  There have been several undergraduate student
>     >  projects to build simple interval arithmetic books
>     >  but none made it into the distribution.  Of
>     >  course, I presume you're aware of ACL2's extensive
>     >  collection of rational and integer arithmetic
>     >  books, e.g., arithmetic-5/top and the modulo
>     >  arithmetic of ihs and the
>     >  register-transfer/floating point stuff of rtl
>     >  (most recently rtl8).
>     >
>     >  J
>     >
>     >
>

\start
Date: Thu, 14 Oct 2010 11:16:43 -0400
From: Tim Daly
To: list
Subject: Fwd: [Dbworld] 10 PhD student positions in Computational Logic at Vienna University of Technology

---------- Forwarded message ----------
From: Thomas Krennwallner
Date: Mon, Sep 20, 2010 at 6:45 PM
Subject: [Dbworld] 10 PhD student positions in Computational Logic at
Vienna University of Technology
To: dbworld@cs.wisc.edu


The Vienna University of Technology (TU Wien) is offering 10 PhD
student positions within the doctoral program

             "Mathematical Logic in Computer Science"

which is launched in Fall 2010; five of the positions are reserved for
female applicants.

The program is jointly organized by the faculties of Informatics,
Mathematics, and Physics, with a strong emphasis on Logic in Computer
Science; computational logic is one of the priority research areas of
the Faculty of Informatics.

TU Wien has a strong international reputation in various fields
targeted in the program, including

   * Logic in Databases,
   * Computer Aided Verification,
   * Constraint Satisfaction and Satisfiability,
   * Knowledge Representation and Reasoning,
   * Finite Model Theory,
   * Quantum Information and Recursion Theory,
   * Proof Theory and Automated Deduction,
   * Many Valued and Fuzzy Logic,
   * Complexity Theory,
   * Set Theory.

The program is interdisciplinary and fosters the application of
Mathematical Logic to Computer Science; two envisaged key application
areas are

   * Model-Based Design and Verification,
   * Advanced Information Systems.

The faculty of the program consists of M. Baaz, A. Ciabattoni,
T. Eiter (coordinator), M. Goldstern, G. Gottlob (associated),
A. Leitsch, R. Pichler, K. Svozil, S. Szeider, H. Veith and
S. Woltran.

Candidates must have an MSc or equivalent degree in
Computer Science, Mathematics or related fields, and an excellent
record of study. They should have solid basic knowledge in logic,
discrete mathematics, and computer science; knowledge in
fields targeted in the program is desired.

Each PhD student position is funded for three years (regular
employment contract with full social benefits). The yearly salary ranges
from a minimum of 12,724 Euro to 25,915 Euro before taxes, depending
on cofunding via associated projects.

Applications are solicited starting immediately, and will be
considered starting from September 10, 2010, until all positions are
filled, but no longer than March 15, 2011.

Further details about the program and the application procedure are
available at http://www.dbai.tuwien.ac.at/drkolleg/.

For additional information, please send email to
dk-info@dbai.tuwien.ac.at.

\start
Date: Tue, 19 Oct 2010 17:21:00 -0500
From: Rob Nendorf
To: list
Subject: WEIER

I'm brand new to axiom, and need to use the WEIER package to calculate
the distinguished polynomial of a given power series (I need to use
the weierstrass function).  I'm completely lost as to how to implement
the package.

I would appreciate any help you can offer.  Please respond at a beginner level.

\start
Date: Wed, 20 Oct 2010 15:45:51 -0500
From: Robert Smith
To: list
Subject: Infinite loop in regression test

First, my system specifications:

$uname -a
Linux TheAmbiguousCase 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16
19:52:42 UTC 2010 x86_64 GNU/Linux

I downloaded the "ubuntu64" source code of September 2010 and
extracted it in "/home/quad" and performed the following commands as
instructed

$ export AXIOM=/home/quad/axiom/mnt/ubuntu64
$ export PATH=$AXIOM/bin:$PATH

Everything seems to go okay and I seem to be in an infinite loop at

  regression testing richhyper1000-1098

I suspect it's an infinite loop because it's been on this test for
about an hour. Any hints or suggestions, or perhaps more information
needed?

\start
Date: Sat, 23 Oct 2010 17:55:21 -0400
From: Tim Daly
To: list
Subject: Re: Infinite loop in regression test

  Some of the integration tests can take a very long time.
Each test prints a number that distinguishes the test.
Look for a line beginning

--S (some number)

or tell me the variable being assigned such as

t1064:=

On 10/20/2010 4:45 PM, quad wrote:
> Good day all,
>
> First, my system specifications:
>
> $uname -a
> Linux TheAmbiguousCase 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16
> 19:52:42 UTC 2010 x86_64 GNU/Linux
>
> I downloaded the "ubuntu64" source code of September 2010 and
> extracted it in "/home/quad" and performed the following commands as
> instructed
>
> $ export AXIOM=/home/quad/axiom/mnt/ubuntu64
> $ export PATH=$AXIOM/bin:$PATH
>
> Everything seems to go okay and I seem to be in an infinite loop at
>
>    regression testing richhyper1000-1098
>
> I suspect it's an infinite loop because it's been on this test for
> about an hour. Any hints or suggestions, or perhaps more information
> needed?

\start
Date: Tue, 26 Oct 2010 14:24:06 -0400
From: Camm Maguire
To: Thomas Kahle
Subject: Re: Axiom for Gentoo

Greetings!  OK just checked in gmp5 support onto the 2.6.8pre branch.

Separately, perhaps you might be able to tell me why on an old
sicortex gentoo box (mips64)  I get the following:

gcc   -o raw_ansi_gcl  -L.  -Wl,-Map raw_ansi_gcl_map  -lansi_gcl -lX11    -lm  -lgmp -lreadline -lc -lgclp 
/.root0/usr/mips64el-gentoo-linux-gnu/gcc-bin/4.1.2/../../../lib/gcc/mips64el-gentoo-linux-gnu/4.1.2/../../../../mips64el-gentoo-linux-gnu/bin/ld: skipping incompatible ./libansi_gcl.a when searching for -lansi_gcl
/.root0/usr/mips64el-gentoo-linux-gnu/gcc-bin/4.1.2/../../../lib/gcc/mips64el-gentoo-linux-gnu/4.1.2/../../../../mips64el-gentoo-linux-gnu/bin/ld: cannot find -lansi_gcl

but

gcc   -o raw_ansi_gcl  -L.  -Wl,-Map raw_ansi_gcl_map  libansi_gcl.a -lX11    -lm  -lgmp -lreadline -lc -lgclp 

works fine.  The compiler is apparently configured as 64bit only.

Take care,

Thomas Kahle writes:

> On 14:24 Thu 14 Oct     , Camm Maguire wrote:
>> Greetings!
>> 
>> Where can I get gmp5?  Does anyone know why it is not in Debian
>> unstable yet?
>
> On 
>
> http://packages.debian.org/search?keywords=gmp
>
> you find lib{32,64}gmp10 and dev packages in the 'experimental'
> branch. I don't know what that is actually.  More experimental than sid?
> Anyhow, these packages contain the .so that constitutes the main part of
> gmp.
>> Take care,
>> 
>> Tim Daly writes:
>> 
>> > Camm, FYI.... -- Tim
>> >
>> > -------- Original Message --------
>> >
>> > Dear Tim,
>> >
>> > coming back to all what we had written below.  I made a new gentoo
>> > ebuild (package) of the september version, using 'unset ABI'.  It works,
>> > but the general policy is that such a solution (bundled copies of system
>> > libraries) will prevent axiom from entering the main gentoo tree.  Since
>> > this is effectively caused by gcl depending on gmp-4, and not accepting
>> > gmp-5 there is probably little you can do about it.  However, since you
>> > seem to know the people, maybe you can coordinate with the gcl
>> > developers.  If gcl works with gmp-4 it should be possible to make it
>> > work with version 5 too, I think.
>> >
>> > On 06:33 Fri 01 Oct     , Tim Daly wrote:
>> >>
>> >>
>> >>  On 10/1/2010 3:04 AM, Thomas Kahle wrote:
>> >>  >  On 05:28 Fri 01 Oct     , Tim Daly wrote:
>> >>  >>  On 10/1/2010 2:01 AM, Thomas Kahle wrote:
>> >>  >>>  On 00:37 Fri 01 Oct     , Tim Daly wrote:
>> >>  >>>

>> >>  >>>>  Axiom ships with a copy of GCL because it has been tested
>> >>  >>>>  with that copy. The GMP that ships with that copy also
>> >>  >>>>  has been tested with Axiom. I'm not sure how this can
>> >>  >>>>  fail in Gentoo.  >> >> >>> One specific problem arises
>> >>  >>>>  when you have only gmp-5 on your system. The >> >> >>>
>> >>  >>>>  configure of the shipped gcl does not like that and will
>> >>  >>>>  start to build >> >> >>> an internal copy of gmp-4. The
>> >>  >>>>  configure of this internal gmp fails >> >> >>> because
>> >>  >>>>  the ABI variable in Gentoo is set to either "32", or
>> >>  >>>>  "AMD64", >> >> >>> while the configure expects it to be
>> >>  >>>>  "standard", no matter on which >> >> >>> architecture you
>> >>  >>>>  are.  The only acceptable solution for the main tree of
>> >>  >>>>  >> >> >>> gentoo by the way would be to make gcl build
>> >>  >>>>  with gmp-5.

>> >>  >>  I'm confused. Where is the GMP getting the ABI information?
>> >>  >>  It looks like Gentoo sets an environment variable.  Do I
>> >>  >>  need to add an 'unset ABI' to the make script?  >> >> > The
>> >>  >>  shell environment of the package manager contains an ABI
>> >>  >>  variable >> >> > because many libraries use that from the
>> >>  >>  environment.  There are also >> >> > more options than just
>> >>  >>  32 or 64 bit, I think. In the official gmp >> >> > package
>> >>  >>  that gentoo ships, the build system has been modified. We
>> >>  >>  patch >> >> > it to use the variable GMPABI instead of ABI
>> >>  >>  and then do the following >> >> > mapping:

>> >>  >
>> >>  >  [...]
>> >>  >
>> >>  >         	# GMP believes hppa2.0 is 64bit
>> >>  >  	local is_hppa_2_0
>> >>  >  	if [[ ${CHOST} == hppa2.0-* ]] ; then
>> >>  >  		is_hppa_2_0=1
>> >>  >  		export CHOST=${CHOST/2.0/1.1}
>> >>  >  	fi
>> >>  >
>> >>  >  	# ABI mappings (needs all architectures supported)
>> >>  >  	case ${ABI} in
>> >>  >  		32|x86)       export GMPABI=32;;
>> >>  >  		64|amd64|n64) export GMPABI=64;;
>> >>  >  		o32|n32)      export GMPABI=${ABI};;
>> >>  >  	esac
>> >>  >
>> >>  >  [...]

>> >>  >  Ok, the bottom line is that we really want gcl to use the
>> >>  >  gmp that is already installed on the users system, because
>> >>  >  we have fixed that once.  Gentoo's QA will never allow
>> >>  >  something that builds an internal copy of gmp to enter the
>> >>  >  stable tree. The main problem is that dependency resolution
>> >>  >  should take place on the level of the package manager.  If
>> >>  >  every scientific package brings its on version of gmp and a
>> >>  >  security issue with some older version is found than you
>> >>  >  have X copies of a vulnerable library on your system and X
>> >>  >  projects need to release new versions and you keep fixing
>> >>  >  the same bugs X times.

>> >>  Axiom includes only two key packages, GCL and noweb. Axiom is
>> >>  gradually planning to eliminate noweb but GCL is a long term
>> >>  commitment. We appreciate the "fix it once" idea but we have to
>> >>  balance it with the "make it right" idea. Axiom is an extremely
>> >>  complex and very large system (about a million "things of
>> >>  code"). Every change gets tested. We have even shipped about a
>> >>  dozen "snapshots" of GCL (See the GCLVERSION variable in the
>> >>  top level Makefile file, which shows 15 different
>> >>  versions). The policy is to take a snapshot of GCL and qualify
>> >>  Axiom on that version. For such fundamental level software like
>> >>  GCL (and GMP) we need to make sure that the user has not
>> >>  introduced unstable elements. A change in GMP would make minor
>> >>  but incorrect changes to large, long running, and numerically
>> >>  intense algorithms.  The user would never know, or if they did
>> >>  know, they would blame Axiom.

>> >>  Camm has just finished another minor release which he tested on
>> >>  a couple of my systems. I have yet to fully qualify Axiom on
>> >>  that release so it is not yet in the shipped system. I hope to
>> >>  get the new GCL release into the November Axiom release.

>> >>  >>  GCL uses GMP internally. I'm not sure what this has to do
>> >>  >>  with the rest of Gentoo. While I'm not opposed to using
>> >>  >>  gmp5 it would require coordination with Camm and validation
>> >>  >>  testing with Axiom. The GCL-internal version of GMP is
>> >>  >>  known to work on all platforms. I'd have to "qualify" gmp5
>> >>  >>  on all of the platforms and also make sure that Axiom/GCL
>> >>  >>  interfaces don't change.

>> >>  >  Ok, so this might be a more long-term project, but it's
>> >>  >  certainly worthwhile.  By the way, do you know any release
>> >>  >  plans for gcl? I saw an alpha of 2.7 on a Debian mirror
>> >>  >  once, but I can't find anymore.

>> >>  I copied Camm on this reply. He can give definitive answers.

>> >>  >>  fedora you type:
>> >>  >>      export AXIOM=`pwd`/mnt/fedora
>> >>  >>  and if you build on ubuntu
>> >>  >>      export AXIOM=`pwd`/mnt/ubuntu

>> >>  >>  The basename of the AXIOM variable is used to set up a
>> >>  >>  makefile with particular options. I'd propose creating a
>> >>  >>  'gentoo' option so you can do export AXIOM=`pwd`/mnt/gentoo
>> >>  >>  This generated makefile can unset the ABI shell variable.

>> >>  >  Well, we can also just unset ABI in the Gentoo package but
>> >>  >  the main problem really is that I can not track what happens
>> >>  >  with that internal gmp.  Will gcl link statically against
>> >>  >  it? Or will it even try to install some shared libraries
>> >>  >  system-wide later?

>> >>  >  Thanks,
>> >>  >  Thomas
>> >>  >

>> >>  >>>>  I'd be happy to work with you to fix problems you encounter.

>> >>  >>>  That is good to hear. By the way, I have been trying with
>> >>  >>>  the July version, if this is fixed in September, please
>> >>  >>>  excuse.

>> >>  >>>>  Note that Axiom is a "literate program" so you're going
>> >>  >>>>  to find that most of the source lives in latex files. You
>> >>  >>>>  will need a running copy of latex and possibly some other
>> >>  >>>>  "system" files.  See the apt-get various lists for other
>> >>  >>>>  distributions to get an idea of the missing files
>> >>  >>>>  (e.g. git-core, texlive, gawk, etc).

>> >>  >>>  That is all set-up I think. The list of dependencies that
>> >>  >>>  we inferred is currently:

>> >>  >>>  virtual/latex-base
>> >>  >>>  app-text/dvipdfm
>> >>  >>>  dev-texlive/texlive-pstricks
>> >>  >>>  x11-libs/libXaw
>> >>  >>>  sys-apps/debianutils
>> >>  >>>  sys-process/procps
>> >>  >>>  <dev-libs/gmp-5.0

>> >>  >>>  These are Gentoo package names, but it should be more or
>> >>  >>>  less clear what is in there.

>> >>  >>>>  On 9/30/2010 4:42 PM, Thomas Kahle wrote:
>> >>  >>>>>  Dear Tim,

>> >>  >>>>>  I am trying to package Axiom for the Gentoo Linux
>> >>  >>>>>  distribution. Gentoo is a source based distribution in
>> >>  >>>>>  which the package manager automatically builds software
>> >>  >>>>>  on the users system. I encountered problems with
>> >>  >>>>>  packaging axiom because of its bundled copy of Gnu
>> >>  >>>>>  common lisp.  In general, we have problems with bundled
>> >>  >>>>>  software because it creates code duplication and
>> >>  >>>>>  introduces all sorts of problems.  Matters are being
>> >>  >>>>>  complicated by the fact that this flavor of lisp is more
>> >>  >>>>>  or less unmainted upstream.  The last release is from
>> >>  >>>>>  2005.  Because of many unfixed problems gcl is currently
>> >>  >>>>>  not available in Gentoo.  If we ignore Gentoo's policies
>> >>  >>>>>  for a moment and try to build axiom with the gcl that it
>> >>  >>>>>  ships internally, we find that this in turn tries to
>> >>  >>>>>  build an internal copy of gmp which will then fail.  The
>> >>  >>>>>  reasons for this failures have all been long fixed in
>> >>  >>>>>  Gentoo's official gmp, so we really don't want to
>> >>  >>>>>  duplicate all this here.  What are your plans for future
>> >>  >>>>>  versions of axiom in this regard?  We would really like
>> >>  >>>>>  to include a recent version of axiom into Gentoo, but
>> >>  >>>>>  currently it seems impossible.  Any hint you might have
>> >>  >>>>>  is appreciated.

\start
Date: Wed, 27 Oct 2010 18:19:04 -0400
From: Camm Maguire
To: Matt Kaufmann
Subject: 2.6.8 licensing

Greetings!  The FSF has requested that we "change the software license
to GPLv3 or later, and the documentation license FDLv1.3 or later".
By this I think they mean LGPLv3 of course.  To remain consistent with
the Debian Free Software guidelines, I think we'd have to add "with no
invariant sections, no front-cover texts and no back-cover texts'" to
the doc license.  I don't see any problem with this, but I thought I'd
put this out for comment just in case anyone else does.

Separately, at some point we might want to discuss having the FSF hold
the copyright, if that is even possible, let alone desirable.

I'm considering removing the binutils subtree, as all targets are
working now with custreloc save ia64 and hppa, which use dlopen as
always.  One can still build against an external bfd library if
desired.  It is probably necessary to keep the local gmp copy as a
convenience as many users don't seem to have this installed.

\start
Date: Wed, 27 Oct 2010 23:09:01 -0500
From: Gabriel Dos Reis
To: Donald Winiecki
Subject: Re: 2.6.8 licensing
Cc: Camm Maguire

Donald Winiecki writes:

| A change to the most recent licenses will make things consistent with
| FSF's current way of thinking about open source, though more
| aggressive developers seem to think it's restrictive.  Given the
| typical users and usual applications of GCL, this may not be an issue.

It is my opinion that GPLv3 goes a bit too far -- but I would dispute
the label "aggressive developer" :-) 

| But I'm not sure -- if GCL is licensed under GPL3, does that mean that
| anything built with or under it will also have to be licensed under
| GPL3?  (I guess that's why Camm is querying the Axiom list.)

Indeed.  That does have some implication for systems like the AXIOM family.
If I understand correctly, it will be a move from LGPL to GPLv3?

| And copyrighting GCL under the FSF seems like a reasonable idea, but
| without Camm, GCL would be fairly well static, I think.

well those are separate issues, I would think.  Having FSF owns
copyright relieves from some legal paperwork and burdens.  That is
largely orthogonal to who actually does the development work.

\start
Date: Thu, 28 Oct 2010 09:55:04 -0400
From: Camm Maguire
To: Gabriel Dos Reis, Jerry James
Subject: Re: 2.6.8 licensing
Cc: Donald Winiecki

Greetings!

Gabriel Dos Reis writes:

> Donald Winiecki writes:
>
> | A change to the most recent licenses will make things consistent with
> | FSF's current way of thinking about open source, though more
> | aggressive developers seem to think it's restrictive.  Given the
> | typical users and usual applications of GCL, this may not be an issue.
>
> It is my opinion that GPLv3 goes a bit too far -- but I would dispute
> the label "aggressive developer" :-) 
>
> | But I'm not sure -- if GCL is licensed under GPL3, does that mean that
> | anything built with or under it will also have to be licensed under
> | GPL3?  (I guess that's why Camm is querying the Axiom list.)
>
> Indeed.  That does have some implication for systems like the AXIOM family.
> If I understand correctly, it will be a move from LGPL to GPLv3?
>

Please excuse my ambiguous wording.  The proposal is to license GCL
under LGPLv3 (currently LGPLv2), and the documentation under the
FDLv1.3.  The LGPL 'library' license is non-viral for apps such as
axiom.

> | And copyrighting GCL under the FSF seems like a reasonable idea, but
> | without Camm, GCL would be fairly well static, I think.
>
> well those are separate issues, I would think.  Having FSF owns
> copyright relieves from some legal paperwork and burdens.  That is
> largely orthogonal to who actually does the development work.

Yes, this is orthogonal, and not too pressing.  But I do wonder if the
copyright holder has final say over issues such as licensing, which
might not be the case now.

\start
Date: Wed, 27 Oct 2010 19:18:08 -0600
From: Jerry James
To: Camm Maguire
Subject: Re: [Gcl-devel] 2.6.8 licensing
Cc: Matt Kaufmann

On Wed, Oct 27, 2010 at 4:19 PM, Camm Maguire wrot=
e:
> Greetings! The FSF has requested that we "change the software license
> to GPLv3 or later, and the documentation license FDLv1.3 or later".
> By this I think they mean LGPLv3 of course.

Forgive me if I've mistaken your meaning, but there is an FDL:

http://www.gnu.org/licenses/fdl-1.3.html

\start
Date: Wed, 27 Oct 2010 20:28:18 -0600
From: Donald Winiecki
To: Camm Maguire
Subject: Re: [Gcl-devel] 2.6.8 licensing
Cc: Matt Kaufmann

A change to the most recent licenses will make things consistent with
FSF's current way of thinking about open source, though more
aggressive developers seem to think it's restrictive.  Given the
typical users and usual applications of GCL, this may not be an issue.

But I'm not sure -- if GCL is licensed under GPL3, does that mean that
anything built with or under it will also have to be licensed under
GPL3?  (I guess that's why Camm is querying the Axiom list.)

And copyrighting GCL under the FSF seems like a reasonable idea, but
without Camm, GCL would be fairly well static, I think.

On Wed, Oct 27, 2010 at 4:19 PM, Camm Maguire wrot=
e:
> Greetings! =C2=A0The FSF has requested that we "change the software licen=
se
> to GPLv3 or later, and the documentation license FDLv1.3 or later".
> By this I think they mean LGPLv3 of course. =C2=A0To remain consistent wi=
th
> the Debian Free Software guidelines, I think we'd have to add "with no
> invariant sections, no front-cover texts and no back-cover texts'" to
> the doc license. =C2=A0I don't see any problem with this, but I thought I=
'd
> put this out for comment just in case anyone else does.
>
> Separately, at some point we might want to discuss having the FSF hold
> the copyright, if that is even possible, let alone desirable.
>
> I'm considering removing the binutils subtree, as all targets are
> working now with custreloc save ia64 and hppa, which use dlopen as
> always. =C2=A0One can still build against an external bfd library if
> desired. =C2=A0It is probably necessary to keep the local gmp copy as a
> convenience as many users don't seem to have this installed.

\start
Date: Fri, 29 Oct 2010 10:30:27 -0400
From: Tim Daly
To: list
Subject: re: [Gcl-devel] 2.6.8 licensing

  I have previously discussed the question of using GCL with Axiom.
GCL, originally ACKL, was written under IBM contract for Axiom.

Both the FSF and Stallman in direct email said there was no problem
using GCL with the mBSD code in Axiom. Note that Axiom distributes
and builds directly from the unmodified sources in the repository.
We add any patches, which we also distribute, at build time.

Since the whole philosophical point of the GPL license is to
guarantee the 4 freedoms, they are still guaranteed by this procedure.

On 10/27/2010 10:28 PM, Donald Winiecki wrote:
> A change to the most recent licenses will make things consistent with
> FSF's current way of thinking about open source, though more
> aggressive developers seem to think it's restrictive.  Given the
> typical users and usual applications of GCL, this may not be an issue.
>
> But I'm not sure -- if GCL is licensed under GPL3, does that mean that
> anything built with or under it will also have to be licensed under
> GPL3?  (I guess that's why Camm is querying the Axiom list.)
>
> And copyrighting GCL under the FSF seems like a reasonable idea, but
> without Camm, GCL would be fairly well static, I think.
>
> On Wed, Oct 27, 2010 at 4:19 PM, Camm MaguireCamm Maguire  wrote:
>> Greetings!  The FSF has requested that we "change the software license
>> to GPLv3 or later, and the documentation license FDLv1.3 or later".
>> By this I think they mean LGPLv3 of course.  To remain consistent with
>> the Debian Free Software guidelines, I think we'd have to add "with no
>> invariant sections, no front-cover texts and no back-cover texts'" to
>> the doc license.  I don't see any problem with this, but I thought I'd
>> put this out for comment just in case anyone else does.
>>
>> Separately, at some point we might want to discuss having the FSF hold
>> the copyright, if that is even possible, let alone desirable.
>>
>> I'm considering removing the binutils subtree, as all targets are
>> working now with custreloc save ia64 and hppa, which use dlopen as
>> always.  One can still build against an external bfd library if
>> desired.  It is probably necessary to keep the local gmp copy as a
>> convenience as many users don't seem to have this installed.

\start
Date: Fri, 29 Oct 2010 11:31:20 -0400
From: Camm Maguire
To: Tim Daly
Subject: re: [Gcl-devel] 2.6.8 licensing

Greetings!

Tim Daly writes:

>  I have previously discussed the question of using GCL with Axiom.
> GCL, originally ACKL, was written under IBM contract for Axiom.
>
> Both the FSF and Stallman in direct email said there was no problem
> using GCL with the mBSD code in Axiom. Note that Axiom distributes
> and builds directly from the unmodified sources in the repository.
> We add any patches, which we also distribute, at build time.
>
> Since the whole philosophical point of the GPL license is to
> guarantee the 4 freedoms, they are still guaranteed by this procedure.
>

You are of course correct and nothing in this proposal changes this.
The essence lies in the documentation license, which some have
interpreted as 'non-free' as they allow (but do not require) the
authors to specify some sections as 'unmodifiable'.  If GCL adopts the
new doc license, no such sections will (ever) be so designated.  This
satisfies the Debian Free Software Guidelines as well.

It seems all parties can be happy with this.  I was just asking if I
had overlooked something.

Take care,

> Tim Daly
>
>
> On 10/27/2010 10:28 PM, Donald Winiecki wrote:
>> A change to the most recent licenses will make things consistent with
>> FSF's current way of thinking about open source, though more
>> aggressive developers seem to think it's restrictive.  Given the
>> typical users and usual applications of GCL, this may not be an issue.
>>
>> But I'm not sure -- if GCL is licensed under GPL3, does that mean that
>> anything built with or under it will also have to be licensed under
>> GPL3?  (I guess that's why Camm is querying the Axiom list.)
>>
>> And copyrighting GCL under the FSF seems like a reasonable idea, but
>> without Camm, GCL would be fairly well static, I think.
>>
>> On Wed, Oct 27, 2010 at 4:19 PM, Camm MaguireCamm Maguire  wrote:
>>> Greetings!  The FSF has requested that we "change the software license
>>> to GPLv3 or later, and the documentation license FDLv1.3 or later".
>>> By this I think they mean LGPLv3 of course.  To remain consistent with
>>> the Debian Free Software guidelines, I think we'd have to add "with no
>>> invariant sections, no front-cover texts and no back-cover texts'" to
>>> the doc license.  I don't see any problem with this, but I thought I'd
>>> put this out for comment just in case anyone else does.
>>>
>>> Separately, at some point we might want to discuss having the FSF hold
>>> the copyright, if that is even possible, let alone desirable.
>>>
>>> I'm considering removing the binutils subtree, as all targets are
>>> working now with custreloc save ia64 and hppa, which use dlopen as
>>> always.  One can still build against an external bfd library if
>>> desired.  It is probably necessary to keep the local gmp copy as a
>>> convenience as many users don't seem to have this installed.

\start
Date: Fri, 29 Oct 2010 10:41:07 -0500
From: Gabriel Dos Reis
To: Camm Maguire
Subject: re: [Gcl-devel] 2.6.8 licensing

Camm Maguire writes:

[...]

| It seems all parties can be happy with this.

Yes, LGPLv3 is not an issue -- thanks for clarifying that point.



