\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: Mon, 1 Dec 2014 14:17:48 +0000
From: Paul Onions <ponions37@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] build failure

As a point of reference FriCAS 1.2.4 builds ok for me on:-
1. OSX 10.5 (PowerPC) using SBCL 1.2.5, and on
2. OSX 10.10 using SBCL 1.2.4, but only after installing Apple's
command-line tools package and the XQuartz app, and even then only
with --x-includes=/usr/X11/include given to the configure script.

Paul

On 29/11/2014, daly@axiom-developer.org <daly@axiom-developer.org> wrote:
> Waldek,
>
> In response to a bug report comparing Axiom and Fricas I downloaded
> the latest Fricas release and did a build on my mac. It failed.
>
> The console log is at:
> http://daly.axiom-developer.org/fricas.20131129.fail
>
> Tim
>

\start
Date: Mon, 01 Dec 2014 15:05:36 -0500
From: Tim Daly <daly@axiom-developer.org>
To: Paul Onions <ponions37@gmail.com>
Subject: Re: [Axiom-developer] build failure

Paul,

>As a point of reference FriCAS 1.2.4 builds ok for me on:-
>1. OSX 10.5 (PowerPC) using SBCL 1.2.5, and on
>2. OSX 10.10 using SBCL 1.2.4, but only after installing Apple's
>command-line tools package and the XQuartz app, and even then only
>with --x-includes=/usr/X11/include given to the configure script.

Thanks for the note. These requirements should probably
be in the configure script I guess. 

I have quite a few of the developer's tools installed because
I did some Apple development work for a client. I don't recall
all the details though.

Waldek made some helpful suggestions off-list but my mac build 
just failed again a few minutes ago. 

I'm back in my office so I can build it elsewhere. I only
need it to chase an Axiom bug report and all I had was my mac.

Tim

\start
Date: Mon, 1 Dec 2014 14:50:25 -0600
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: Re: [Axiom-developer] [Axiom-math] Pointer update please.

There are several examples in the src/input directory you might find useful.

In particular, see 
src/input/groebner.input.pamphlet
src/input/groeb.input.pamphlet
src/input/noonburg.input.pamphlet
src/input/dop.input.pamphlet

As an aside, you surprised me with the links you posted.
> http://axiom-wiki.newsynthesis.org/axiom--test--1/src/algebra/PgrobnerSpad
implies that you found Axiom code from when it was maintained under the
GNU Arch source code control system (circa 2002).

Tim

\start
Date: Tue, 2 Dec 2014 09:31:08 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] help wanted -  send algebra examples

The plan calls for continuous integration. That is, automating 
the process of doing releases so that every new change becomes
a new release.

Part of that process involves running a test suite to make sure
that nothing broke, a process currently done by hand. If something
does break, a new test is added.

We are trying to build a more expansive suite of tests.

You can help. In particular, you can make sure that things you 
care about and depend upon become part of the test suite.

Ideally a test set would include an explanation, since not everyone
does Mellin transforms, or whatever your specialty is. But that isn't
required. Any input file you use for testing is fine.

At this point it is more important to gather the test sets.
Please create an input file, run it, capture the output, and send it.
That is, create

mytestset.input

   )spool mytestset.output
   3+5
   6+7
   )spool

run it, CHECK THAT THE ANSWERS ARE CORRECT, and send "mytestset.output"
to daly@axiom-developer.org

Even simple, seemingly mundane test suites can uncover failures.

Please help. 

Tim

\start
Date: Tue, 2 Dec 2014 15:36:40 -0600
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: Re: [Axiom-developer] input file examples

Raymond,

Thanks for your input file. 

There is a "best practices" version of regression test files
which is "in plan" for all test files as part of the continuous
integration effort. If something fails it should be possible
to know not only what was expected by WHY it was expected.

See the input file and its generated pdf at:
http://daly.axiom-developer.org/biquat.input.pamphlet
http://daly.axiom-developer.org/biquat.input.pdf 

Since these are full latex files you can embed diagrams, images,
and bibligraphic references.


Axiom supports running an individual test file, e.g.

  )cd src/input
  )tangle biquat   -- extract the default chunk named * from 
                   -- biquat.input.pamplet to create biquat.input
  )read biquat     -- read the biquat.input file, creating biquat.output
  )regress biquat  -- compare --R with the newly generated results

Note that the ')read' will probably exit Axiom as most test files
have the line ')lisp (bye)' at the end (for automation reasons).



These regression tests are in src/input/*.input.pamphlet

These test files are latex source files. The actual code is
contained within \begin{chunk} and \end{chunk} delimiters.

At build time the actual code is extracted, executed, and 
checked against known good results. So you'll see

\begin{document}
   more latex
\begin{chunk}{*}
   input file examples to run
\end{chunk}
\end{document}

within the {chunk} section there are a series of numbered tests
of the form (note that any line starting with -- is an Axiom comment)

--S 5 of 64
t1 := 3 + 4
--R 
--R   (5) 7
--R                     Type: PositiveInteger
--E 5

Axiom uses the fact that -- lines are comments in order to build the
test facility. If you run the above lines the interpreter only sees
the 't1 := 3 + 4' and ignores everything else.

So the hack is to run the input file with all the comment lines.
The result of the run looks like:

--S 5 of 64
t1 := 3 + 4
 
   (5) 7
                     Type: PositiveInteger
--R 
--R   (5) 7
--R                     Type: PositiveInteger
--E 5

Now it is just a matter of comparing the lines generated by the
interpreter with the lines prefixed by --R. If they don't match
then something failed. The --S number lets you find the failing
test and checks for missing tests and early exit failures.

This makes it trivial to create test files. Just 

   make an input file,
   use ')spool foo.output' at the beginning
   use ')spool' at the end
   run the input file
   edit the foo.output by adding --S, --R, and --E lines
   rename foo.output to foo.input
   add latex

Note also that since this is latex it can be used to create a pdf.
Anything NOT in a chunk is just latex. Anything IN a chunk will be
extracted and executed. This makes it possible to generate really
pretty test cases with  associated theory.

Tim

\start
Date: Thu, 4 Dec 2014 00:03:37 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] projects update

Progress has happened on the CI effort. Jenkins seemed to be the
most general and easiest setup. It handled the git repository and
the shell makefiles with plugins.

The CI version of Axiom is called "bronze". At the moment I'm working
on the makefiles to adjust them for jenkins. There have been changes
to expand, remove, and rewrite src/input for automated regression tests
under jenkins. 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom continuous integration
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  Currently we follow a model of publishing a "release"
  
  1) set up a continuous integration server
     - jenkins server setup
       * add git plugin
       * add shell plugin
       * build bronze project
     - rework makefiles for jenkins builds
     - rework src/input for jenkins builds

\start
Date: Fri, 12 Dec 2014 21:47:58 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] read the docs :-)

So I'm reading the documentation and updating it to match what
the code actually does... and I "discovered" the )savesystem command.

You can do things like
   axiom
   (1) -> t1:=2
   )savesystem foo

which will save Axiom and exit. Then you can do

   ./foo
   (1) -> t1
   2

which restarts Axiom with the session information intact.
Who knew?

Tim

\start
Date: Fri, 12 Dec 2014 21:57:33 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] read the docs :-)

The axiom command has a '-ws' (workspace) argument which will
re-activate a session saved with )savesystem. The default path
is $AXIOM/bin so given

   axiom 
   (1) -> t1:=4
   (2) -> )savesystem foo

Then
   axiom -ws foo
will look for workspace $AXIOM/bin/foo. It also accepts a full
pathname so you can save workspaces anywhere.

Tim

\start
Date: Sat, 13 Dec 2014 08:25:54 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] projects progress for week ending 12/13/14

It has been a busy week. Progress was made on a lot of the projects
listed in the projects file.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom continuous integration
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Most of the work has concentrated on the Axiom continuous integration.
In particular, a effort is being made to clean up all failing 
regression test files so that a build is always clean. This is
important to continuous integration since any failure should stop
a deployment.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom help files
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The help documentation for system commands was updated, both in the
Jenks book and Volume 5, the Interpreter. Some existing but undocumented
system commands were documented.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom src/input dispersal
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Along with this effort, existing files in src/input are being reworked.

Some of the files are being folded into the algebra books either as
documentation or unit test cases. The graphics files have been 
collected and are being moved to Volume 8.1, the Axiom gallery.

Integration examples are being run in a fully-instrumented Axiom
image. The idea is to sort the integrals based on which 'integrate'
function they invoke. This will help categorize the 'integrate'
functions in order to ensure test coverage and improve documentation.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom interpreter merge
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The src/interp directory still contains lisp files that need to be
merged. This week the src/interp/regress.lisp file was merged and
removed.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom CATS expansion
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The Computer Algebra Test Suite (CATS) now contains a section with
graphics tests. These are based on published graphs, such as the
CRC Standard Curves and Surfaces book. More graphs have been 
written but not yet pushed.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom buglist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bugs in Fricas were tested in Axiom. Those that failed were either
fixed or added to the buglist file. As a result, effort 2 was completed.

All of the Axiom test suite was run against Fricas to uncover fixed
bugs that need to be backported.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom makefile removal
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Portions of the Makefiles have been reworked to simplify the process.
This is still 'in process' and not yet pushed.

\start
Date: Sat, 13 Dec 2014 10:33:11 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] read the docs :-)


On 12/12/2014 10:57 PM, daly@axiom-developer.org wrote:
> The axiom command has a '-ws' (workspace) argument which will
> re-activate a session saved with )savesystem. The default path
> is $AXIOM/bin so given
>
>     axiom
>     (1) -> t1:=4
>     (2) -> )savesystem foo
>
> Then
>     axiom -ws foo
> will look for workspace $AXIOM/bin/foo. It also accepts a full
> pathname so you can save workspaces anywhere.
>
> Tim
>
>
Tim, I tried it and it didn't come back by either copying the above or 
the previous message.  Any hints?

aa :=23
)savesystem foo
saved in the current directory but
./foo  brought up axiom without the variable value
(1)aa
     (1) aa
in addition
axiom -ws  foo
gave "Cannot find the executable /usr/lib/axiom-20120501/bin/foo"
although the examples you gave )savesystem foo commands were identical.

Do I need Aldor or some such?

Ray
\start
Date: Sat, 13 Dec 2014 13:37:03 -0600
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: [Axiom-developer] read the docs :-)

Odd. What platform are you on? --Tim

\start
Date: Sat, 13 Dec 2014 15:19:34 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] read the docs :-)


On 12/13/2014 02:37 PM, daly@axiom-developer.org wrote:
> Odd. What platform are you on? --Tim
Attached is the result of "hardinfo"  (edited for privacy against 
hackers) and one run.  I examined the system log and found no errors in 
the correct time frame  14:55--
It you like I can run strace against it.
Incidentally I think everything else is running okay.   This is an 
official OS download.
I also have the sources
axiom-aug2014-src.tgz
or
  axiom-pre7-aug2014-src.tgz
I could compile them if needed.

Let me know; I think this could be made into a convenience with a 
selection menu in front.

Ray


--------------050804080805080908060606
Content-Type: text/plain; charset=UTF-8;
 name="hardinfo.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="hardinfo.txt"


Summary
Computer
Processor	2x AMD A4-3400 APU with Radeon(tm) HD Graphics
Memory	12285MB (2079MB used)
Operating System	Ubuntu 14.04.1 LTS
User Name	rrogers (Raymond Rogers)
Date/Time	Sat 13 Dec 2014 02:50:59 PM EST

Operating System
Version
Kernel	Linux 3.13.0-43-generic (x86_64)
Compiled	#72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014
C Library	Unknown
Default C Compiler	GNU C Compiler version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Distribution	Ubuntu 14.04.1 LTS

Reiterating session
rrogers@raymond-desktop-Ubuntu:~$ axiom
                        AXIOM Computer Algebra System 
                          Version: Axiom (May 2012)
                Timestamp: Tuesday July 30, 2013 at 10:00:45 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
   Visit http://axiom-developer.org for more information
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase

rrogers@raymond-desktop-Ubuntu:~$ axiom
                        AXIOM Computer Algebra System 
                          Version: Axiom (May 2012)
                Timestamp: Tuesday July 30, 2013 at 10:00:45 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
   Visit http://axiom-developer.org for more information
-----------------------------------------------------------------------------
 
   Re-reading compress.daase   Re-reading interp.daase
   Re-reading operation.daase
   Re-reading category.daase
   Re-reading browse.daase

(1) -> 
(1) -> a:=34
(1) -> 
   (1)  34
                                                        Type: PositiveInteger
(2) -> a
(2) -> 
   (2)  34
                                                        Type: PositiveInteger

(3) -> )savesystem foo
(3) -> 

rrogers@raymond-desktop-Ubuntu:~$ 
rrogers@raymond-desktop-Ubuntu:~$ ls -l ./foo
-rwxrwxr-x 1 rrogers rrogers 30296240 Dec 13 14:58 ./foo
## That is the correct time --Ray

rrogers@raymond-desktop-Ubuntu:~$ ./foo
                        AXIOM Computer Algebra System 
                          Version: Axiom (May 2012)
                Timestamp: Tuesday July 30, 2013 at 10:00:45 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
   Visit http://axiom-developer.org for more information
-----------------------------------------------------------------------------
 
(1) -> a

   (1)  a
                                                            Type: Variable(a)
(2) -> 





--------------050804080805080908060606--

\start
Date: Sun, 14 Dec 2014 04:21:13 -0600
From: daly@axiom-developer.org
To: Raymond Rogers <raymond.rogers72@gmail.com>
Subject: [Axiom-developer] read the docs

Raymond,

I've managed to reproduce the problem on a MAC build.
I don't know the cause yet. It seems to be related to 
the GCL savesystem but I'm not sure. In any case, I
will open a bug report to follow it up.

Tim

\start
Date: Mon, 15 Dec 2014 03:55:45 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Lisp function signatures

The lisp code is being enhanced with function signatures.

In addition, the list of all signatures, with page numbers is included 
as a separate compilation at the end of the document. For instance,

115 set-restart-hook : Void -> 'restart

131 intloopReadConsole : (String Integer) -> Throw

137 intloopPrefix? : String -> Union(String,NIL)

139 intloopProcessString : (String,StepNo) -> StepNo

140 next : (Function,Delay) -> Delay

140 next1 : Delay -> ParsePair

141 incString : String -> Function

144 setCurrentLine : String -> List(String)

144 mkprompt : Void -> String

146 serverReadLine : Stream -> String

167 intloopProcess : (StepNo,Boolean,Delay) -> StepNo

177 incRenumber : Delay -> Delay

177 incZip : (Function,Delay,Delay) -> Delay

177 incZip1 : Delay -> ParsePair

178 incIgen : Integer -> Delay

180 incLude : (Int,List(String),Int,List(String),List(Int) -> Delay

204 incCommand? : String -> Boolean

207 Delay : (Function,List(Any)) -> Delay

441 StreamNull : Delay -> Union(T,NIL)

\start
Date: Mon, 15 Dec 2014 16:20:15 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] GPLv2 goes to court

http://opensource.com/law/14/7/lawsuit-threatens-break-new-ground-gpl-and-software-licensing-issues

This should be interesting to watch. It involves GPLv2, copyright
conditions vs covenant, "distribution to independent contractors" vs
"independent contractors are employees", and patents.

My reading of the docs leads me to bet that, on the conditions vs
covenant topic, the 'conditions' apply and there is copyright
infringement, possibly throwing it back into federal court.

On the "distribution to independent contractors" (triggering the
distribution clause) vs "independent contractors are employees"
(not a distribution) it seems that Ameriprise does not provide
independent contractors with an office, phone, or benefits so
they would not be considered employees. Thus, Ameriprise would
likely have "distributed" the software. 

The patent issue is too complex for me to even make a guess.
I'm not sure I even understand the concept of a software patent.

Anyway, in my opinion, Ameriprise is likely to lose.

But, in case it is not obvious, I'm not a lawyer.

Tim

\start
Date: Mon, 15 Dec 2014 16:28:35 -0600
From: daly@axiom-developer.org
To: patAxiom@first.in-berlin.de
Subject: Re: [Axiom-developer] A Critique of the Mathematical Abilities of
	CA Systems

Thanks for the pointer.

Axiom has the examples from this paper as part of the unit test suite.
See src/input/wester.input.pamphlet

Tim

\start
Date: Mon, 15 Dec 2014 16:28:42 -0600
From: daly@axiom-developer.org
To: panAxiom@first.in-berlin.de
Subject: Re: [Axiom-developer] A Critique of the Mathematical Abilities of
	CA Systems

Thanks for the pointer.

Axiom has the examples from this paper as part of the unit test suite.
See src/input/wester.input.pamphlet

Tim

\start
Date: Mon, 15 Dec 2014 17:19:08 -0600
From: daly@axiom-developer.org
To: panAxiom@first.in-berlin.de
Subject: Re: [Axiom-developer] A Critique

I see that Michael has provided the output files with the
expected results on his web page link.

I will use this and turn it into a section of the Computer Algebra
Test Suite.

Tim

\start
Date: Tue, 16 Dec 2014 08:31:16 +0100
From: Ralf Hemmecke <ralf@hemmecke.org>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] GPLv2 goes to court

On 12/15/2014 11:20 PM, daly@axiom-developer.org wrote:
> http://opensource.com/law/14/7/lawsuit-threatens-break-new-ground-gpl-and-software-licensing-issues

What exactly does that have to do with Axiom?

> On the "distribution to independent contractors" (triggering the
> distribution clause) vs "independent contractors are employees"
> (not a distribution) it seems that Ameriprise does not provide
> independent contractors with an office, phone, or benefits so
> they would not be considered employees. Thus, Ameriprise would
> likely have "distributed" the software. 

IANAL, but the software is re-distributed even in the case that an
employer gives it to its employees under the GPL. Now an employee has to
right to get the sources. He also has the right (under GPL) to
redistribute. Well, this might conflict with his contract with the
employer, so the employee might choose not to re-distribute the software
any further. If one receives GPL software, there is no obligation to
redistribute it. GPL only applies if one starts a distribution.

Anyway, GPLv3 probably makes things clearer also with respect to law in
other countries.

Lawyers can make things sooo complicated.

Ralf

\start
Date: Tue, 16 Dec 2014 02:34:06 -0600
From: daly@axiom-developer.org
To: "Ralf Hemmecke" <ralf@hemmecke.de>
Subject: [Axiom-developer] GPLv2

> What does this have to do with Axiom?

License discussions arise from time to time. We have a long email
history in Axiom discussing licensing.

This is the first court case involving the GPL that has not (yet)
settled out of court. Licensing and copyright law, at least in the
U.S., depends on a body of court cases to shape their validity in
practice. So the judgments in this case, assuming it goes to trial,
will define a lot about what the GPL means, what parts are vital,
what parts can be enforced, and what remedies are available.

As for the employee issue, at least in the U.S., software is generally
licensed to the corporation, not to the individual employee. Use by
an employee would not be considered distribution and an employee would
not have redistribution rights. However, as I looked into the details,
it seems that Ameriprise licenses their "brand name" to individuals but
those individuals are "1099" paid contractors, not employees. 

A 1099 contractor is an independent entity. I do 1099 contract work
under my own company ("Literate Software") so this would constitute
distribution to an independent firm that only holds a brand-name
license.

It is even more interesting because apparently Ameriprise modifies
the GPL software using contract programmers. Will the judge enforce
releasing Ameriprise intellectual property? Or will he strike down
that portion as non-essential? Licenses and contracts usually have 
"severance clauses" which allow partial enforcement (all of my
Literate Software contracts have had one). Will he enforce release
or simply provide relief by stopping distribution?

I see the severance clause in GPLv2

   If any portion of this section is held invalid or unenforceable
   under any particular cirumstance, the balance of the section is
   intended to apply and the section as a whole is intended to apply
   in other circumstances.

so the judge can "cut up the GPLv2" and only partially enforce it.

GPLv3, according to my reading, seems to have deleted that clause
which would mean that any flaw invalidates the whole license. That's
a pretty big bet for a license that has never been enforced by the 
court and has no prior case law.

I really wish Groklaw was still active. This is going to be fun to watch.
Pass the popcorn.

Tim

\start
Date: Tue, 16 Dec 2014 10:21:10 +0100
From: Ralf Hemmecke <ralf@hemmecke.org>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] GPLv2

On 12/16/2014 09:34 AM, daly@axiom-developer.org wrote:
>> What does this have to do with Axiom?
> 
> License discussions arise from time to time. We have a long email
> history in Axiom discussing licensing.

OK. ;-)

> This is the first court case involving the GPL that has not (yet)
> settled out of court.

Maybe in the US. But there have been cases in Germany.

http://en.wikipedia.org/wiki/Gpl-violations.org

> As for the employee issue, at least in the U.S., software is generally
> licensed to the corporation, not to the individual employee.

Wow! Actually, I don't know the exact situation in Germany, but what I
wrote was something that I read somewhere some years ago and it made
perfectly sense to me.

Nevertheless. "Copyright" in Germany is not existing in the american
sense. Rather, there is "Urheberrecht" and "Nutzungsrecht". Under German
law, I cannot give away the "Urheberrecht" (because "Urheber" means
"creator" and that right is bound to an individual). That basically
means I cannot legally put something into the public domain.
Per default the creator of a work (i.e. the Urheber) has the exclusive
Nutzungsrecht (i.e., right to use/copy/modify/distribute/...) of the
work in question, but, of course, if the work has been produced inside a
company, then the exclusive "Nutzungsrecht" usually immediately falls
into the hands of the company. And that means that the creator of some
work is not allowed to distribute his own work without consent of the
company. Well, that's of course reasonable, if the company pays this
employee.

Anyway, German law, is a bit different from US law.

If everyone would play nice, there wouldn't be need to spend a lot of
time into such legal issues and we could concentrate on real work and
release it under a free license.

Ralf

\start
Date: Tue, 23 Dec 2014 05:45:46 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] project update

Progress has been made on many fronts in the last week.

Most of the time was spent on the Interpreter (volume 5). The most
significant long term change is adding signatures to the lisp code and
a separate Signatures chapter which contains backlinks to the
functions. A complete collection of all missing references now exists
so the next round of work can add the missing code.

I rebuilt my hardware and now have a new Jenkins dedicated disk. I
spent time creating VirtualBox instances of many distros so they can
be used in the automated build.

The other major effort involved starting another computer algebra test
suite (CATS) based on Wester's published test cases. Unlike the other
CATS suites (integration, differential equations, graphics), this one
ranges across many areas of Axiom.

Tim


=======================================================================

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom continuous integration
-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
  * The jenkins server now has private disk space.
  * Built individual virtualbox images for many distros.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom Burge recursive parser
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Got a copy of Recursive Programming Techniques by Burge

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom Charybdis
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Read the Charybdis paper

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom src/interp cleanup
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Started rewrite into standard common lisp syntax (from machine syntax)
  * Removed |function| macro globally.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom interpreter merge
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Complete review of Volume 5, noting all of the missing references. 
  * Started adding missing references.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom CATS expansion
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Adding Wester test suite as published at
    http://math.unm.edu/~wester/cas_review.html

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom buglist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * Add )savesystem restore failure to buglist

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom books
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * treeshake missing references
  * added a Signatures chapter to the Axiom Interpreter volume
  * added signatures of some lisp functions
  * clean up the defvar syntax

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Axiom interpreter
-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  * )quit now defaults to immediate quit

\start
Date: Wed, 24 Dec 2014 20:31:24 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: fricas-devel@googlegroups.com,
	Axiom-Developer <axiom-developer@nongnu.org>,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards

Ralf is only telling it as it is,
but I wish I could be even as pessimistic as him.

This is a crisis disguised as another documentation squabble.
As I see the status of PanAxiom:

OpenAxiom - One developer - little to no activity = dead branch.
FriCAS    - One developer - one developer - system being devolved.
Axiom     - One developer - when he goes Axiom goes.

The basic issue that I see is that PanAxiom is really a
software engineering project before it can continue to live.
It brings to mind the Whirlwind project that turned the
early hacked-up computer-like light-bulb testers into
engineering standard replicable devices and spawned an industry.
A significant part its development was thoroughly documenting
what it did and how it did it.

 From the posts over the last year or so, I get these messages:

Even minimal documentation efforts may either hard to start or
will be too much bother with to add or maintain. Besides who needs it?
As one young lady that I had set to maintaining a large system
with many undocumented changes to it said:
"I didn't know I needed to know archeology."

The literate approach that Knuth created has no answer to
mass of existing code problem: that is, he didn't think out
a mechanism for the curious to dynamically add insights to
the system's code even if literate.  Inverses are sooo.. hard.

Oh, and PanAxiom has no systematic development of basic numerology.

Xmas, Gene



On 12/24/2014 1:24 PM, Martin Baker wrote:
> On 24/12/14 18:12, Ralf Hemmecke wrote:
>  > It's open source development so I don't have to agree with you and can
>  > choose to invest my time into something that doesn't make me unhappy.
>
> I strongly agree with Ralf on this documentation issue.
>
> Martin
>

\start
Date: Thu, 25 Dec 2014 00:40:43 -0600
From: daly@axiom-developer.org
To: surow@attglobal.net
Subject: [Axiom-developer] documenation standards
Cc: axiom-developer@nongnu.org, fricas-devel@googlegroups.com,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>

Eugene,

I only have an official position on Axiom. 

> The basic issue that I see is that PanAxiom is really a
> software engineering project before it can continue to live.

Making Axiom "live" is the WHOLE point of the Literate Programming effort.

Currently you need have a deep knowledge of computation, mathematics,
Spad, and Lisp to use Axiom efficiently. Axiom needs to communicate
ideas behind those implementations at all levels so that it can be
maintained and modified.

If you just want a copy of the system for your own use then there
is no reason to bother with natural language. When you stop then
your work dies. Exactly zero people care.





> A significant part its development was thoroughly documenting
> what it did and how it did it.

And "WHY" it was done. Even with my own code, after 20 years,
I know WHAT I did and HOW I did it. I can even tell you what
bytes the compiler will lay down in memory.... I just don't
remember "WHY", only that if I remove it the system breaks.

Axiom isn't trying to "document", it is trying to COMMUNICATE ideas
from human to human. This is NOT a subtle difference. When you read
a physics textbook the natural language paragraphs explain the ideas,
not the equations. Imagine how useless a physics textbook would be
if all you had was a book of equations.

Source code is equations. Axiom is trying to write the text
surrounding the equations.

The literate programming focus is for the next generation, people we
will never meet who want to maintain, modify, and extend the system.
People die (Jenks, Bronstein, Sundarasan), which makes it hard to 
get answers. 

Writing new source code without a full explanation just makes the
same fundamental mistake the Axiom team made in the last century.
In our defense, we were doing research, not product development.

Now we have the benefit of hindsight and the prospect of a future.
New "source code equations" need to have the paragraphs that
communicate the ideas.

Writing the ideas is tedious but it is MUCH harder to reverse engineer
the ideas from the equations, if it can be done at all. A lot of the
details in Spad code exist nowhere in the literature. Theory papers
rarely explain how to cons up an s-expression and funcall it to
dynamically compute the result.

Axiom is trying to set professional quality standards for computational 
mathematics software based on COMMUNICATION with future computational 
mathematicians, developers, and users.

The "gold standard" form of Axiom can be found in the book
"Physically Based Rendering" by Pharr and Humphries. When Axiom
looks like that we will have achieved a minimum professional
standard for Axiom as computational mathematics.




> Even minimal documentation efforts may either hard to start or
> will be too much bother with to add or maintain. Besides who needs it?

Axiom has about 1.2 million lines of code. It has taken years, so far,
just to organize, hyperlink, index, and automate. The "minimal
documentation effort" has been massive but progress is being made.
There are still 200,000 lines of code to rewrite and merge which
will consume most of next year, at minimum.

Nobody currently needs documentation. But documentation is part
of being a software professional. Quality software is easy to
understand, easy to use, and has "to the point" documentation.

Axiom is expanding the available documentation. There are more
)help files, there are now code examples shown with )d op responses,
there are full hypertext index lookups in each book, there are input 
files in specific areas (e.g. Hamiltonian Biquaternions, the Cohen 
algebra with references to the book, database query language 
example, etc.), with more to come.

There is a book outlining related theory that is being organized
with hyperlinks to the related algebra. There are SVG graphs with
hyperlinks to the algebra. There are hyperlinks within the algebra
to other categories, domains, or packages used. There is a website
with historical papers that will eventually be hyperlinked from
the current bibliography book.

There is a computer algebra test suite based on published books
that show Axiom being used and tested by outside literature.

So there is a "documentation" effort as well as a literate
programming effort. 



> "I didn't know I needed to know archeology."

Charybdis is the equation output formatting program from the
1960s. The zipper parser for algebra input is a research effort from
the 70s. The type system is inspired by Sammet's Modula and other
early ideas. What was cutting edge research 50 years ago is now
archeology. What is cutting edge research now will be archeology in 50
years, assuming the work is written up and published.




> The literate approach that Knuth created has no answer to
> mass of existing code problem: that is, he didn't think out
> a mechanism for the curious to dynamically add insights to
> the system's code even if literate.  Inverses are sooo.. hard.

Last month I attended a Knuth talk. I asked him about literate
programming. He said that he believed he could not have written
the MMIX simulator without it because it was too complex for him.
He considers literate programming to be one of his most important ideas.

Knuth has the luxury of writing literate programs from scratch. We
have the horror of understanding "source code equations", reverse
engineering the ideas, and the communicating that understanding in
natural language.

I believe literate programming is the only tool that can make software
live, especially complex software like Axiom.

If Axiom is going to live, it must be done... 
I want Axiom to live. Therefore...

Tim

\start
Date: Fri, 26 Dec 2014 16:32:22 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: daly@axiom-developer.org
Subject: Re: [Axiom-developer] documenation standards

Well said.

My own general interest resides in mechanisms that
could possibly reduce the entry-effort price.

Now that I gave World Scientific the OK to
go to print with "Einstein's Apple", I'm getting
some free time to resume exploring some ideas.

Cheers, Gene

On 12/25/2014 1:40 AM, daly@axiom-developer.org wrote:
> Eugene,
>
> I only have an official position on Axiom.
>
>
>
>
>> The basic issue that I see is that PanAxiom is really a
>> software engineering project before it can continue to live.
>
> Making Axiom "live" is the WHOLE point of the Literate Programming effort.
>
> Currently you need have a deep knowledge of computation, mathematics,
> Spad, and Lisp to use Axiom efficiently. Axiom needs to communicate
> ideas behind those implementations at all levels so that it can be
> maintained and modified.
>
> If you just want a copy of the system for your own use then there
> is no reason to bother with natural language. When you stop then
> your work dies. Exactly zero people care.
>
>
>
>
>
>> A significant part its development was thoroughly documenting
>> what it did and how it did it.
>
> And "WHY" it was done. Even with my own code, after 20 years,
> I know WHAT I did and HOW I did it. I can even tell you what
> bytes the compiler will lay down in memory.... I just don't
> remember "WHY", only that if I remove it the system breaks.
>
> Axiom isn't trying to "document", it is trying to COMMUNICATE ideas
> from human to human. This is NOT a subtle difference. When you read
> a physics textbook the natural language paragraphs explain the ideas,
> not the equations. Imagine how useless a physics textbook would be
> if all you had was a book of equations.
>
> Source code is equations. Axiom is trying to write the text
> surrounding the equations.
>
> The literate programming focus is for the next generation, people we
> will never meet who want to maintain, modify, and extend the system.
> People die (Jenks, Bronstein, Sundarasan), which makes it hard to
> get answers.
>
> Writing new source code without a full explanation just makes the
> same fundamental mistake the Axiom team made in the last century.
> In our defense, we were doing research, not product development.
>
> Now we have the benefit of hindsight and the prospect of a future.
> New "source code equations" need to have the paragraphs that
> communicate the ideas.
>
> Writing the ideas is tedious but it is MUCH harder to reverse engineer
> the ideas from the equations, if it can be done at all. A lot of the
> details in Spad code exist nowhere in the literature. Theory papers
> rarely explain how to cons up an s-expression and funcall it to
> dynamically compute the result.
>
> Axiom is trying to set professional quality standards for computational
> mathematics software based on COMMUNICATION with future computational
> mathematicians, developers, and users.
>
> The "gold standard" form of Axiom can be found in the book
> "Physically Based Rendering" by Pharr and Humphries. When Axiom
> looks like that we will have achieved a minimum professional
> standard for Axiom as computational mathematics.
>
>
>
>
>
>> Even minimal documentation efforts may either hard to start or
>> will be too much bother with to add or maintain. Besides who needs it?
>
> Axiom has about 1.2 million lines of code. It has taken years, so far,
> just to organize, hyperlink, index, and automate. The "minimal
> documentation effort" has been massive but progress is being made.
> There are still 200,000 lines of code to rewrite and merge which
> will consume most of next year, at minimum.
>
> Nobody currently needs documentation. But documentation is part
> of being a software professional. Quality software is easy to
> understand, easy to use, and has "to the point" documentation.
>
> Axiom is expanding the available documentation. There are more
> )help files, there are now code examples shown with )d op responses,
> there are full hypertext index lookups in each book, there are input
> files in specific areas (e.g. Hamiltonian Biquaternions, the Cohen
> algebra with references to the book, database query language
> example, etc.), with more to come.
>
> There is a book outlining related theory that is being organized
> with hyperlinks to the related algebra. There are SVG graphs with
> hyperlinks to the algebra. There are hyperlinks within the algebra
> to other categories, domains, or packages used. There is a website
> with historical papers that will eventually be hyperlinked from
> the current bibliography book.
>
> There is a computer algebra test suite based on published books
> that show Axiom being used and tested by outside literature.
>
> So there is a "documentation" effort as well as a literate
> programming effort.
>
>
>
>> "I didn't know I needed to know archeology."
>
> Charybdis is the equation output formatting program from the
> 1960s. The zipper parser for algebra input is a research effort from
> the 70s. The type system is inspired by Sammet's Modula and other
> early ideas. What was cutting edge research 50 years ago is now
> archeology. What is cutting edge research now will be archeology in 50
> years, assuming the work is written up and published.
>
>
>
>
>> The literate approach that Knuth created has no answer to
>> mass of existing code problem: that is, he didn't think out
>> a mechanism for the curious to dynamically add insights to
>> the system's code even if literate.  Inverses are sooo.. hard.
>
> Last month I attended a Knuth talk. I asked him about literate
> programming. He said that he believed he could not have written
> the MMIX simulator without it because it was too complex for him.
> He considers literate programming to be one of his most important ideas.
>
> Knuth has the luxury of writing literate programs from scratch. We
> have the horror of understanding "source code equations", reverse
> engineering the ideas, and the communicating that understanding in
> natural language.
>
> I believe literate programming is the only tool that can make software
> live, especially complex software like Axiom.
>
> If Axiom is going to live, it must be done...
> I want Axiom to live. Therefore...
>
> Tim

\start
Date: Fri, 26 Dec 2014 23:23:31 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Software Checklists and Quality

I took flying lessons. My instructor was a complete fanatic about
checklists. I learned their value in that context. For example,

   Landing Checklist: Wheels down and locked?

Checklists matter a LOT. People do forget.

It never occurred to me that they could be applied to programming.
This article
  http://www.solipsys.co.uk/new/SoftwareChecklist.html
expresses the idea that they ought to be applied in software.

There is a nugget of the checklist idea in the regression tests
but it isn't fully formed and reified as "checklisting". Some of
them are encoded in Makefiles but not in an explicit form.

Years ago I started a "release checklist" to make sure I did all of
the steps necessary to pre-check a new release. I thought of checklist
as a crutch for my bad memory rather than an encoding of knowledge.
I'm now trying to encode the list into a continuous integration system.

Given the blog post, I feel that the idea of an explicit effort of
creating, maintaining, and automating checklists could do a lot to
improve the quality of Axiom.

Comments?

Tim

\start
Date: Sat, 27 Dec 2014 16:44:16 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: fricas-devel@googlegroups.com,
	Axiom-Developer <axiom-developer@nongnu.org>,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards

Waldek: Thank you for providing this explanation of
your viewpoint and experiences that motivate it.
Up until now I was baffled by what you seemed to be doing.

It seems clear the kind of support mechanism(s) that
a code complex like PanAxiom needs must be very dynamically
adaptable at a keystroke level to include/exclude
commentary or consult widely separated code fragments
with near instant locate and display.
Do you agree?

Cheers, Gene

On 12/26/2014 11:02 PM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>> On 12/22/2014 12:42 AM, Waldek Hebisch wrote:
>>> AFAICS this was not a derivation.  The line
>>>
>>>          concat(frst(f1), rst(f1) + p1 + concat(rpSt(n, 0), f1*p1))
>>>
>>> is a recursive formula written using Spad.
>>
>> How many people know what rpSt is?
>
> Those who look up definition and specification:
>
>    -- rpSt(z, s) is a stream of length z each of whose entries is s
>>
>>> ...
>>> Derivation is simple, so it is better to omit it (as I and _you_
>>> did) -- reader can easily reconstruct it.
>>
>> If you believe it was easy without the knowledge of the specification of
>> prodiag1, then either you are wrong or I am stupid.
>
> I am affraid that we are using different language.  In my language
> specification says what a function is supposed to compute.  Now:
>
>      -- prodiag1([f_n, ...], n) computes
>      -- ((1 + z^n*f_n)*(1 + z^{n+1}*f_{n+1})... - 1)/z^n
>      prodiag1(ststa : ST ST A, n : Integer) : ST(A) == ...
>
> says you exactly what 'prodiag1' should compute, so for me
> it is specification.
>
>> I felt like
>> needlessly wasting my time over this. And you even did not commit my
>> comments that IMHO would help others to waste less time.
>
> You wanted to have:
>
> 1   -- Let f = [f_1, f_2, f_3, ...] be a stream of streams of coefficients
> 2   -- of Taylor series. We tacitly identify a stream of coefficients with
> 3   -- a Taylor series in the variable z.
> 4   -- Let h(s), t(s) be the head and tail of a stream s, respectively.
> 5   -- Let p(s, n) be recursively defined by:
> 6   -- p(s, n) = (1+z^n*h(s)*p(t(s), n+1).
> 7   -- Then p(f, 1) gives the infinite product
> 8   -- p(f, 1) = (1+z*f_1)*(1+z^2*f_2)*(1+z^3*f_3)*...
> 9   -- Let q(s, n) be defined by: p(s, n) = 1 + z^n*q(s, n).
> 10  -- Then we get the following recursion formula for q.
> 11  -- q(s, n) = h(f1) + z*(r1 + q1 + z^n*f1*q1)
> 12  --           where
> 13  --              f1 = h(s)
> 14  --              r1 = t(s)
> 15  --              q1 = q(r1, n+1)
> 16   prodiag1(ststa : ST ST A, n : Integer) : ST(A) == delay
> 17      empty? ststa => zro()
> 18      f1 := frst ststa  -- head
> 19      r1 := rst ststa   -- tail
> 20      p1 := prodiag1(r1, n + 1)
> 21      empty? f1 => concat(0, p1)
> 22      concat(frst(f1), rst(f1) + p1 + concat(rpSt(n, 0), f1*p1))
>
> Now, comments on line 18 and 19 are texbook example of bad
> comments, they just restate what code is doing without
> adding any insight.  Lines 1-5 besides repeating what should
> be already known from comment to STTAYLOR:
>
> ++ Description:
> ++   StreamTaylorSeriesOperations implements Taylor series arithmetic,
> ++   where a Taylor series is represented by a stream of its coefficients.
>
> just introduce notation.  Line 6 is the specification.  I dare
> to say that two line specification I gave is at least as
> readable as the above specification and has advantage of
> beeing shorter.  Lines 7 and 8 may help if one insists
> on your previous lines, but since I explicitely specify
> prodiag1 as infinite product specialization to n = 1
> becames obvious.  I believe that for _you_ your explanation
> looks clearer: simply it "resonates" with you understanding
> of the subject.  But for unbiased reader the two line form
> has advantege of immediately presenting important part
> without burdening short term memory with unimportant
> details.  Finally, lines 9-15 repeat what code is doing
> but in different notation.
>
>>> This kind of comments help if reader is unfamiliar with Spad,
>>> but otherwise just adds bulk to the file.  Bulk is bad because
>>> every reader will spent more time reading and internalizing
>>> what was written.
>>
>> IMHO, this is wrong. Knowing SPAD is rather unimportant. What counts is
>> the mathematical background and the kind of algorithm that is used. And
>> that is missing and is tacitly hidden inside the SPAD code.
>>
>>> Note: I expect that active and interested
>>> reader will re-derive the formula.  Adding more detail will
>>> not help and may hurt turning the reade to "passive mode".
>>
>> Well, you expect every potential new developer to invest much time, so
>> you basically treat them as if they were your students. Can you count
>> how many active developer FriCAS has? I would have counted me as one,
>> but then the above tells me the I am required to waste my time. Why
>> would I want to do that? It's totally ineffective and frustrating. It's
>> not freely sharing knowledge.
>
> I am sad that you consider analyzing code to be waste of time.
> For me it is normal part of developement work.  I need to modify
> some routine I read it and as needed releated code.  IME just
> using documetation is frequently inadequte: I looking for things
> not considered by original developers.  Since they did not
> consider them writing code they could not document them.
> Yes, such analyzis takes some effort.  IME most of effort
> goes into filtering out irrelevant datails.  Now, you
> want to replace 9 lines that I commited by 22 lines.  This
> more than doubles amount of material that I need to scan
> and filter out.
>
> Using "literate" analogy: FriCAS code is research level, analogous
> to research paper or a monograph.  From readers of such works
> one expects some background knowledge and familiarity with
> notation.  Readers of a monograpth when faced with unfamilar
> notation are supposed to look it up in an index.  Similarely
> readear of 'prodiag1' are supposed to look up 'rpSt'.  A lot
> of formulas is supposed to be easy enough so that readers
> will know them or provide own proof.  Now, if one wants to
> make a subject more accessible it is not done by "simplifing"
> research papers.  Rather, it is done via creation of
> additional training material.
>
> Coming back to 'prodiag1'.  You say that you wasted time.
> Did you spent more than 15 minutes on it?  I consider 15
> to be generous estimate of time needed to derive formulas
> in use.  Normally when seeing routine as 'prodiag1' I
> consider it simple enough and assume that the author did
> it right, so I would go other it essentially in time needed
> to read it (this is why 22 lines versus 9 hurt!).  When
> I just want to know details I consider the 15 minutes
> not as waste but as time well spent.  When I have
> reasons to belive that routine is incorrect or I need
> to modify it, then IMO 15 minutes is fully justified
> and unavoidable: if I can not believe the author I need
> to check everthing with due care.  In particular it is
> better to derive formula second time because otherwise
> documentation may fool me to commit the same error that
> the author did.  Note that on complicated projects
> frequently cited norm is 10 lines a day.  According to
> such norm 'prodiag' would be worth more than half a day,
> so there is "budget" to come back to it few times.
>
>>
>> I guess, it would be better to lower the barrier to enter FriCAS
>> development rather than requiring new people to deeply dive into SPAD
>> code and to analyse what the code actually does even if they certainly
>> come with zero knowledge of the library but know the SPAD keywords.
>>
>>> To put is differently: your addition would be good in a
>>> tutorial.
>>
>> ... that nobody will ever write...
>>
>
> I think that probablity of somebody writing a tutorial is larger
> than probabilty that a newcomer to FriCAS would like to
> look at 'prodiag1'.
>
>>> But I bet that reader facing substantial amount
>>> of code with such documentation will quickly give up
>>> due to bulk of text to read.
>>
>> How many people have you met that tell you this? You must have knowledge
>> of a big FriCAS community that I haven't heard of.
>
> Well, I had a lot of contact with user of our local computer
> network.  I also spent some time on various support lists.
> In case of systems that had a lot of documentation typical
> pattern was like:
>
> Q: Is there any documentation?
> A: Here it is.
> Q: That is soo long. Do you have something shorter?
>
> On programming fora for requests to shorten text are
> quite frequent.
>
> FriCAS community is small, but I have no reason to think
> that it is different than general programmer population.
>
>>> When I was teaching introductory programming course given task
>>> "turn this formula(s) into code" or even "what this piece
>>> of code is doing" students did quite well.
>>
>> I have yet to see someone who can tell, what exactly the following
>> Mathematica program computes and whether this program is correct.
>>
>>    foo[a_, b_] := (
>>        If[a > 0,
>>            If[TrueQ[a > b], Return[foo[b, a]]];
>>            Return[foo[b-a, a]]
>>        ];
>>        Return[b]
>>    );
>
> I have only little Mathematica knowledge.  But this looks
> like correct routine to compute GCD of nonnegative integers.
> Mathematica is untyped so it may return useful results
> if a and b are elements of an orderd group isomorphic
> with integers.  It fails to terminate when a and b
> are positive but not comeasurable, so it makes little
> sense to consider it on significantly bigger domains.  AFAICS
> the main unknown is domain of foo.  In case of Spad types
> significantly limit possible domains.
>

\start
Date: Sat, 27 Dec 2014 16:24:16 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: axiom-developer@nongnu.org, fricas-devel <fricas-devel@googlegroups.com>, 
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>
Subject: Re: [Axiom-developer] Software Checklists and Quality

Once upon a time in the land of HAL,
I had to nursemaid thirty systems that were to be
kept or brought up to a common level.
Since they had to intercommunicate,
level differences were not tolerable.

There was a multi-page list of procedure steps,
to be performed in sequence but was never called a checklist.

The most important thing experienced was that the steps
could never be followed in exactly the same way two times in a row.
Each update would vary something that required updating
and modifying the list.  Not the pilot's type of list.

But it did perform a form of knowledge capture and enabled
bring other people into the fold, which I think is what we
would like to do.

Cheers, Gene


On 12/27/2014 12:23 AM, daly@axiom-developer.org wrote:
> I took flying lessons. My instructor was a complete fanatic about
> checklists. I learned their value in that context. For example,
>
>     Landing Checklist: Wheels down and locked?
>
> Checklists matter a LOT. People do forget.
>
> It never occurred to me that they could be applied to programming.
> This article
>    http://www.solipsys.co.uk/new/SoftwareChecklist.html
> expresses the idea that they ought to be applied in software.
>
> There is a nugget of the checklist idea in the regression tests
> but it isn't fully formed and reified as "checklisting". Some of
> them are encoded in Makefiles but not in an explicit form.
>
> Years ago I started a "release checklist" to make sure I did all of
> the steps necessary to pre-check a new release. I thought of checklist
> as a crutch for my bad memory rather than an encoding of knowledge.
> I'm now trying to encode the list into a continuous integration system.
>
> Given the blog post, I feel that the idea of an explicit effort of
> creating, maintaining, and automating checklists could do a lot to
> improve the quality of Axiom.
>
> Comments?
>
> Tim

\start
Date: Sun, 28 Dec 2014 10:48:26 -0800
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: surow@attglobal.net
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards
Cc: fricas-devel@googlegroups.com,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>,
	Axiom-Developer <axiom-developer@nongnu.org>

--089e014940aefbecfa050b4b3300
Content-Type: text/plain; charset=UTF-8

On Wed, Dec 24, 2014 at 5:31 PM, Eugene Surowitz <surow@attglobal.net>
wrote:

> Ralf is only telling it as it is,
> but I wish I could be even as pessimistic as him.
>
> This is a crisis disguised as another documentation squabble.
> As I see the status of PanAxiom:
>
> OpenAxiom - One developer - little to no activity = dead branch.
>

Not really -- but YMMV.


> FriCAS    - One developer - one developer - system being devolved.
> Axiom     - One developer - when he goes Axiom goes.
>
> The basic issue that I see is that PanAxiom is really a
> software engineering project before it can continue to live.
> It brings to mind the Whirlwind project that turned the
> early hacked-up computer-like light-bulb testers into
> engineering standard replicable devices and spawned an industry.
> A significant part its development was thoroughly documenting
> what it did and how it did it.
>
> From the posts over the last year or so, I get these messages:
>
> Even minimal documentation efforts may either hard to start or
> will be too much bother with to add or maintain. Besides who needs it?
> As one young lady that I had set to maintaining a large system
> with many undocumented changes to it said:
> "I didn't know I needed to know archeology."
>
> The literate approach that Knuth created has no answer to
> mass of existing code problem: that is, he didn't think out
> a mechanism for the curious to dynamically add insights to
> the system's code even if literate.  Inverses are sooo.. hard.
>
> Oh, and PanAxiom has no systematic development of basic numerology.
>
> Xmas, Gene
>
>
>
>
> On 12/24/2014 1:24 PM, Martin Baker wrote:
>
>> On 24/12/14 18:12, Ralf Hemmecke wrote:
>>  > It's open source development so I don't have to agree with you and can
>>  > choose to invest my time into something that doesn't make me unhappy.
>>
>> I strongly agree with Ralf on this documentation issue.
>>
>> Martin
>>

--089e014940aefbecfa050b4b3300
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Dec 24, 2014 at 5:31 PM, Eugene Surowitz <span dir=3D"ltr">&lt;=
<a href=3D"mailto:surow@attglobal.net" target=3D"_blank">surow@attglobal.ne=
t</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ralf is only tell=
ing it as it is,<br>
but I wish I could be even as pessimistic as him.<br>
<br>
This is a crisis disguised as another documentation squabble.<br>
As I see the status of PanAxiom:<br>
<br>
OpenAxiom - One developer - little to no activity =3D dead branch.<br></blo=
ckquote><div><br></div><div>Not really -- but YMMV.</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
FriCAS=C2=A0 =C2=A0 - One developer - one developer - system being devolved=
.<br>
Axiom=C2=A0 =C2=A0 =C2=A0- One developer - when he goes Axiom goes.<br>
<br>
The basic issue that I see is that PanAxiom is really a<br>
software engineering project before it can continue to live.<br>
It brings to mind the Whirlwind project that turned the<br>
early hacked-up computer-like light-bulb testers into<br>
engineering standard replicable devices and spawned an industry.<br>
A significant part its development was thoroughly documenting<br>
what it did and how it did it.<br>
<br>
>From the posts over the last year or so, I get these messages:<br>
<br>
Even minimal documentation efforts may either hard to start or<br>
will be too much bother with to add or maintain. Besides who needs it?<br>
As one young lady that I had set to maintaining a large system<br>
with many undocumented changes to it said:<br>
&quot;I didn&#39;t know I needed to know archeology.&quot;<br>
<br>
The literate approach that Knuth created has no answer to<br>
mass of existing code problem: that is, he didn&#39;t think out<br>
a mechanism for the curious to dynamically add insights to<br>
the system&#39;s code even if literate.=C2=A0 Inverses are sooo.. hard.<br>
<br>
Oh, and PanAxiom has no systematic development of basic numerology.<br>
<br>
Xmas, Gene<br>
<br>
<br>
<br>
<br>
On 12/24/2014 1:24 PM, Martin Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 24/12/14 18:12, Ralf Hemmecke wrote:<br>
=C2=A0&gt; It&#39;s open source development so I don&#39;t have to agree wi=
th you and can<br>
=C2=A0&gt; choose to invest my time into something that doesn&#39;t make me=
 unhappy.<br>
<br>
I strongly agree with Ralf on this documentation issue.<br>
<br>
Martin<br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Axiom-developer mailing list<br>
<a href=3D"mailto:Axiom-developer@nongnu.org" target=3D"_blank">Axiom-devel=
oper@nongnu.org</a><br>
<a href=3D"https://lists.nongnu.org/mailman/listinfo/axiom-developer" targe=
t=3D"_blank">https://lists.nongnu.org/<u></u>mailman/listinfo/axiom-<u></u>=
developer</a><br>
</blockquote></div><br></div></div>

--089e014940aefbecfa050b4b3300--

\start
Date: Sun, 28 Dec 2014 13:09:57 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Literate Programming in the Large video

The Literate Programming in the Large video, which was a talk
given at the Portland "Write the DOCS" conference is now online
as an MP4. The audience members are corporate people writing
documentation.

http://axiom-developer.org/axiom-website/videos.html

or directly at

http://axiom-developer.org/axiom-website/LiterateProgrammingInTheLarge.mp4

It is always exciting to give a talk when your presentation materials
fail to materialize. 

(and, yes, I know that the Integers do not form a Field. Sigh)

Tim

\start
Date: Sun, 28 Dec 2014 13:28:15 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom Computer Algebra System Information Sources
	video

The Axiom Computer Algebra System Information Sources video is now
available in mp4 format at

http://axiom-developer.org/axiom-website/videos.html

or directly at

http://axiom-developer.org/axiom-website/AxiomComputerAlgebraSystemInformationSources.mp4

Tim

\start
Date: Sun, 28 Dec 2014 19:35:14 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Easter egg in Axiom

Centuries ago, while we were still developing Scratchpad (the IBM name
of the project) we faced the problem of selling it. Someone already
owned the name Scratchpad and, although it wasn't being used for a
product, the owner wanted to keep it.

We tried to suggest a new name which is a lot harder than it looks. 
I believe that IBM spent about $50,000 dollars researching the various
names. We held a contest for a new name and "Axiom" won.  There was
even a new logo created for it with "dots" both over and under the "i"
in Axiom.

The Hyperdoc banner was being changed on an hourly basis (by me) with
the various names. I didn't believe that the name Axiom would last
any longer than any of the others. Anyway, I put the new-new-new (a
group inside joke; Bill Burge always called "this week's parser" "the
new parser") logo on Hyperdoc.

But there is a subtle modification. Look carefully at the logo.  The
top-right corner has a TM logo... but not really. It actually says
"TiM". I modified it as a joke, never expecting that it would leave my
desk. I just realized that the modiication survived all these years.

A bit of history for your entertainment.

TiM

\start
Date: Sun, 28 Dec 2014 22:29:38 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] New Videos

I've added three new videos to the Axiom website. They cover
the basic steps to handle a reported bug. The videos document
the "every day" process of being an Axiom developer.

http://axiom-developer.org/axiom-website/videos.html

The first new video "Bug Report Tracking" shows the steps
taken to record a reported bug in the buglist.

The second new video "Debugging Axiom Lisp Failure" shows how
to use the break and trace commands to find the point of failure,
how to use the book index to find the source code, how to debug
the failure, and how to test the fix.

The third new video "Closing a Reported Bug" shows the steps
taken to close a reported bug in the buglist.

These videos are intended to show new developers how to modify
and maintain Axiom. Suggestions for additional topics are welcome.

Tim

\start
Date: Mon, 29 Dec 2014 05:29:17 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Axiom courses online

Hasty generalization is my favorite form of reasoning.

Axiom now has the beginning attempt at developing tutorial videos so a
new developer can see how things are done. They aim to emulate Khan
academy videos.

At the moment, and for the near future, these are a set of videos on
random topics covering everyday use such as adding algebra or building
unit test cases. These are recorded screen captures but I have the
tools to edit full videos so it would be possible to include
whiteboard standup lectures (sadly I'm a bit too ugly for video).

The long term view suggests developing online courses complete with a
syllabus, videos, readings, and guest lectures.  At least three
courses suggest themselves. We need a course for the user, one for the
algebra developer, and one for the general developer.

The user course would address topics such as installing Axiom,
starting the system, how to get help (hyperdoc, the command line, the
mailing list), how to find algebra and examples, etc.

The algebra developer course would address topics such as an overview
of the existing algebra, developing new algebra, and deep-dives into
particular topics through guest lectures by the people who developed
the algebra.

The general developer course would cover topics such as how to get
sources, how to build on various platforms, submitting changes, adding
new code, source code management, writing literate programs, a
detailed overview of the interpreter, compiler, hyperdoc, graphics,
and the new browser.

Each of these courses needs a syllabus which will appear in a
first-draft form on the video page in the near future. Feel free
to propose revisions.

Suggestions? Comments? 

It is a good thing that Axiom has a 30 Year Horizon. :-)

Tim

\start
Date: Mon, 29 Dec 2014 05:45:41 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] Weekly progress report

The Interpreter volume has newly merged code.
The Compiler volume has newly merged code.
The video page has 4 new videos.
Hyperdoc Bug 7274 was found, reported, and fixed.
The READLINE and |function| macros were partially removed.
htcheck.lisp has been completely rewritten, merged, and removed.
Dead code has been removed.

Tim

\start
Date: Mon, 29 Dec 2014 16:05:16 -0500
From: Bill Page <bill.page@newsynthesis.org>
To: fricas-devel <fricas-devel@googlegroups.com>
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards
Cc: Axiom-Developer <axiom-developer@nongnu.org>,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>

On 24 December 2014 at 20:31, Eugene Surowitz <surow@attglobal.net> wrote:
> Ralf is only telling it as it is,
> but I wish I could be even as pessimistic as him.
>

I am definitely not as pessimistic as either of you!

> This is a crisis disguised as another documentation squabble.

It seems to me the crisis actually began many years ago when IBM
abandoned Axiom as a research project (gave it to NAG) and it
eventually failed as a commercial product.

> As I see the status of PanAxiom:
>
> OpenAxiom - One developer - little to no activity = dead branch.

It is remarkable to me how our perceptions differ! When did you last
look at OpenAxiom? I think the effort in OpenAxiom has been mostly of
an internal nature: extensions to the SPAD language, improvements in
coding style and preparations for re-basing the system on LLVM rather
than Lisp.  Last summer FriCAS had a Google Summer-Of-Code funded
project with similar goals. But Gaby has also implemented an alternate
graphical user interface for OpenAxiom.

> FriCAS    - One developer - one developer - system being devolved.

This opinion also seems odd.  What do you mean by "devolved"?  As I
see it from the point of view of mathematics, FriCAS is the only
project that has made any substantial progress. FriCAS is also the
only project that supports Aldor as an alternate library compiler.
Both FriCAS and OpenAxiom are (or were recently) used in teaching and
research.  This sounds more like evolution to me than devolution.

> Axiom     - One developer - when he goes Axiom goes.
>

I think that you are probably right here that "when he goes the
[original] Axiom project goes". I am not aware of anyone motivated to
continue the work in the direction that Tim Daly has taken it.

But I do agree with the implication of your initial characterization
of the problem as being "disguised as another documentation squabble".
I no longer think that (lack of) documentation is the central issue.
It may sound rather arrogant to say so, but it seems to me the problem
is more likely to be simply that Axiom was and still is ahead of its
time: the majority of computer algebra system users simply do not yet
have the level of sophistication or necessary experience to appreciate
it. This is not likely to be changed much by the presence or absence
of documentation or even tutorial training materials.  To see this I
think one only needs to look at the marketing strategies of the
commercial computer algebra systems.

Oddly perhaps things were different back when Axiom was under
development at IBM; then (1970's) it seems that nearly everyone who
worked with Axiom was a sophisticated expert. There has been an
explosive growth in the interest in computer algebra systems but very
little progress in passing on that early expertise to the next
generation(s).

So the original Axiom open source project now seems of only marginal
interest to me.  Nothing that Tim is working on right now is
particularly relevant to how or why I remain interested in Axiom (or
more specifically, FriCAS)..

> The basic issue that I see is that PanAxiom is really a
> software engineering project before it can continue to live.

No, I think the days when we could usefully and optimistically speak
of "PanAxiom" are gone.  There are now clearly three separate projects
with a life (or death) or their own (four if you want to count Aldor).
I also disagree that any of these projects are fundamentally "software
engineering projects" except maybe Aldor.  As I see it Axiom as a
concept is still fundamentally a research project - as is the entire
field of computer algebra as a whole.  The most that software
engineering can offer is minor improvements in technique.

>
> The literate approach that Knuth created has no answer to
> mass of existing code problem: that is, he didn't think out
> a mechanism for the curious to dynamically add insights to
> the system's code even if literate.  Inverses are sooo.. hard.

Do you mean some kind of "reverse engineering"?  I think you are right
that literate programming methodologies do not make this any easier.
Once I thought that a user supported and maintained web site (wiki)
might be an answer to this.  Although the FriCAS project still
supports the wiki that started in the early days of the original Axiom
project, I would say that it also counts as a (mostly) failed
experiment.

>
> Oh, and PanAxiom has no systematic development of basic numerology.
>

I suppose it is worthwhile to ask what you might mean by "numerology"?
Obviously not http://en.wikipedia.org/wiki/Numerology ...  Maybe
"number systems"?

Regards,
Bill Page.

\start
Date: Tue, 30 Dec 2014 13:17:59 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: fricas-devel@googlegroups.com,
	Gabriel Dos Reis <open-axiom-devel@lists.sf.net>,
	Axiom-Developer <axiom-developer@nongnu.org>
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards

Here's some of my reactions:

On 12/29/2014 4:05 PM, Bill Page wrote:
> On 24 December 2014 at 20:31, Eugene Surowitz <surow@attglobal.net> wrote:
>> Ralf is only telling it as it is,
>> but I wish I could be even as pessimistic as him.
>>
>
> I am definitely not as pessimistic as either of you!
>
I'm glad to hear this.
My own level of interest has been been there
for about thirty years at this point.
'Pessimism' may the wrong word.
>> This is a crisis disguised as another documentation squabble.
>
> It seems to me the crisis actually began many years ago when IBM
> abandoned Axiom as a research project (gave it to NAG) and it
> eventually failed as a commercial product.
>
Yup! Though Dick Jenks wasn't real happy with my cost analysis
of maintaining Axiom as a product; it subsequently went to NAG.

>> As I see the status of PanAxiom:
>>
>> OpenAxiom - One developer - little to no activity = dead branch.
>
> It is remarkable to me how our perceptions differ! When did you last
> look at OpenAxiom? I think the effort in OpenAxiom has been mostly of
> an internal nature: extensions to the SPAD language, improvements in
> coding style and preparations for re-basing the system on LLVM rather
> than Lisp.  Last summer FriCAS had a Google Summer-Of-Code funded
> project with similar goals. But Gaby has also implemented an alternate
> graphical user interface for OpenAxiom.
>
>> FriCAS    - One developer - one developer - system being devolved.
>
> This opinion also seems odd.  What do you mean by "devolved"?  As I
> see it from the point of view of mathematics, FriCAS is the only
> project that has made any substantial progress. FriCAS is also the
> only project that supports Aldor as an alternate library compiler.
> Both FriCAS and OpenAxiom are (or were recently) used in teaching and
> research.  This sounds more like evolution to me than devolution.
>
>> Axiom     - One developer - when he goes Axiom goes.
>>
>
> I think that you are probably right here that "when he goes the
> [original] Axiom project goes". I am not aware of anyone motivated to
> continue the work in the direction that Tim Daly has taken it.
>

Each version/fork of the code reduces the net effectiveness
of the programming hours spent unless each person tunnel
visions their work; that's just good control of your own time/effort.
I in no way imply that the separate forks aren't making very
meaningful improvements.

Its just that there is no whole that is greater than the sum of the parts
or even equal to them.

> But I do agree with the implication of your initial characterization
> of the problem as being "disguised as another documentation squabble".
> I no longer think that (lack of) documentation is the central issue.
> It may sound rather arrogant to say so, but it seems to me the problem
> is more likely to be simply that Axiom was and still is ahead of its
> time: the majority of computer algebra system users simply do not yet
> have the level of sophistication or necessary experience to appreciate
> it. This is not likely to be changed much by the presence or absence
> of documentation or even tutorial training materials.  To see this I
> think one only needs to look at the marketing strategies of the
> commercial computer algebra systems.
>
I agree with every word.
And user communities are notoriously resistant learning assignments.

> Oddly perhaps things were different back when Axiom was under
> development at IBM; then (1970's) it seems that nearly everyone who
> worked with Axiom was a sophisticated expert. There has been an
> explosive growth in the interest in computer algebra systems but very
> little progress in passing on that early expertise to the next
> generation(s).
>
True for every large system.
A cultural community or mechanism beyond code + documentation is needed.

> So the original Axiom open source project now seems of only marginal
> interest to me.  Nothing that Tim is working on right now is
> particularly relevant to how or why I remain interested in Axiom (or
> more specifically, FriCAS)..
>
>> The basic issue that I see is that PanAxiom is really a
>> software engineering project before it can continue to live.
>
> No, I think the days when we could usefully and optimistically speak
> of "PanAxiom" are gone.  There are now clearly three separate projects
> with a life (or death) or their own (four if you want to count Aldor).
> I also disagree that any of these projects are fundamentally "software
> engineering projects" except maybe Aldor.  As I see it Axiom as a
> concept is still fundamentally a research project - as is the entire
> field of computer algebra as a whole.  The most that software
> engineering can offer is minor improvements in technique.
>
Research projects are very nice provided
no one expects me to believe or reproduce the results.
>>
>> The literate approach that Knuth created has no answer to
>> mass of existing code problem: that is, he didn't think out
>> a mechanism for the curious to dynamically add insights to
>> the system's code even if literate.  Inverses are sooo.. hard.
>
> Do you mean some kind of "reverse engineering"?  I think you are right
> that literate programming methodologies do not make this any easier.
> Once I thought that a user supported and maintained web site (wiki)
> might be an answer to this.  Although the FriCAS project still
> supports the wiki that started in the early days of the original Axiom
> project, I would say that it also counts as a (mostly) failed
> experiment.
>
As I said: users don't do homework.

I call it an interesting experiment;
I intend to look further into it.
Waldek's comments fit in here.
>>
>> Oh, and PanAxiom has no systematic development of basic numerology.
>>
>
> I suppose it is worthwhile to ask what you might mean by "numerology"?
> Obviously not http://en.wikipedia.org/wiki/Numerology ...  Maybe
> "number systems"?
>
Yup; the forks should be able to count their p's and q's. ;)

> Regards,
> Bill Page.
>

Cheers, Gene

\start
Date: Tue, 30 Dec 2014 13:23:00 -0500
From: Raymond Rogers <raymond.rogers72@gmail.com>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] [fricas-devel] documentation standards

On 12/29/2014 04:05 PM, Bill Page wrote:
>> Axiom     - One developer - when he goes Axiom goes.
>>
> I think that you are probably right here that "when he goes the
> [original] Axiom project goes". I am not aware of anyone motivated to
> continue the work in the direction that Tim Daly has taken it.
I'm afraid you are right.  I think Tim's goal is absolutely the  correct 
thing
(I hate to see knowledge evaporate) but he is trying a "bottom up" approach
to reverse engineer it.
Every time I read about his progress; the picture of Atlas holding up 
the world comes
to mind.  An impossible goal for a mere human like me.
Remember Principia Mathematica by Whitehead and Russle; not only did 
they not
finish but I believe Whitehead said he was never as sharp afterwards;
he had burnt something out.  Have you tried reading it?  I think I got 
to page 100
  before getting completely submerged.  We must realize that that was a 
early
form of mathematical proof generation from fundamentals.
I really like that "literate program" form on Differential
Forms!  But that was top-down.  But I think doing bottom up is virtually 
impossible.
I think an alternative is to try to build _automatic_ translators that 
convert the
base code to mathematical formulation recognizable as mathematics.  I 
realize
that present mathematical notation is not perfect; but is usable because of
3,000 years of development.  Though, in all honesty, I am speaking from
ignorance.
> No, I think the days when we could usefully and optimistically speak 
> of "PanAxiom" are gone. There are now clearly three separate projects 
> with a life (or death) or their own (four if you want to count Aldor). 
> I also disagree that any of these projects are fundamentally "software 
> engineering projects" except maybe Aldor. As I see it Axiom as a 
> concept is still fundamentally a research project - as is the entire 
> field of computer algebra as a whole. The most that software 
> engineering can offer is minor improvements in technique. 
Are you thinking of mathematics or programming?  I would think a 
mathematical basis is definitely
not pass and should be the real goal. I really look forward to the day 
that "programming" is
automated and people will no longer be stuck digging in the mines trying 
to create or find a few gems.
> Do you mean some kind of "reverse engineering"? I think you are right 
> that literate programming methodologies do not make this any easier. 
> Once I thought that a user supported and maintained web site (wiki) 
> might be an answer to this. Although the FriCAS project still supports 
> the wiki that started in the early days of the original Axiom project, 
> I would say that it also counts as a (mostly) failed experiment. 
Please don't! The results apparently haven't been extensive but I would 
think that that is some
form of "marketing" :)  People sometime make fun of marketing and 
merchants; but the truth is they play
an essential role in the distribution of goods, knowledge, services and 
human advancement.
I don't have an "answer"  but what comes to mind is direct linkages to 
and from sites like Wikipedia, PlanetMath, or proofwiki.org.

Ray

--------------070707050709000107070600
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix"><small>On 12/29/2014 04:05 PM, Bill
        Page wrote:</small><br>
    </div>
    <blockquote
cite="mid:CAC6x94ScY9bEdHp_PUhxjw+1GnoFDU-8G68_-PrutRUT1MdZ2g@mail.gmail.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">Axiom     - One developer - when he goes Axiom goes.

</pre>
      </blockquote>
      <pre wrap="">
I think that you are probably right here that "when he goes the
[original] Axiom project goes". I am not aware of anyone motivated to
continue the work in the direction that Tim Daly has taken it.</pre>
    </blockquote>
    <small>I'm afraid you are right. I think Tim's goal is absolutely
      the correct thing<br>
      (I hate to see knowledge evaporate) but he is trying a "bottom up"
      approach<br>
      to reverse engineer it. <br>
      Every time I read about his progress; the picture of Atlas holding
      up the world comes <br>
      to mind. An impossible goal for a mere human like me.<br>
      Remember Principia Mathematica by Whitehead and Russle; not only
      did they not<br>
      finish but I believe Whitehead said he was never as sharp
      afterwards; <br>
      he had burnt something out. Have you tried reading it? I think I
      got to page 100<br>
      before getting completely submerged. We must realize that that
      was a early <br>
      form of mathematical proof generation from fundamentals.<br>
      I really like that "literate program" form on Differential <br>
      Forms! But that was top-down. But I think doing bottom up is
      virtually impossible.<br>
      I think an alternative is to try to build _automatic_ translators
      that convert the<br>
      base code to mathematical formulation recognizable as
      mathematics. I realize<br>
      that present mathematical notation is not perfect; but is usable
      because of <br>
      3,000 years of development. Though, in all honesty, I am speaking
      from <br>
      ignorance.<br>
    </small>
    <blockquote
cite="mid:CAC6x94ScY9bEdHp_PUhxjw+1GnoFDU-8G68_-PrutRUT1MdZ2g@mail.gmail.com"
      type="cite">
      <small>No, I think the days when we could usefully and
        optimistically speak
        of "PanAxiom" are gone. There are now clearly three separate
        projects
        with a life (or death) or their own (four if you want to count
        Aldor).
        I also disagree that any of these projects are fundamentally
        "software
        engineering projects" except maybe Aldor. As I see it Axiom as a
        concept is still fundamentally a research project - as is the
        entire
        field of computer algebra as a whole. The most that software
        engineering can offer is minor improvements in technique.
      </small></blockquote>
    <small>Are you thinking of mathematics or programming? I would
      think a mathematical basis is definitely<br>
      not pass and should be the real goal.</small> <small>I really
      look forward to the day that "programming" is <br>
      automated and people will no longer be stuck digging in the mines
      trying to create or find a few gems.</small><br>
    <blockquote
cite="mid:CAC6x94ScY9bEdHp_PUhxjw+1GnoFDU-8G68_-PrutRUT1MdZ2g@mail.gmail.com"
      type="cite">
      <small>Do you mean some kind of "reverse engineering"? I think you
        are right
        that literate programming methodologies do not make this any
        easier.
        Once I thought that a user supported and maintained web site
        (wiki)
        might be an answer to this. Although the FriCAS project still
        supports the wiki that started in the early days of the original
        Axiom
        project, I would say that it also counts as a (mostly) failed
        experiment.
      </small></blockquote>
    <small>Please don't!</small> <small>The results apparently haven't
      been extensive but I would think that that is some<br>
      form of "marketing" :) People sometime make fun of marketing and
      merchants; but the truth is they play<br>
      an essential role in the distribution of goods, knowledge,
      services and human advancement.<br>
      I don't have an "answer" but what comes to mind is direct
      linkages to and from sites like Wikipedia, PlanetMath, or
      proofwiki.org.<br>
    </small><br>
    <small>Ray</small><br>
  </body>
</html>

--------------070707050709000107070600--

\start
Date: Tue, 30 Dec 2014 13:30:30 -0600
From: daly@axiom-developer.org
To: axiom-developer@nongnu.org
Subject: [Axiom-developer] The impossible dream

Gentlemen,

It is completely clear that you disagree with the Axiom's goals.

You've all decided that Axiom is a failure and a waste of time.

You consider Axiom to be "of marginal interest".

None of these personal opinions seem to be useful feedback. We had a
year of this pointless "bikeshed" debate 7 years ago. None of our
opinions have changed.

It is not clear why you even mention Axiom on any list.

If you have something useful to contribute, please do.  Otherwise, I'm
asking you politely to stop copying this useless thread to the Axiom
mailing list.

Tim

\start
Date: Tue, 30 Dec 2014 17:58:47 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: axiom-developer@nongnu.org
Subject: Re: [Axiom-developer] The impossible dream

"all" is a very big word even in lower-case.

I consider Axiom and its forks to all be partial successes
which are leading to excellent competitive experiments.
So: all-{1}.

Cheers, Gene

On 12/30/2014 2:30 PM, daly@axiom-developer.org wrote:
> Gentlemen,
>
> It is completely clear that you disagree with the Axiom's goals.
>
> You've all decided that Axiom is a failure and a waste of time.
>
> You consider Axiom to be "of marginal interest".
>
> None of these personal opinions seem to be useful feedback. We had a
> year of this pointless "bikeshed" debate 7 years ago. None of our
> opinions have changed.
>
> It is not clear why you even mention Axiom on any list.
>
> If you have something useful to contribute, please do.  Otherwise, I'm
> asking you politely to stop copying this useless thread to the Axiom
> mailing list.
>
> Tim

\start
Date: Tue, 30 Dec 2014 18:16:27 -0500
From: Eugene Surowitz <surow@attglobal.net>
To: Axiom-Developer <axiom-developer@nongnu.org>
Subject: [Axiom-developer] http://axiom-developer.org/index.html

Tim:

I suggest that the "Videos" entry under "Site Navigation"
be moved up and be placed under the "Information category"
replacing "How to participate" which has been pointing
to a page that has contained nothing but "Todo" for as long
as I can remember.

Or possibly just after "Screenshots".

People are more likely to spot it in either case;
watching TV is such a naturally unnatural act.

Cheers, Gene

\start
Date: Wed, 31 Dec 2014 07:55:16 -0600
From: daly@axiom-developer.org
To: Eugene Surowitz <surow@attglobal.net>
Subject: Re: [Axiom-developer] http://axiom-developer.org/index.html

Gene,

>I suggest that the "Videos" entry under "Site Navigation"
>be moved up and be placed under the "Information category"
>replacing "How to participate" which has been pointing
>to a page that has contained nothing but "Todo" for as long
>as I can remember.

>Or possibly just after "Screenshots".

>People are more likely to spot it in either case;
>watching TV is such a naturally unnatural act.

The video link is now under the screenshot link.

Tim

\start
Date: Wed, 31 Dec 2014 08:53:14 -0600
From: daly@axiom-developer.org
To: leonbaum <notifications@github.com>
Subject: Re: [Axiom-developer] Build failure: grep: int/input/*.regress: No
	such file or

Actually, it's not a failure in the Axiom build but in the post-build
test mechanism. There is a selector for the group of tests to run,
controlled by "TESTSET".

The default for "make" is TESTSET=notests and grep still tries to 
check for failing tests.

I always type
  make TESTSET=regresstests
so I didn't notice this failure. I will fix it shortly.
In the meantime, try 

   make TESTSET=regresstests

Tim



\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
