Speaking of "real work on a real system" there could be several projects
that would be useful.
view2d / vew3d
For the browser-based version the graphics goal is to replace the view2d and
view3d programs with HTML5 canvas-based versions. The first step would
be to document the message patterns from axiom to view2d and back. Once
that is done and documented there would be an effort to use something like
websockets to display the messages in browser text and automate the replies.
Now that you know the messages they need to be turned into HTML5 canvas
drawing commands. Once the drawing happens there is another layer of
control because clicking on a view2d/3d image will bring up a control panel.
This could be done with menus or buttons in the web page rather than as a
separate window.
If a student wants to do this they should look at the book
"Physically Based Rendering". This book won an Academy Award.
It is the canonical example of where Axiom needs to go.
Deconstructing Hyperdoc
Hyperdoc was our pre-internet version of a browser. Some portions of it are
pre-canned scripts (some of which I've already written, as you can see from
the sources). Some portions interact with the running Axiom to send an
input line and open a DIV section with the response. I have also written
some
prototype code for that in the sources.
Some page output is generated dynamically by Axiom. This needs to be
written so it creates browser-based text rather than hyperdoc text.
Removing Makefiles
We currently use 'make' to build the system. But Axiom is trying to remove
as many tools and external dependencies as possible. Each thing we remove
is one less thing users need to pre-install and one less thing to maintain.
The task would be to trace the 'make' scripts to find out the exact sequence
of commands to build Axiom. These would then be written as lisp functions.
So instead of using 'make', we start lisp and use it to build Axiom, which
is
a large lisp program.
Some of this tracing is already done in anticipation that this rewrite will
happen. The Makefile files are documented (and generated from) the
Makefile.pamphlet files.
Knuth, Literate Programming, and Axiom
The 'pamphlet' files are raw latex files. You can just run latex on them.
Knuth's original vision of literate programming had 2 tools, 'weave' and
'tangle'. The 'weave' program takes the literate sources and generates
tex-compatible output. Axiom uses latex directly so there is no need for
a 'weave' program.
The 'tangle' program exists, called 'tanglec' in the books subdirectory.
It takes 2 arguments, the source latex file and the name of a 'chunk'.
It writes the chunk contents to stdout.
tanglec bookvol10.3.pamphlet "domain INT Integer" >integer.spad
This will look for a chunk with the given name, e.g.
\begin{chunk}{domain INT Integer}
the integer.spad source code is here
\end{chunk}
There is no real magic in the 'tanglec' program. It just reads the source
file, makes a hash table of every chunk name (concatenating repeated
names into a single block) and then writes out the requested chunk to
stdout.
The ultimate goal is to make every file a latex document. Most
programs use the "pile of sand" (POS) method to organize sources.
They try to provide "semantics" by clever directory names such as 'doc'.
What they don't realize is that this is left-over technology from the past.
I used to work on a machine with 8k, 4k of which was the operating system.
If you created a file larger than 4k you crashed the system. So we invented
"include" for files and "overlay linkers" (which are now virtual memory
hardware). Comments cost bytes and were frowned upon.
People STILL write 4k files and POS directories with include files despite
having 16G of memory. They still think comments are expensive and that
'documentation' is worthless. We need to think of 'explanations', not
documentation or comments. POS programming needs to die.
Explanations
If you cover a topic in class (e.g. CAD, Groebner, Berlekamp factoring, etc)
the task would be to find the code that implements the algorithms and
document them. This is rather more difficult than it sounds as there are
a lot of implementation details which classes never cover but are vital.
A good starting point would be polynomial algorithms. Axiom supports a
lot of different poly representations, such as sparse/dense, recursive,
distributed, and various multivariate versions of the same. Pick one of
the Domains, e.g. SparseUnivariatePolynomial (SUP), discuss its
representation in Axiom, and explain operations like 'variables',
'resultant',
'primitivePart', 'squareFree', etc.
Contributions
You should stress to any student that Axiom is literate. That means that
any contribution NEEDS to focus on explanation. For a system like Axiom
to live, it needs to be possible for people to maintain, modify, and extend
it.
The prior authors (me included) failed to explain anything. Axiom was
originally a research project not a product so nobody cared. Unfortunately,
now we have to re-discover how existing code works. New code can't be
allowed to make the same mistake.
I'd be happy to work with students who want to contribute.
Tim
On Tue, May 9, 2017 at 5:39 PM, Tim Daly <axiom...@gmail.com> wrote:
> No need to apologize. I know this is a busy time.
>
> The ultimate goal is to replace the hyperdoc/graphics with a browser front
> end using HTML canvas for the graphics. I have made a start on this but
> have been busy with other things.
> (See http://axiom-developer.org/axiom-website/bookvol11.pdf)
>
> A possible alternative is to use the Jupyter notebook. (
> http://jupyter.org/)
> I have not looked into this in detail. The student is free to talk to me
> about any ideas.
>
> I'm working on a syllabus for a CMU course which seems to differ from the
> current
> courses taught elsewhere. Almost every course spends all of its time on the
> algorithms. That's fine but it leave the topic "ungrounded". The student
> does
> not know how the algorithms are actually implemented and does not know how
> to build/test/modify an existing system with new work. It's a bit like
> teaching
> art by looking at paintings but never mentioning 90% of the subject that a
> real
> artist knows, like brushes, medium, art shows, etc. It's all nice in
> theory but
> is ultimately pointless as the student can't use the information.
>
> In the ideal case the students would be part of a group that does real work
> on a real system, just as art students end up painting and entering their
> work
> in art shows. I'm hoping to start a "reading group" that covers papers
> from the
> past as well as the latest conferences. I have a set of papers on CAD
> starting
> with the Collins 1975 paper onward which I'm starting to organize.
>
> Tim
>
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
https://lists.nongnu.org/mailman/listinfo/axiom-developer
