Web Assembly / Web Sockets On my list of things to think about for the Axiom browser interface is using Web Assembly (http://webassembly.org/docs/mvp/) and Web Sockets (https://tools.ietf.org/html/rfc6455)
The current implementation uses older technology. Gnu Common Lisp compiles to C code. LLVM supports compiling C code to wasm (web assembly). This raises the interesting possibility of sending a compiled user function for a graph (or other user-interface function) directly to the browser front end for local execution. This is "current research", meaning that nobody knows how to do this yet so it really is research. It might be more appropriate for an advanced student's project with a poster/publication effort. I have played with websockets for a bit, unsuccessfully. But my efforts were at their first introduction a while ago so browser "support" was quite new and buggy. Socket support is probably better now but web assembly is at the MVP (minimum viable product) stage which means somebody, somewhere got it to work once on hand-crafted code in an undocumented custom tool chain. The 'canonical' case I'm trying to construct is to send a set of functions, graph them on a common (2D) canvas, have the user provide vertical lines that are the Cylindrical Algebraic Decomposition "cells" which show where the separations are, and send these vertical line equations back to Axiom. This is an example of the user providing part of the actual computation interactively. Again, I'll mention that this is real research as nobody does interactive CAD computations yet as far as I know. Approaching this canonical case requires a lot of tiny demonstration steps. Any student willing to take tiny steps should be encouraged. Tim On Mon, May 15, 2017 at 7:45 AM, Tim Daly <[email protected]> wrote: > 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 <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/axiom-developer
