diff --git a/books/bookvol10.3.pamphlet b/books/bookvol10.3.pamphlet
index 6b72ef7..257be7e 100644
--- a/books/bookvol10.3.pamphlet
+++ b/books/bookvol10.3.pamphlet
@@ -59370,7 +59370,7 @@ IndexedOneDimensionalArray(S:Type, mn:Integer):
Qsetelt ==> SETELT$Lisp
-- Qelt1 ==> QVELT_-1$Lisp
-- Qsetelt1 ==> QSETVELT_-1$Lisp
- Qnew ==> GETREFV$Lisp
+ Qnew ==> MAKE_-ARRAY$Lisp
I ==> Integer
#x == Qsize x
@@ -102089,7 +102089,7 @@ PrimitiveArray(S:Type): OneDimensionalArrayAggregate S == add
-- Qsetelt ==> QSETVELT$Lisp
Qelt ==> ELT$Lisp
Qsetelt ==> SETELT$Lisp
- Qnew ==> GETREFV$Lisp
+ Qnew ==> MAKE_-ARRAY$Lisp
#x == Qsize x
minIndex x == 0
@@ -141523,7 +141523,7 @@ U32Vector() : OneDimensionalArrayAggregate Integer == add
Qsize ==> QV32LEN$Lisp
Qelt ==> ELT32$Lisp
Qsetelt ==> SETELT32$Lisp
- Qnew ==> GETREFV32$Lisp
+ Qnew ==> MAKE_-ARRAY32$Lisp
#x == Qsize x
minIndex x == 0
@@ -145857,7 +145857,7 @@ This is eventually forcibly replaced by a recompiled version.
(RETURN
(PROGN
(LETT |dv$| '(|Boolean|) |Boolean|)
- (LETT $ (GETREFV 41) |Boolean|)
+ (LETT $ (make-array 41) |Boolean|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |Boolean|))
@@ -146066,7 +146066,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(SEQ (PROGN
(LETT |dv$| '(|Character|) |Character|)
- (LETT $ (GETREFV 53) |Character|)
+ (LETT $ (make-array 53) |Character|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |Character|))
@@ -146771,7 +146771,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|DoubleFloat|) |DoubleFloat|)
- (LETT $ (GETREFV 140) |DoubleFloat|)
+ (LETT $ (make-array 140) |DoubleFloat|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |DoubleFloat|))
@@ -147398,7 +147398,7 @@ Note that this code is not included in the generated catdef.spad file.
(LETT DV$1 (|devaluate| |#1|) |IndexedList|)
(LETT DV$2 (|devaluate| |#2|) |IndexedList|)
(LETT |dv$| (LIST '|IndexedList| DV$1 DV$2) |IndexedList|)
- (LETT $ (GETREFV 71) |IndexedList|)
+ (LETT $ (make-array 71) |IndexedList|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
@@ -147907,7 +147907,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|Integer|) |Integer|)
- (LETT $ (GETREFV 130) |Integer|)
+ (LETT $ (make-array 130) |Integer|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |Integer|))
@@ -148820,7 +148820,7 @@ Note that this code is not included in the generated catdef.spad file.
(PROGN
(LETT DV$1 (|devaluate| |#1|) |IndexedString|)
(LETT |dv$| (LIST '|IndexedString| DV$1) |IndexedString|)
- (LETT $ (GETREFV 83) |IndexedString|)
+ (LETT $ (make-array 83) |IndexedString|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
@@ -149170,7 +149170,7 @@ Note that this code is not included in the generated catdef.spad file.
(PROGN
(LETT DV$1 (|devaluate| |#1|) |List|)
(LETT |dv$| (LIST '|List| DV$1) |List|)
- (LETT $ (GETREFV 62) |List|)
+ (LETT $ (make-array 62) |List|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
@@ -149355,7 +149355,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|NonNegativeInteger|) |NonNegativeInteger|)
- (LETT $ (GETREFV 17) |NonNegativeInteger|)
+ (LETT $ (make-array 17) |NonNegativeInteger|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL)
@@ -150001,7 +150001,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|OutputForm|) |OutputForm|)
- (LETT $ (GETREFV 138) |OutputForm|)
+ (LETT $ (make-array 138) |OutputForm|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |OutputForm|))
@@ -150161,7 +150161,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|PositiveInteger|) |PositiveInteger|)
- (LETT $ (GETREFV 12) |PositiveInteger|)
+ (LETT $ (make-array 12) |PositiveInteger|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |PositiveInteger|))
@@ -150237,12 +150237,12 @@ Note that this code is not included in the generated catdef.spad file.
(DEFUN |PRIMARR;minIndex;$I;2| (|x| |$|) 0)
(PUT (QUOTE |PRIMARR;empty;$;3|)
- (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (GETREFV 0))))
+ (QUOTE |SPADreplace|) (QUOTE (XLAM NIL (make-array 0))))
-(DEFUN |PRIMARR;empty;$;3| (|$|) (GETREFV 0))
+(DEFUN |PRIMARR;empty;$;3| (|$|) (make-array 0))
(DEFUN |PRIMARR;new;NniS$;4| (|n| |x| |$|)
- (SPADCALL (GETREFV |n|) |x| (QREFELT |$| 12)))
+ (SPADCALL (make-array |n|) |x| (QREFELT |$| 12)))
(PUT (QUOTE |PRIMARR;qelt;$IS;5|) (QUOTE |SPADreplace|) (QUOTE ELT))
@@ -150298,7 +150298,7 @@ Note that this code is not included in the generated catdef.spad file.
(PROGN
(LETT DV$1 (|devaluate| |#1|) |PrimitiveArray|)
(LETT |dv$| (LIST '|PrimitiveArray| DV$1) |PrimitiveArray|)
- (LETT $ (GETREFV 35) |PrimitiveArray|)
+ (LETT $ (make-array 35) |PrimitiveArray|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
@@ -150459,7 +150459,7 @@ Note that this code is not included in the generated catdef.spad file.
(PROGN
(LETT DV$1 (|devaluate| |#1|) |Reference|)
(LETT |dv$| (LIST '|Reference| DV$1) |Reference|)
- (LETT $ (GETREFV 23) |Reference|)
+ (LETT $ (make-array 23) |Reference|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
@@ -150942,7 +150942,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|SingleInteger|) |SingleInteger|)
- (LETT $ (GETREFV 103) |SingleInteger|)
+ (LETT $ (make-array 103) |SingleInteger|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |SingleInteger|))
@@ -151825,7 +151825,7 @@ Note that this code is not included in the generated catdef.spad file.
(RETURN
(PROGN
(LETT |dv$| '(|Symbol|) |Symbol|)
- (LETT $ (GETREFV 124) |Symbol|)
+ (LETT $ (make-array 124) |Symbol|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$| (|buildPredVector| 0 0 NIL) |Symbol|))
@@ -151999,7 +151999,7 @@ Note that this code is not included in the generated catdef.spad file.
(PROGN
(LETT DV$1 (|devaluate| |#1|) |Vector|)
(LETT |dv$| (LIST '|Vector| DV$1) |Vector|)
- (LETT $ (GETREFV 36) |Vector|)
+ (LETT $ (make-array 36) |Vector|)
(QSETREFV $ 0 |dv$|)
(QSETREFV $ 3
(LETT |pv$|
diff --git a/books/bookvol5.pamphlet b/books/bookvol5.pamphlet
index 7e867a0..5e06258 100644
--- a/books/bookvol5.pamphlet
+++ b/books/bookvol5.pamphlet
@@ -39565,7 +39565,1433 @@ See Steele Common Lisp 1990 pp305-307
\end{chunk}
-\chapter{OpenMath stub functions}
+\chapter{OpenMath}
+\section{A Technical Overview\cite{4}}
+
+OpenMath is a standard for representing mathematical data in as
+unambiguous a way as possible. It can be used to exchange mathematical
+objects between software packages or via email, or as a persistent
+data format in a database. It is tightly focussed on representing
+semantic information and is not intended to be used directly for
+presentation, although tools exist to facilitate this.
+
+The original motivation for OpenMath came from the Computer Algebra
+community. Computer Algebra packages were getting bigger and more
+unwieldy, and it seemed reasonable to adopt a generic "plug and play"
+architecture to allow specialised programs to be used from general
+purpose environments. There were plenty of mechanisms for connecting
+software components together, but no common format for representing
+the underlying data objects. It quickly became clear that any standard
+had to be vendor-neutral and that objects encoded in OpenMath should
+not be too verbose. This has led to the design outlined below.
+
+In 1998, the Worldwide Web Consortium (W3C) produced its first
+recommendation for the Extensible Markup Language (XML), intended to
+be a universal format for representing structured information on the
+worldwide web. It was swiftly followed by the first MathML
+recommendation which is an XML application oriented mainly towards the
+presentation (i.e. the rendering) of mathematical expressions.
+
+The formal definition of OpenMath is contained within The OpenMath
+Standard and its accompanying documents, and the reader is referred
+there for more details.
+
+\subsection{The OpenMath Architecture}
+
+The OpenMath representation of a mathematical structure is referred to
+as an OpenMath object. This is an abstract structure which is
+represented concretely via an OpenMath encoding. These encoded objects
+are what an OpenMath application would read and write, and in practice
+the OpenMath objects themselves almost never exist, except on
+paper. The advantage of this is that OpenMath is not tied to any one
+underlying mechanism: in the past we have used functional, SGML and
+binary encodings. The current favourite is XML, as described below,
+and we will tend to use XML notation when describing OpenMath objects
+(even though strictly speaking the XML representation is an encoding).
+OpenMath Objects
+
+Formally, an OpenMath object is a labelled tree whose leaves are the
+basic OpenMath objects integers, IEEE double precision floats, unicode
+strings, byte arrays, variables or symbols. Of these, symbols are the
+most interesting since they consist of a name and a reference to a
+definition in an external document called a content dictionary (or
+CD). Using XML notation where the element name OMS indicates an
+OpenMath symbol, the following:
+\begin{verbatim}
+
+\end{verbatim}
+represents the usual sine function, as defined in the CD "transc1". A
+basic OpenMath object is an OpenMath object, although its XML
+representation will be:
+\begin{verbatim}
+
+
+
+\end{verbatim}
+
+OpenMath objects can be built up recursively in a number of ways. The
+simplest is function application, for example the expression sin(x)
+can be represented by the XML:
+\begin{verbatim}
+
+
+
+
+
+
+\end{verbatim}
+where OMV introduces a variable and OMA is the application
+element. Another straightforward method is attribution which as the
+name suggests can be used to add additional information (for example
+"the AXIOM command which generated me was ...") to an object without
+altering its fundamental meaning. More interesting are binding objects
+which are used to represent an expression containing bound variables,
+for example:
+\begin{verbatim}
+
+
+
+
+
+
+\end{verbatim}
+represents the integral of the sin function, but the encoding:
+\begin{verbatim}
+
+
+
+
+
+
+
+
+
+
+
+
+
+\end{verbatim}
+represents ∫sin(x)dx. This may appear overly complicated but it is
+useful, for example when searching in a database for expressions which
+match ∫sin(y)dy . The definition of a symbol in the CD specifies
+whether or not it may be used to bind variables, which is why
+\begin{verbatim}
+
+\end{verbatim}
+cannot be used as a binding symbol.
+
+The final kind of OpenMath object is an error which is built up from a
+symbol describing the error and a sequence of OpenMath objects. For
+example:
+\begin{verbatim}
+
+
+
+
+
+
+\end{verbatim}
+represents the error which might be generated when an application sees
+a symbol it doesn't recognise from a CD it thought it knew about.
+
+\subsection{OpenMath Encodings}
+
+We have already seen some examples of the XML encoding, but it is by
+no means the only encoding. In the past there was a functional
+encoding (which looked like Lisp) and an SGML encoding which evolved
+into the current XML. Both of these are now obsolete, but there is
+still a binary encoding described in the standard , which is much more
+compact than the XML one.
+
+In fact the XML encoding is not \verb|100%| XML. When XML was in its infancy
+the developers of OpenMath realised that it might become significant
+and decided to add some XML-like features to the SGML encoding so that
+an an OpenMath object could be encoded as valid XML. Thus it is
+currently the case that any well-formed OpenMath object encoded using
+the XML encoding as described in the standard is a valid XML
+document. However, if one uses standard XML tools to generate an
+OpenMath object in the XML encoding from the DTD given in chapter 4 of
+the standard, it is possible that the result will not be valid
+OpenMath, although in practice this is highly unlikely. To cover all
+the possibilities allowed by XML would make it much more complicated
+to write an application to read any OpenMath object from
+scratch. Whether to adopt XML completely remains a hot topic of debate
+within the OpenMath community!
+
+Generally speaking, it is not intended that the existing encodings
+should be readable by a human user or writable by hand. It is
+desirable that they be compact and it is also desirable that they be
+linear, but neither of these is a requirement. It is a property of
+encodings that it is possible to convert between them with no loss of
+information.
+
+\subsection{Content Dictionaries}
+
+Content Dictionaries (or CDs for short) are the most important, and
+the most interesting, aspect of OpenMath because they define the
+meaning of the objects being transmitted. A CD is a collection of
+related symbols and their definitions, encoded in an XML
+format. Defining the meaning of a symbol is not a trivial task, and
+even referring to well-known references can be fraught with pitfalls
+Formal definitions and properties can be very useful but
+time-consuming to produce and verbose, not to mention difficult to get
+right. A symbol definition in an OpenMath CD consists of the following
+pieces of information:
+\begin{verbatim}
+ the symbol name;
+ a description in plain text;
+ optionally, a set of this symbol's properties in plain text
+ (Commented Mathematical Properties, or CMPs);
+ optionally, a set of this symbol's properties encoded in OpenMath
+ (Formal Mathematical Properties, or FMPs);
+ optionally, one or more examples of its use (encoded in OpenMath).
+\end{verbatim}
+In practice the CMPs and FMPs can come as pairs, and often serve in
+the place of examples.
+
+A very simple instance of a CD definition is:
+\begin{verbatim}
+
+ log
+
+
+This symbol represents a binary log function; the first argument is
+the base, to which the second argument is log'ed.
+It is defined in Abramowitz and Stegun, Handbook of Mathematical
+Functions, section 4.1
+
+
+ a^b = c implies log_a c = b
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+log 100 to base 10 (which is 2).
+
+
+
+
+
+
+
+
+
+
+\end{verbatim}
+
+Another example would be to print the list
+\begin{verbatim}
+ [ 1, 1/2 ]
+\end{verbatim}
+as
+\begin{verbatim}
+
+
+
+ 1
+
+
+ 1
+ 2
+
+
+
+\end{verbatim}
+
+This provides a symbol to represent the log function by giving a
+pointer to a standard reference book. It provides the property that:
+\[ a^b=c \rightarrow log_a(c)=b \]
+both as plain text and as OpenMath, and also gives an example of how
+the symbol is used.
+
+CDs usually consist of related symbols and collections of related CDs
+can be grouped together, for convenience, as CD Groups. One very
+important CD Group is that corresponding to the content part of
+MathML.
+
+It is possible to associate extra information with CDs, in particular
+type information. Since there are many type systems available, each of
+which has its own strengths and advocates, the OpenMath community does
+not mandate any single system. Simple signatures can be encoded using
+the Simple Type System, while more formal definitions are possible
+using the Extended Calculus of Constructorss. Other associated
+information can include style sheets for rendering OpenMath symbols in
+MathML, and mathematical definitions to be used by formal logic
+systems.
+
+Given the evolutionary nature of mathematics, it is clear that the set
+of CDs should be forever growing and never complete. Currently there
+are CDs for high-school mathematics, linear algebra, polynomials and
+group theory to name a few, and new contributions are always
+welcome. There is no requirement that applications use the standard
+set of CDs and it is often very useful to design a "private" CD for a
+specific purpose.
+
+\subsection{OpenMath in Action}
+
+There is no definitive way in which OpenMath should be used, as the
+protocol has been designed to be as flexible as possible. Nevertheless
+many OpenMath applications share common characteristics which we shall
+discuss here.
+
+Suppose that we wish to have two applications communicating by sending
+OpenMath objects to each other, e.g. a client program and a
+computational server. It is unlikely that the internal data structures
+used by the applications will be OpenMath, and so translation between
+the internal representations and OpenMath (almost certainly OpenMath
+encodings rather than objects) will have to take place. The piece of
+software which does this is usually referred to as a phrase-book.
+
+It is possible to write a generic phrase-book which can handle any
+piece of OpenMath, but applications where this makes sense are few and
+far between. In practice an OpenMath phrase book will usually only
+handle a fixed set of CDs (and hence a fixed set of symbols). What
+``handle'' means will vary from case to case: a computer algebra system
+will usually try and evaluate its input and return a result or an
+error, while a typesetter will print its input according to some
+rendering rules and not return anything. OpenMath carefully avoids
+defining what the ``right'' behaviour is in a given circumstance, and
+leaves that up to the phrase-book writer. Indeed it is quite possible
+that a piece of software could have multiple phrase-books associated
+with it for different purposes. OpenMath symbols should not be
+regarded as verbs since they are used to construct objects rather than
+to send commands, and the presence of both nouns and verbs in a CD
+(e.g. ``integral'' and ``integrate'') is strongly discouraged.
+
+Writing a phrase-book may be non-trivial, and requires an
+understanding of the semantics of the underlying software. An OpenMath
+object may not map directly into a private object and vice-versa, for
+example in some systems a rational number might have to be represented
+by a float, or a sparse matrix by a dense one.
+
+The OpenMath standard includes a section on compliance, which
+describes the behaviour of an OpenMath application when certain errors
+occur. It also insists that all compliant software has the capability
+to use the XML encoding, to guarantee a degree of interoperability.
+This is an area where the standard is expected to evolve as more
+OpenMath applications become available.
+
+\section{Technical Details\cite{3}}
+
+This chapter describes the Axiom implementation of the OpenMath project
+at INRIA \cite{3}. The code enables the exchange of OpenMath objects
+between two processes and more generally the input and output of OpenMath
+objects. First we describe the library API and then we implement the
+functions used by Axiom.
+\section{The Structure of the API}
+The library and its API are logically structured in four parts:
+\begin{itemize}
+\item Functions that deal with {\sl devices}, the abstraction
+from which OpenMath objects are read and written to.
+\item Functions that read from and write to OpenMath devices. These functions
+use a simple model that read and write tokens.
+\item Functions that create I/O structures to be used by devices, so that,
+for example, an OpenMath object can be read from a file or a socket. This part
+is extensible by the user.
+\item Functions that deal with interprocess communication.
+\end{itemize}
+
+\section{OpenMath Expressions}
+
+\subsection{Expressions}
+
+The library understands the following kinds of basic OpenMath expressions:
+\begin{itemize}
+\item integers
+\item double precision floating-point numbers (64 bits, following IEEE 754)
+\item byte arrays
+\item character strings
+\item symbols
+\item variables
+\end{itemize}
+and the four kinds of constructions:
+\begin{itemize}
+\item applications $e_0(e_1, \ldots e_n)$
+\item errors $s(e_1, \ldots e_n)$
+\item binders $e_1, (v_1, \ldots v_n), e_2 $
+\item attributed expressions $[s_1 e_1, \ldots s_n e_n] e$
+\end{itemize}
+where $e_i$ are OpenMath expressions, $v_i$ are OpenMath variables and $s$ and
+$s_i$ are OpenMath symbols.
+
+\subsection{Symbols}
+
+Symbols are constructed from a content dictionary (abbreviated as CD
+in the sequel) and a name. A content dictionary is identified by its
+name. The API permits the creation of any symbol in any content
+dictionary: there is nothing that prevents creating symbols that do
+not belong to a known CD.
+
+\subsection{Encoding and Decoding OpenMath Expressions}
+
+An OpenMath object is encoded as a sequence of bytes that is read and
+written sequentially. The library views this sequence as a stream of
+tokens. Expressions are linearized in a way that looks like Lisp with
+typed parenthesis. For example, the linearization of the application
+of $S$ to $E_1\ldots E_n$ is:
+\begin{itemize}
+\item indicating that this is an application (a ``begin application'' token)
+\item linearizing $S$
+\item linearizing $E_1$,\ldots $E_n$
+\item indicating that all arguments have been given (an ``end application''
+token)
+\end{itemize}
+
+The other constructions are linearized the same way (each one with its
+own begin and end tokens). Note that there is no explicit arity
+indication so that we don't have to introduce a special mechanism when
+we don't know beforehand how many arguments there are.
+
+To give attributes to an expression, the attributes and their
+associated values are put before the expression. To give the
+attributes $a_i$ with values $v_i$ (where $a_i$ are symbols and $v_i$
+are OpenMath expressions) to an expression $E$ the process is:
+\begin{itemize}
+\item put a ``begin attributed expression'' token
+\item put a ``begin attribute pairs'' token
+\item put the symbol $a_1$ followed by the linearization of $v_1$ {\sl etc}
+\item put an ``end attribute pairs'' token
+\item linearize $E$
+\item put an ``end attributed expression'' token
+
+\end{itemize}
+
+Decoding is done by first querying the type of the next OpenMath token and
+then invoking the right function to get this particular kind of token.
+
+\section{Big Integers}
+
+The library supports big integers that can potentially be given in
+various formats. The {\tt OMBigIntType} describes the different
+possible formats.
+\begin{verbatim}
+typedef enum OMbigIntType {
+ OMBIunknown = 0, /* this is base 10, digits in normal order */
+ OMBIbase10 /* this is base 16, digits in normal order (MSB) */
+ OMbigIntBase16
+} OMbigIntType;
+\end{verbatim}
+
+\section{Functions Dealing with OpenMath Devices}
+
+OpenMath expressions are read and written through {\sl devices}.
+Basically, an OpenMath device has an associated encoding and an I/O
+method. There are basically two encodings defined and implemented.
+The first one is a human readable and writable one that can be used
+for example as the encoding for sending OpenMath objects via e-mail or
+storing OpenMath objects to files. This encoding is SGML compatible
+in the sense that it can be used to represent OpenMath objects in SGML
+texts. I has an XML variant. The second encoding is a binary one that
+can be used when compactness and speed of encoding and decoding is
+important. The encodings are defined by the {\tt OMencodingType} type
+which is an enumerated type defined as
+\begin{verbatim}
+typedef enum OMencodingType
+ { OMencodingUnknown,
+ OMencodingBinary,
+ OMencodingSGML,
+ OMencodingXML} OMencodingType;
+\end{verbatim}
+{\tt OMencodingUnknown} is to be used when creating a device that does not
+know which kind of encoding will be used. It must be used only for input
+devices.
+
+A device is created with the following function, given an encoding and
+an appropriate I/O method:
+\begin{itemize}
+\item {\tt OMdev OMmakeDevice(OMencodingType encoding, OMIO IO)}
+\end{itemize}
+Devices are closed with the following function
+\begin{itemize}
+\item {\tt void OMcloseDevice(OMdev dev)}
+\end{itemize}
+
+Whether a device could be used both for reading and writing is entirely
+dependent on its I/O method.
+
+The user can define its own I/O method as a function returning
+an {\tt OMIO} object. This could enable him, for example, to use an
+existing transport protocol to exchange OpenMath expressions or to implement
+cut-and-paste of OpenMath expression by writing I/O structures that input and
+output to strings. The I/O section describes the available I/O structures in
+the library.
+
+An {\tt OMdev} object is a pointer to a structure that contains a lot
+of state. Almost all functions taking an {\tt OMdev} object modify
+it. Likewise, an {\tt OMIO} object carries a lot of state.
+
+\section{Functions to Write OpenMath Expressions to Devices}
+
+\subsection{Beginning and Ending Objects}
+
+The following two functions mark the beginning and end of an OpenMath object.
+\begin{itemize}
+\item \verb+OMstatus OMputObject(OMdev dev)+
+\item \verb+OMstatus OMputEndObject(OMdev dev)+
+\end{itemize}
+These functions should be called before and after an OpenMath object
+in constructed in a device. In particular, the \verb+OMputEndObject+
+function insures that the object has been completely written if any
+buffering was used.
+
+\subsection{Writing Basic Objects}
+
+Basic OpenMath objects are written using these functions:
+\begin{itemize}
+\item \verb+OMstatus OMputInt32(OMdev dev, int n)+
+\item
+\begin{verbatim}
+OMstatus OMputBigInt(OMdev dev, const char *data, int len, int sign,
+ OMbigIntType format)
+\end{verbatim}
+\item \verb+OMstatus OMputFloat64(OMdev dev, double *f)+
+\item \verb+OMstatus OMputByteArray(OMdev dev, const char *data, int len)+
+\item \verb+OMstatus OMputString(OMdev dev, const char *s)+
+\item \verb+OMstatus OMputVar(OMdev dev, const char *name)+
+\item \verb+OMstatus OMputSymbol(OMdev dev, const char *cd, const char *name)+
+\end{itemize}
+
+The {\tt char *} arguments of {\tt OMputString}, {\tt OMputVar} and {\tt
+OMputSymbol} are null-terminated strings. There are other functions that
+accept non null-terminated arrays of characters with their length.
+These are
+\begin{itemize}
+\item \verb+OMstatus OMputStringN(OMdev dev, const char *str, int len)+
+\item \verb+OMstatus OMputVarN(OMdev dev, const char *var, int len)+
+\item
+\begin{verbatim}
+OMstatus OMputSymbolN(OMdev dev, const char *cd, int clen,
+ const char *name, int nlen)
+\end{verbatim}
+\end{itemize}
+
+The format for the {\tt data} argument of the {\tt OMputBigInt} function is
+given by {\tt format}. When {\tt format} is {\tt OMBIbase10}, it is the
+sequence of character of its base 10 representation without sign (most
+significant digit first). The sign of the big integer is given by the
+{\tt sign} argument that should be an integer greater or
+equal to zero for a positive integer and less than zero for a negative
+one. For example, the following line outputs the value of $20!$ to {\tt dev}:
+\begin{verbatim}
+OMputBigInt(dev, "265252859812191058636308480000000", 33, 1, OMBIbase10);
+\end{verbatim}
+
+\subsection{Writing Structured Objects}
+
+The following functions are used to mark the beginning and end of the
+structured objects. They should be called in nested pairs, correctly
+bracketed:
+\begin{itemize}
+\item \verb+OMstatus OMputApp(OMdev dev)+
+\item \verb+OMstatus OMputEndApp(OMdev dev)+
+\item \verb+OMstatus OMputAttr(OMdev dev)+
+\item \verb+OMstatus OMputEndAttr(OMdev dev)+
+\item \verb+OMstatus OMputBind(OMdev dev)+
+\item \verb+OMstatus OMputEndBind(OMdev dev)+
+\item \verb+OMstatus OMputBVar(OMdev dev)+
+\item \verb+OMstatus OMputEndBVar(OMdev dev)+
+\item \verb+OMstatus OMputAtp(OMdev dev)+
+\item \verb+OMstatus OMputEndAtp(OMdev dev)+
+\item \verb+OMstatus OMputError(OMdev dev)+
+\item \verb+OMstatus OMputEndError(OMdev dev)+
+\end{itemize}
+
+Here is an example showing how to use these functions to output $\sin x + y$,
+where $x$ and $y$ are represented as variables and $\sin$ is the symbol whose
+name is {\tt sin} in the {\tt Basic} content dictionary. This can be done
+using the following sequence:
+\begin{verbatim}
+OMputObject(dev);
+OMputApp(dev);
+ OMputSymbol(dev, "Basic", "sin");
+ OMputApp(dev)
+ OMputSymbol(dev, "Basic", "+");
+ OMputVar(dev, "x");
+ OMputVar(dev, "y");
+ OMputEndApp(dev);
+OMputEndApp(dev);
+OMputEndObject(dev);
+\end{verbatim}
+
+\section{Functions to Extract OpenMath Expressions from Devices}
+
+\subsection{Testing the type of the current token}
+
+The first step in decoding an expression from a device is to call the
+{\tt OMgetType} function
+\begin{itemize}
+\item \verb+OMstatus OMgetType(OMdev dev, OMtokenType *type)+
+\end{itemize}
+so that the correct function can be called to recover the current token.
+
+{\tt OMgetType} returns via its {\tt type} argument an {\tt OMtokenType}
+object indicating the type of the next object to be read from the device.
+{\tt OMtokenType} is an enumerated type defined as
+\begin{verbatim}
+typedef enum OMtokenType {
+ OMtokenUnknown, /* error catching trick */
+ OMtokenInt32,
+ OMtokenBigInt,
+ OMtokenFloat64,
+ OMtokenByteArray,
+ OMtokenVar,
+ OMtokenString,
+ OMtokenSymbol,
+ OMtokenComment,
+ OMtokenApp, OMtokenEndApp,
+ OMtokenAttr, OMtokenEndAttr,
+ OMtokenAtp, OMtokenEndAtp,
+ OMtokenError, OMtokenEndError,
+ OMtokenObject, OMtokenEndObject,
+ OMtokenBind, OMtokenEndBind,
+ OMtokenBVar, OMtokenEndBVar,
+} OMtokenType;
+\end{verbatim}
+Note that the type of the current token can be tested multiple times. Two
+successive calls to {\tt OMgetType} will always return the same result if no
+other {\tt OMget...} function was called in between.
+
+\subsection{Extracting the current token}
+
+\noindent
+The following functions are used to read the basic OpenMath objects from
+devices:
+\begin{itemize}
+\item \verb+OMstatus OMgetInt32(OMdev dev, int *i)+
+\item \verb+OMstatus OMgetFloat64(OMdev dev, double *d)+
+\item
+\begin{verbatim}
+OMstatus OMgetBigInt(OMdev dev, char **data, int *len, int *sign,
+ OMbigIntType *fmt)
+\end{verbatim}
+\item
+\begin{verbatim}
+OMstatus OMgetBigIntN(OMdev dev, char *data, int len, int *sign,
+ OMbigIntType *fmt)
+\end{verbatim}
+\item \verb+OMstatus OMgetByteArray(OMdev dev, char **data, int *len)+
+\item \verb+OMstatus OMgetByteArrayN(OMdev dev, char *data, int len)+
+\item \verb+OMstatus OMgetString(OMdev dev, char **str)+
+\item \verb+OMstatus OMgetStringN(OMdev dev, char *str, int len)+
+\item \verb+OMstatus OMgetVar(OMdev dev, char **var)+
+\item \verb+OMstatus OMgetVarN(OMdev dev, char *var, int len)+
+\item \verb+OMstatus OMgetSymbol(OMdev dev, char **cd, char **name)+
+\item
+\begin{verbatim}
+OMstatus OMgetSymbolN(OMdev dev, char *cd, int clen, char *name, int nlen)
+\end{verbatim}
+\end{itemize}
+The functions that return variable size data exist in two versions. A simple
+version that does the necessary memory allocation itself
+(using {\tt OMmalloc}) and a
+version (suffixed with {\tt N}) that lets the user do the allocation itself.
+The size of the needed area can be determined with the following function:
+\begin{itemize}
+\item \verb+int OMgetLength(OMdev dev)+ returns the length of the next
+object.
+\end{itemize}
+that works for big integers, byte arrays, strings and variables. For symbols,
+the following function returns both the length of the content dictionary name
+and the length of the symbol name:
+\begin{itemize}
+\item \verb+OMstatus OMgetSymbolLength(OMdev dev, int *clen, int *nlen)+
+\end{itemize}
+
+When the current token does not carry any data i.e. when
+{\tt OMgetType} returns a marker, i.e. one of:
+\begin{itemize}
+\item {\tt OMtokenApp},
+\item {\tt OMtokenEndApp},
+\item {\tt OMtokenAttr},
+\item {\tt OM tokenEndAttr},
+\item {\tt OMtokenAtp},
+\item {\tt OMtokenEndAtp},
+\item {\tt OMtokenError},
+\item {\tt OMtokenEndError},
+\item {\tt OMtokenObject},
+\item {\tt OMtokenEndObject},
+\item {\tt OMtokenBind},
+\item {\tt OMtokenEndBind},
+\item {\tt OMtokenBVar}
+\item {\tt OMtokenEndBVar}
+\end{itemize}
+it is necessary to call the correct function to remove the marker. The
+available functions are
+
+\begin{itemize}
+\item \verb+OMstatus OMgetObject(OMdev dev)+
+\item \verb+OMstatus OMgetEndObject(OMdev dev)+
+\item \verb+OMstatus OMgetApp(OMdev dev)+
+\item \verb+OMstatus OMgetEndApp(OMdev dev)+
+\item \verb+OMstatus OMgetAttr(OMdev dev)+
+\item \verb+OMstatus OMgetEndAttr(OMdev dev)+
+\item \verb+OMstatus OMgetAtp(OMdev dev)+
+\item \verb+OMstatus OMgetEndAtp(OMdev dev)+
+\item \verb+OMstatus OMgetBind(OMdev dev)+
+\item \verb+OMstatus OMgetEndBind(OMdev dev)+
+\item \verb+OMstatus OMgetBVar(OMdev dev)+
+\item \verb+OMstatus OMgetEndBVar(OMdev dev)+
+\item \verb+OMstatus OMgetError(OMdev dev)+
+\item \verb+OMstatus OMgetEndError(OMdev dev)+
+\end{itemize}
+
+All the previous functions return {\tt OMsuccess} when they succeed. When
+they return something else, there has been a problem such as calling the
+wrong function ({\tt OMgetApp} when there is not a ``beginning of
+application'' mark) or a system error.
+
+The sequence of calls to read an expression is thus completely similar
+(if we omit the calls to {\tt OMgetType}) to the sequence of calls to
+write the expression. For example, the previous expression ($\sin x + y$)
+can be recovered via the sequence:
+\begin{verbatim}
+OMgetObject(dev);
+OMgetApp(dev);
+ OMgetSymbol(dev, ...);
+ OMgetApp(dev);
+ OMgetSymbol(dev, ...);
+ OMgetVar(dev, ...);
+ OMgetVar(dev, ...);
+ OMgetEndApp(dev);
+OMgetEndApp(dev);
+OMgetEndObject(dev);
+\end{verbatim}
+
+\verb+OMgetInt32(OMdev dev, int *i)+ returns the integer through its {\tt i}
+argument.
+
+\begin{verbatim}
+OMgetBigInt(OMdev dev, char **data, int *len, int *sign, OMbigIntType *fmt)
+\end{verbatim}
+returns the data corresponding to the big integer in {\tt data}, its length
+in {\tt len}, its sign in {\tt sign} and its format in {\tt fmt}.
+
+\begin{verbatim}
+OMgetBigIntN(OMdev dev, char *data, int len, int *sign, OMbigIntType *fmt)
+\end{verbatim}
+copies the data corresponding to the big integer in {\tt data} buffer that
+should be (at least) {\tt len} characters long. The sign and format are
+returned in the {\tt sign} and {\tt fmt} arguments.
+
+\verb+OMgetByteArray(OMdev dev, char **data, int *len)+ returns the byte
+array through its {\tt data} argument. Its length is returned via the
+{\tt len} argument.
+
+\verb+OMgetByteArrayN(OMdev dev, char *data, int len)+ copies the byte array
+in the {\tt data} buffer that should be (at least) {\tt len} characters
+long.
+
+\verb+OMgetString(OMdev dev, char **str)+ returns the string trough its
+{\tt str} argument.
+
+\verb+OMgetStringN(OMdev dev, char *str, int len)+ copies the string
+in the {\tt str} buffer whose length should be (at least) {\tt len}.
+If {\tt len} is greater than the actual length of the string, a null
+character is added at the end of {\tt str}.
+
+\verb+OMgetVar(OMdev dev, char **var)+ returns the name of the
+variable (as a null-terminated string) in its {\tt var} argument
+
+\verb+OMgetVarN(OMdev dev, char *var, int len)+ copies the name of the
+variable in the {\tt var} buffer, whose length should be (at least)
+{\tt len}.
+If {\tt len} is greater than the actual length of the variable name, a null
+character is added at the end of {\tt var}.
+
+\verb+OMgetSymbol(OMdev dev, char **cd, char **name)+ returns the content
+dictionary and the name of the symbol through the {\tt cd} and {\tt name}
+arguments.
+
+\verb+OMgetSymbolN(OMdev dev, char *cd, int clen, char *name, int nlen)+
+copies the content dictionary and the name of the symbols in the {\tt cd} and
+{\tt name} buffers. {\tt cd} should be at least {\tt clen} character long and
+{\tt name} should be at least {\tt nlen} long. When there is enough room
+(based on {\tt clen} or {\tt nlen}) a null character is added after the last
+character of the name ({\tt cd} or {\tt name}).
+
+\section{Comments in the SGML/XML Encodings}
+
+The library can also output and read comments (SGML/XML comments) with the
+following functions:
+\begin{itemize}
+\item \verb+OMstatus OMputComment(OMdev dev, char *comment)+
+\item \verb+OMstatus OMputCommentN(OMdev dev, char *comment, int len)+
+\item \verb+OMstatus OMgetComment(OMdev dev, char **comment)+
+\item \verb+OMstatus OMgetCommentN(OMdev dev, char *comment, int len)+
+\end{itemize}
+
+By default, comments are silently ignored by the library when reading
+OpenMath objects (and writing them using the binary encoding).
+The function
+\begin{itemize}
+\item \verb+OMbool OMignoreComment(OMdev dev, OMbool set)+
+\end{itemize}
+changes this behaviour. When called with {\tt OMfalse}, comments are passed
+to the application: the {\tt OMgetType} function will return
+{\tt OMtokenComment} when the current token is a comment and the
+{\tt OMgetComment} or {\tt OMgetCommentN} functions should be used to get the
+comments. When {\tt OMignoreComment} is called with {\tt OMtrue}, comments
+are ignored.
+
+\section{I/O Functions for Devices}
+
+We provide four functions that produce {\tt OMIO} objects for
+devices. These functions provide I/O through the {\tt stdio} library
+(on {\tt FILE} object), file descriptors and character strings.
+
+\begin{itemize}
+\item \verb+OMIO OMmakeIOFile(FILE *f)+ associates the device with the
+file pointer {\tt f}.
+\item \verb+OMIO OMmakeIOfd(int fd)+ associates the device with the file
+descriptor {\tt fd}.
+\item \verb+OMIO OMmakeIOHandle(HANDLE handle)+ associates the device with a
+file handle *Windows specific version of \verb+OMmakeIOfd()+.{\tt fd}.
+\item \verb+OMIO OMmakeIOString(char **s)+ associates the device with a
+string.
+\end{itemize}
+For example, the following code opens a device that reads from standard
+input:
+\begin{verbatim}
+dev = OMmakeDevice(OMencodingSGML, OMmakeIOFile(stdin));
+\end{verbatim}
+
+The {\tt OMmakeIOString} builds an input device that reads from a string
+or an output device that writes to a string. For input, {\tt s} must point to
+a character string (null terminated). For output, {\tt s} will point to a
+string allocated by the library (note that the string {\tt s} points to can
+be reallocated by the library).
+
+\section{Communications}
+
+A communication layer can be put above the device layer. In fact, the
+I/O structure in a device provides all the necessary support to use
+any transmission or communication means. This library directly
+provides some connection-oriented, client-server facilities (based on
+{\sc tcp}).
+
+A set of functions are used to set up connections. Connections are described
+by the {\tt OMconn} type. An {\tt OMconn} is a (pointer to a) structure with
+two user-accessible fields {\tt in} and {\tt out}. {\tt in} is a pointer to a
+device to be used for input. {\tt out} is pointer to a device to be used for
+output. These devices use the binary encoding.
+
+An {\tt OMconn} object is made with the following function:
+\begin{itemize}
+\item \verb+OMconn OMmakeConn(int timeout)+
+\end{itemize}
+where {\tt timeout} is a timeout for the connection, expressed in
+milliseconds.
+
+\begin{itemize}
+\item \verb+OMdev OMconnIn(OMconn conn)+ returns the input device
+associated with the connection.
+\item \verb+OMdev OMconnOut(OMconn conn)+ returns the output device
+associated with the connection.
+\end{itemize}
+
+\subsection{Functions to Initiate an {\tt OMconn}}
+
+The functions we provide can be divided in two classes. The first one
+simply establishes an interprocess communication using {\sc IP} addresses.
+The second one provides functions that can be used to launch a server.
+The addresses used are then generated by the library.
+
+\subsubsection{Simple Connections Functions}
+
+The following functions allow a client OpenMath application to contact an
+OpenMath server at a specified address:
+\begin{itemize}
+\item \verb+OMstatus OMconnTCP(OMconn conn, char *machine, int port)+
+\item \verb+OMstatus OMconnUnix(OMconn conn, char *file)+
+\end{itemize}
+These functions first physically establish the connection. Then, they enter
+negotiation with the server (they send the first message). When they return,
+the negotiation is finished and the devices in the {\tt conn} argument are
+ready.
+
+On the server side, the following functions provide bindings at specified
+addresses and take care of the negotiation:
+\begin{itemize}
+\item \verb+OMstatus OMbindTCP(OMconn conn, int port)+
+\item \verb+OMstatus OMbindUnix(OMconn conn, char *file)+
+\end{itemize}
+
+All four the previous functions block until the connection is established
+(and negotiation is over) or the timeout of the {\tt conn} argument is
+reached.
+
+The following function returns the file descriptor associated with a device.
+This is intended to be used when there is a need to poll the device (through
+the {\tt select} or {\tt poll} system calls).
+\begin{itemize}
+\item \verb+OMdeviceFd(OMdev dev)+
+\end{itemize}
+
+\subsubsection{Functions that Launch Servers}
+
+These functions provide the same functionalities for launching a
+server that were provided in the {\sc asap} library.
+
+In this model, the client calls {\tt OMlaunch} with a machine name
+{\tt mach} and a string {\tt cmd} that is executed via {\tt rsh} on
+machine {\tt mach} as a shell command line. This command is supposed
+to launch the server program. The command is executed in an
+environment (in the {\sc unix} sense) where some variables are
+associated with an address on the machine that runs the client. The
+server can then connect to the client with the {\tt OMserveClient}
+function.
+
+If the machine name is {\tt localhost}, the command is started on the
+same machine (without calling {\tt rsh}).
+
+\begin{itemize}
+\item
+\begin{verbatim}
+OMstatus OMlaunchEnv(OMconn conn, char *machine, char *command, char *env)
+\end{verbatim}
+\item \verb+OMstatus OMlaunch(OMconn conn, char *machine, char *command)+
+\item \verb+OMstatus OMserveClient(OMconn conn)+
+\end{itemize}
+
+The environment variables passed to the server (launched program) are
+{\verb+OM_CALLER_UNIX_SOCKET+} (when a local connection is required) and
+{\verb+OM_CALLER_MACHINE+} and {\verb+OM_CALLER_PORT+} (for internet
+connections).
+
+The {\tt OMlaunchEnv} function enables the command to be run with a
+particular environment (in the {\sc unix} sense). For example to run a
+{\tt plot} server on the {\tt kama} machine, we could use a piece of code
+such as
+\begin{verbatim}
+conn = OMmakeConn(2000);
+OMlaunchEnv(conn, "kama", "plot", "DISPLAY=rati:0 PATH=/users/bin");
+\end{verbatim}
+
+\subsubsection{Termination}
+
+\begin{itemize}
+\item \verb+OMstatus OMconnClose(OMconn conn)+
+\end{itemize}
+
+\section{Parameters}
+
+The library internally uses three functions that can be supplied by the user.
+\begin{itemize}
+\item \verb+extern void *(*OMmalloc) (size_t size)+
+\item \verb+extern void *(*OMrealloc) (void *ptr, size_t size)+
+\item \verb+extern void (*OMfree) (void *ptr)+
+\end{itemize}
+
+\begin{itemize}
+\item {\tt OMmalloc} is used for all memory allocations in the library.
+The default value is the {\tt malloc} function.
+\item {\tt OMfree} is used for deallocations. The default value is the
+{\tt free} function.
+\item {\tt OMfatal} is invoked when a fatal error is detected in the library
+(for example when memory allocation failed or when an inconsistency is
+detected in the library code data structures). The default value just does an
+{\tt exit}.
+\end{itemize}
+{\tt OMfatal} is declared as
+{\tt \verb+extern void (*OMfatal)(OMstatus status)+}.
+All memory allocations and deallocations in the library are done through the
+{\tt OMmalloc} and {\tt OMfree} functions.
+
+\section{Miscellaneous Functions and Variables}
+
+\begin{itemize}
+\item \verb+char *OMstatusToString(OMstatus status)+ converts a status to a
+human readable string.
+\item \verb+char *OMtokenTypeToString(OMtokenType ttype)+ converts a
+{\tt tokenType} to a human readable string.
+\item \verb+OMencodingType OMgetDeviceEncoding(OMdev dev)+ returns the
+encoding actually used by the device.
+\item \verb+char *OMlibDynamicInfo(void)+
+\item \verb+extern const char *OMlibVersion+ is the version of the library.
+\item \verb+extern const char *OMlibInfo+ contains some textual information
+about the library.
+\end{itemize}
+
+\section{The OM.h header file}
+\begin{verbatim}
+#ifndef __OM_h__
+#define __OM_h__
+
+/*
+ * All types used through API.
+ */
+
+/* These types are anonymized by the mean of a generic pointer.
+ * You should not allocate or dereference objects of these types.
+ * API (hopefully) provides you with all needed methods.
+ * If you find any that are not included, please refer to
+ * us rather than using private structures.
+ * ie: If you need to do something like
+ * malloc(sizeof(OMdevStruct));
+ * or
+ * OMdevStruct * pDev;
+ * pDev->anyField = something;
+ * this probably means we need to discuss your problem.
+ */
+
+/* A device is an abstraction for put/get of OpenMath tokens */
+typedef struct OMdevStruct *OMdev;
+
+/* IO is a device field, (the physical IO channel) */
+typedef struct OMIOStruct *OMIO;
+
+
+/* Error status that may be returned
+ */
+typedef enum OMstatus {
+ /* Last call was successful. */
+ OMsuccess = 0,
+ /* Last call failed for some undetermined reason. */
+ OMfailed = 1,
+ /* Last call failed for memory reasons. */
+ OMnoMem,
+ /* Last call failed during some system call. */
+ OMerrorSys,
+ /* Last call to some OMget* function failed due to an unexpected EOF
+ on input IO. */
+ OMemptyIO,
+ /* Last call to some OMget* function failed because there is no more
+ token on device. */
+ OMnoMoreToken,
+ /* Last call to some OMget* function timeouted. */
+ OMtimeoutedRead,
+ /* Last call to some OMget* function failed due to malformed input.
+ (this error covers all low level lexical or syntactic problems). */
+ OMmalformedInput,
+ /* Last call to OMbindTCP failed because address is already in use
+ (EADDRINUSE). */
+ OMaddrInUse,
+ /* Last call to OMconnTCP failed to set connection. */
+ OMconnectFailed,
+ /* Last call trigered some not (yet) implemented code in this lib. */
+ OMnotImplemented,
+ /* Last call caused some internal trouble. */
+ OMinternalError
+} OMstatus;
+
+/* All OpenMath token kinds are identified by one of these types.
+ * Values given in this enum have been chosen to:
+ * - avoid conflicts whith specific XML characters
+ * to help automatic detection of encoding type.
+ * (no: '\t'(9) '\r'(13) '\n'(10) '<'(60) or ' '(32))
+ * - keep some bits (3) available for special encodings purpose
+ * (eg: sharing or big len flags in binary encoding)
+ */
+typedef enum OMtokenType {
+ OMtokenUnknown = 0, /* error catching trick */
+ OMtokenInt32 = 1,
+ OMtokenBigInt = 2,
+ OMtokenFloat64 = 3,
+ OMtokenByteArray = 4,
+ OMtokenVar = 5,
+ OMtokenString = 6,
+ OMtokenWCString = 7,
+ OMtokenSymbol = 8,
+ OMtokenComment = 15,
+ OMtokenApp = 16, OMtokenEndApp = 17,
+ OMtokenAttr = 18, OMtokenEndAttr = 19,
+ OMtokenAtp = 20, OMtokenEndAtp = 21,
+ OMtokenError = 22, OMtokenEndError = 23,
+ OMtokenObject = 24, OMtokenEndObject = 25,
+ OMtokenBind = 26, OMtokenEndBind = 27,
+ OMtokenBVar = 28, OMtokenEndBVar = 29
+} OMtokenType;
+
+typedef enum OMbigIntType {
+ OMbigIntUnknown = 0,
+ /* this is base 10, digits in normal order (MSB) */
+ OMbigIntBase10,
+ /* this is base 16, digits in normal order (MSB) */
+ OMbigIntBase16
+} OMbigIntType;
+
+/* Encodings should not be "user visible"
+ * We thus refer to encoding as "symbolic constants" from this enum type. */
+typedef enum OMencodingType {
+ /* You may set an input stream to "unknown encoding".
+ * By doing this, you let library auto detect the
+ * encoding type of the device during first token input.*/
+ OMencodingUnknown = 0,
+ /* Binary encoding, more compact than XML one. */
+ OMencodingBinary,
+ /* XML-like encoding, human readable. */
+ OMencodingXML,
+} OMencodingType;
+
+/* This is a portable equivalent to wchar_t for unicode strings */
+typedef unsigned short OMUCS2;
+
+/* Replacment for lacking C bools */
+typedef unsigned char OMbool;
+#define OMfalse (0)
+#define OMtrue (1)
+
+/*
+ * Some global variables
+ */
+
+/* Version of this lib (eg: "1.0") */
+extern const char *OMlibVersion;
+
+/* Some textual information about this lib (eg: "debug is on" */
+extern const char *OMlibInfo;
+
+/* These pointers allow you to redefine memory managment functions
+ used in lib. */
+extern void *(*OMmalloc) (size_t size);
+extern void *(*OMrealloc) (void *ptr, size_t size);
+extern void (*OMfree) (void *ptr);
+
+/* If set, this function will be called by OMfatal, thus you may use it for
+ error handling (by default it is set to exit()) */
+extern void (*OMfatal) (OMstatus status);
+
+
+
+/* for C++ includes */
+#ifdef __cplusplus
+#define OMbeginPrototypes extern "C" {
+#define OMendPrototypes }
+#else /*__cplusplus */
+#define OMbeginPrototypes
+#define OMendPrototypes
+#endif /*__cplusplus */
+
+/*
+ * Prototypes of OpenMath API
+ */
+
+/* Prototypes that are spread along all headers are repeated here.
+ * - This should ease the API users.
+ * (docs are fine but source is always the ultimate help)
+ * - This allow a cleaner embeding of library
+ * (no need to install all .h! just take this one and the .a)
+ */
+OMbeginPrototypes
+#ifndef OM_DEV
+/* this part is automaticaly updated, do NOT edit below */
+/** Prototypes */
+/* OMPut* functions.
+ * They all take a device to put token to.
+ * Some of them need more parameters to define the token content.
+ * They are thoroughly documented in OpenMath Specification shiped
+ * with the library.
+ * return: a status that reflect the operation success.
+ */
+extern OMstatus OMputInt32(OMdev dev, int n);
+extern OMstatus OMputFloat64(OMdev dev, double *d);
+extern OMstatus OMputBigInt(OMdev dev, const char *data, int len,
+ int sign, OMbigIntType format);
+extern OMstatus OMputByteArray(OMdev dev, const char *data, int len);
+/* OMputString*
+ * If you want to output plain 8bits C like strings there is no need
+ * to use the OMputWCString* functions. This one is more efficient
+ * (faster and more compact output for some encodings)
+ */
+extern OMstatus OMputString(OMdev dev, const char *str);
+extern OMstatus OMputStringN(OMdev dev, const char *str, int len);
+/* OMputWCString
+ * If you are using wide char strings you need to output them
+ * with that function rather than with OMputString.
+ * (It takes endianess into account)
+ */
+extern OMstatus OMputWCString(OMdev dev, const OMUCS2 * wcstr);
+extern OMstatus OMputVar(OMdev dev, const char *var);
+extern OMstatus OMputVarN(OMdev dev, const char *var, int len);
+extern OMstatus OMputSymbol(OMdev dev, const char *cd, const char *name);
+extern OMstatus OMputSymbolN(OMdev dev, const char *cd, int clen,
+ const char *name, int nlen);
+extern OMstatus OMputApp(OMdev dev);
+extern OMstatus OMputEndApp(OMdev dev);
+extern OMstatus OMputAttr(OMdev dev);
+extern OMstatus OMputEndAttr(OMdev dev);
+extern OMstatus OMputAtp(OMdev dev);
+extern OMstatus OMputEndAtp(OMdev dev);
+extern OMstatus OMputBind(OMdev dev);
+extern OMstatus OMputEndBind(OMdev dev);
+extern OMstatus OMputBVar(OMdev dev);
+extern OMstatus OMputEndBVar(OMdev dev);
+extern OMstatus OMputObject(OMdev dev);
+extern OMstatus OMputEndObject(OMdev dev);
+extern OMstatus OMputError(OMdev dev);
+extern OMstatus OMputEndError(OMdev dev);
+extern OMstatus OMputComment(OMdev dev, const char *comment);
+extern OMstatus OMputCommentN(OMdev dev, const char *comment, int len);
+/* OMgetType
+ * Get the type of the current token on device /
+ * dev: device to look at.
+ * type: where to store returned type.
+ * return: 0 or some error code
+ */
+extern OMstatus OMgetType(OMdev dev, OMtokenType * type);
+/* OMgetLength
+ * Get the current token length.
+ * dev: device to read from
+ * len: where to put the token length
+ * the last '\0' for string like tokens is not counted
+ * (rem: for WCString it is the number of bytes not the number of
+ * wide chars)
+ * return: 0 or some error code
+ */
+extern OMstatus OMgetLength(OMdev dev, int *len);
+/* OMgetSymbolLength
+ * Get the current token (wich is assumed to be a symbol) lengths.
+ * dev: device to read from
+ * clen: where to put the cd length (not counting the last '\0')
+ * nlen: where to put the name length (not counting the last '\0')
+ * return: 0 or some error code
+ */
+extern OMstatus OMgetSymbolLength(OMdev dev, int *clen, int *nlen);
+/* OMGet* functions.
+ * They all take a device to get token from.
+ * Some of them need more parameters to fill with the token content.
+ * They are thoroughly documented in OpenMath Specification shiped with
+ * the library.
+ * return: a status that reflect the operation success.
+ */
+extern OMstatus OMgetInt32(OMdev dev, int *i);
+extern OMstatus OMgetFloat64(OMdev dev, double *d);
+extern OMstatus OMgetBigInt(OMdev dev, char **data, int *len, int *sign,
+ OMbigIntType * format);
+extern OMstatus OMgetBigIntN(OMdev dev, char *data, int len, int *sign,
+ OMbigIntType * format);
+extern OMstatus OMgetByteArray(OMdev dev, char **data, int *len);
+extern OMstatus OMgetByteArrayN(OMdev dev, char *data, int len);
+/* OMgetString*
+ * Beware! You are not suposed to use these functions unless you know
+ * for sure you are reading plain 8bits strings.
+ * Thus it is here only for speed/space consideration in very
+ * specific applications.
+ * If input is a 16 bit char string and you read it with these
+ * functions you will lose the 8 most significant bits of each char.
+ * You should rather refer to OMgetWCString* functions.
+ */
+extern OMstatus OMgetString(OMdev dev, char **str);
+extern OMstatus OMgetStringN(OMdev dev, char *str, int len);
+/* OMgetWCString*
+ * These functions return 16 bits wide strings. (regardless input
+ * was done in 8 or 16 bits mode).
+ * Thus, most if not all applications should use these functions
+ * preferably to OMgetString*.
+ */
+extern OMstatus OMgetWCString(OMdev dev, OMUCS2 ** wcstr);
+/* BEWARE: the is suposed to be the length in bytes for the
+ * preallocated buffer (not the length in number of wide chars)
+ */
+extern OMstatus OMgetWCStringN(OMdev dev, OMUCS2 * wcstr, int len);
+extern OMstatus OMgetVar(OMdev dev, char **var);
+extern OMstatus OMgetVarN(OMdev dev, char *var, int len);
+extern OMstatus OMgetSymbol(OMdev dev, char **cd, char **name);
+extern OMstatus OMgetSymbolN(OMdev dev, char *cd, int clen, char *name,
+ int nlen);
+extern OMstatus OMgetApp(OMdev dev);
+extern OMstatus OMgetEndApp(OMdev dev);
+extern OMstatus OMgetAttr(OMdev dev);
+extern OMstatus OMgetEndAttr(OMdev dev);
+extern OMstatus OMgetAtp(OMdev dev);
+extern OMstatus OMgetEndAtp(OMdev dev);
+extern OMstatus OMgetBind(OMdev dev);
+extern OMstatus OMgetEndBind(OMdev dev);
+extern OMstatus OMgetBVar(OMdev dev);
+extern OMstatus OMgetEndBVar(OMdev dev);
+extern OMstatus OMgetObject(OMdev dev);
+extern OMstatus OMgetEndObject(OMdev dev);
+extern OMstatus OMgetError(OMdev dev);
+extern OMstatus OMgetEndError(OMdev dev);
+extern OMstatus OMgetComment(OMdev dev, char **comment);
+extern OMstatus OMgetCommentN(OMdev dev, char *comment, int len);
+/* OMbeginObject
+ * Must be called before every new OpenMath object put.
+ * (Not before every token!)
+ * dev: device where new object is to be put.
+ * return: status describing operation success
+ */
+extern OMstatus OMbeginObject(OMdev dev);
+/* OMendObject
+ * Must be called after every OpenMath object put.
+ * (Not after every token!)
+ * dev: device where object has been put.
+ * return: status describing operation success
+ */
+extern OMstatus OMendObject(OMdev dev);
+/* OMignoreComment
+ * Set behavior of a device concerning comments.
+ * (Comments on an input device may safely be ignored.)
+ * dev: device to modify
+ * set: If set == OMtrue then device will ignore incoming comments
+ * If set == OMfalse then device will process incoming comments
+ * like other tokens.
+ * By default comments are ignored.
+ * Whatever is value, output of comments is always done.
+ * return: previous value
+ */
+extern OMbool OMignoreComment(OMdev dev, OMbool set);
+/* OMtokenCount
+ * Reports the numbe rof tokens that have been in/output on a device
+ * dev: devive to examine
+ * inTokenNb: where to store number of input tokens (if not NULL)
+ * outTokenNb: where to store number of output tokens (if not NULL)
+ */
+extern void OMtokenCount(OMdev dev, int *inTokenNb, int *outTokenNb);
+/* OMgetDeviceEncoding
+ * Get the currnet encoding used by a device
+ * dev: device to examine
+ * return: current encoding
+ */
+extern OMencodingType OMgetDeviceEncoding(OMdev dev);
+/* OMsetDeviceEncoding
+ * Set the encoding that will be used on a device
+ * BEWARE: changing encoding on a device that has already been used
+ * for IO is unsafe.
+ * but seting encoding on a new device is safe.
+ * (in some occasions, it is not easy to know which encoding to
+ * use at device creation)
+ * dev: device to modify
+ * encoding: encoding to use
+ */
+extern void OMsetDeviceEncoding(OMdev dev, OMencodingType encoding);
+/* OMmakeDevice
+ * Create a device from a low level IO
+ * Warning: "IO" should be a "generated" (new) structure as it contains some
+ * state that is private to the device. It is very dangerous for two devices
+ * to share the same "IO" structure.
+ * encoding: encoding scheme used by device
+ * IO: low level I/O suport for device
+ * return: a newly allocated device
+ */
+extern OMdev OMmakeDevice(OMencodingType encoding, OMIO IO);
+/* OMcloseDevice
+ * Close a device previously created with OMmakeDevice
+ * (embedded IO is closed too)
+ * dev: device to close
+ */
+extern void OMcloseDevice(OMdev dev);
+/* OMmakeIOFd
+ * Create a low level IO object from a file descriptor.
+ * (May be used on socket for instance.)
+ * fd: file descriptor to wrap into the OpenMath IO object.
+ * return: a newly allocated IO object.
+ */
+extern OMIO OMmakeIOFd(int fd);
+/* OMmakeIOFile
+ * Create a low level IO object from a FILE*.
+ * (May be used on stdin for instance.)
+ * fd: FILE* to wrap into the OpenMath IO object.
+ * return: a newly allocated IO object.
+ */
+extern OMIO OMmakeIOFile(FILE * f);
+/* OMmakeIOString
+ * Create a low level IO object from a string (NUL terminator is not needed).
+ * (May be used for copy/paste for instance.)
+ * s: pointer to string to use into the OpenMath IO object.
+ * - In case of input device the string must be NUL terminated.
+ * - In case of output device string may be reallocated
+ * to fit size of outcoming objects.
+ * return: a newly allocated IO object.
+ */
+extern OMIO OMmakeIOString(char **s);
+/* OMstatusToString
+ * Convert a status to a human readable string that explain its meaning
+ * status: status to explain
+ * return: corresponding string
+ */
+extern char *OMstatusToString(OMstatus status);
+/* OMtokenTypeToString
+ * Convert a tokenType to a human readable string
+ * ttype: type to convert
+ * return: corresponding string
+ */
+extern char *OMtokenTypeToString(OMtokenType ttype);
+/* OMsetVerbosityLevel
+ * When using API some infos may be loged.
+ * This set the required verbosity level.
+ * level: level of verbosity.
+ * 0 means nothing is nether printed
+ * 1 everything is printed (default)
+ * 2,... less verbose
+ * return: last verbosity level
+ */
+extern int OMsetVerbosityLevel(int level);
+/* OMsetVerbosityOutput
+ * When using API some infos may be loged.
+ * This set the destination for logs.
+ * logFile: where to output logs (default is stderr)
+ * return: last output
+ */
+extern FILE *OMsetVerbosityOutput(FILE * logFile);
+/* OMlibDynamicInfo
+ * Gather some informations about lib that can't be statically determined.
+ * Complete them with some relevant static infornation too.
+ * return: a newly allocated string
+ */
+extern char *OMlibDynamicInfo(void);
+/*** End Prototypes */
+/* end of automaticaly updated part */
+
+#ifdef WIN32
+#include "windows.h"
+
+/* OMmakeIOHandle
+ * Create a low level IO object from a widows handle.
+ * handle: windows handle to wrap into the OpenMath IO object.
+ * return: a newly allocated IO object.
+ */
+extern OMIO OMmakeIOHandle(HANDLE handle);
+extern void OMfreeIOHandle(OMIO io);
+#endif
+
+#else /* OM_DEV */
+/* The prototypes above are in fact collected from all these .h files */
+#include "OMbase.h"
+#include "OMdev.h"
+#include "OMdevFd.h"
+#include "OMdevFile.h"
+#include "OMdevString.h"
+#include "OMdevHandle.h"
+#include "OMencBin.h"
+#include "OMencXml.h"
+#include "OMmisc.h"
+#include "OMutf7.h"
+#endif /* OM_DEV */
+
+OMendPrototypes
+
+#endif /* __OM_h__ */
+\end{verbatim}
+
+\section{Axiom OpenMath stub functions}
These stub functions will eventually be expanded to handle OpenMath.
See the OpenMathDevice domain in Volume 10.3. Note that the argument
list for the Spad functions does not always match the argument list
@@ -39580,7 +41006,7 @@ domain in Volume 10.3.
\item SGML
\end{itemize}
-\section{Axiom specific functions}
+\subsection{Axiom specific functions}
This is used in OpenMathPackage in Volume 10.4.
\begin{verbatim}
(read OMdev) -> LispObject
@@ -39624,7 +41050,7 @@ Return true if Axiom supports this CD.
\end{chunk}
-\section{Lisp conversion functions}
+\subsection{Lisp conversion functions}
The lisp conversion functions are:
\begin{verbatim}
(toDev LispObject) -> OMdev
@@ -39651,7 +41077,7 @@ or from dev to enc.
\end{chunk}
-\section{Device manipulation functions}
+\subsection{Device manipulation functions}
\begin{verbatim}
(openFileDev LispObject, ints, ...) -> LispObject
(openStrDev LispObject, LispObject, LispObject) -> LispObject
@@ -39680,7 +41106,7 @@ This closes dev, flushing output if necessary.
\end{chunk}
-\section{Connection manipulation functions}
+\subsection{Connection manipulation functions}
These are covered in the OpenMathConnection domain in Volume 10.3.
\begin{verbatim}
(makeConn LispObject, LispObject) -> LispObject
@@ -39713,7 +41139,7 @@ These are covered in the OpenMathConnection domain in Volume 10.3.
\end{chunk}
-\section{Client/Server functions}
+\subsection{Client/Server functions}
These are covered in the OpenMathConnection domain in Volume 10.3.
See OMconn.h
\begin{verbatim}
@@ -39733,7 +41159,7 @@ See OMconn.h
\end{chunk}
-\section{Device input/output functions}
+\subsection{Device input/output functions}
Most of these functions are in the OpenMathDevice domain in Volume 10.3.
The only exception seems to be the om-stringPtrToString and
om-stringToStringPtr functions which are called in the domains that
@@ -43002,6 +44428,10 @@ This is part of the undo mechanism.
{\bf http://axiom.axiom-developer.org/axiom-website/documentation.html}
\bibitem{2} Daly, Timothy, ``The Axiom Wiki Website''\\
{\bf http://axiom.axiom-developer.org}
+\bibitem{3} Stephane Dalmas and Olivier Arsac ``OpenMath''
+Project SAFIR, INRIA Sophia Antipolis
+\bibitem{4} OpenMath Technical Overview
+\verb|www.openmath.org/overview/technical.html|
\end{thebibliography}
\chapter{Index}
\printindex
diff --git a/books/bookvolbib.pamphlet b/books/bookvolbib.pamphlet
index 332cbe8..b5bfd46 100644
--- a/books/bookvolbib.pamphlet
+++ b/books/bookvolbib.pamphlet
@@ -384,6 +384,10 @@ LCCN QA76.95 I59 1993
T. Beneke and W. Schwippert. Double-track into the future: MathCAD will
gain new users with Standard and Plus versions. Elektronik, 43(15) pp107-110,
July 1994, CODEN EKRKAR ISSN 0013-5658
+\bibitem[Bor00]{Bor00}
+Borwein, Jonathan
+``Multimedia tools for communicating mathematics''
+Springer-Verlag ISBN 3-540-42450-4 p58
\bibitem[BT94]{BT94}
R. Brown and A. Tonks ``Calculations with simplicial and cubical groups
in AXIOM'' Journal of Symbolic Computation 17(2) pp159-179 February 1994
@@ -415,6 +419,18 @@ combinatoire dans les graphs de Hamming et sa solution en Scratchpad''
(English: A combinatorial problem in Hamming Graphs and its solution in
Scratchpad) Rapports de recherche 1586, Institut National de Recherche en
Informatique et en Automatique, Le Chesnay, France, January 1992, 12pp
+\bibitem[CCR]{CCR}
+Caprotti, Olga, Cohen, Arjeh M., and Riem, Manfred
+``Java Phrasebooks for Computer Algebra and Automated Deduction''
+\verb|www.sigsam.org/bulletin/articles/132/paper8.pdf|
+\bibitem[CC99]{CC99}
+Capriotti, O. and Carlisle, D.
+``OpenMath and MathML: Semantic Mark Up for Mathematics''
+\verb|www.acm.org/crossroads/xrds6-2/openmath.html|
+\bibitem[CCCS]{CCCS}
+Capriotti, Olga, Cohen, Arjeh M., Cuypers, Hans, and Sterk, Hans
+``OpenMath Technology for Interactive Mathematical Documents''
+\verb|www.win.tue.nl/~hansc/lisbon.pdf|
\bibitem[Chu89]{Chu89}
Chudnovsky, D.V. and Chudnovsky, G.V.
``The computation of classical constants''
@@ -424,6 +440,18 @@ Chudnovsky, David and Jenks, Richard
``Computers in Mathematics''
International Conference on Computers and Mathematics July29-Aug1 1986
Marcel Dekker, Inc (1990) ISBN 0-8247-8341-7
+\bibitem[CCBS]{CCBS}
+Cohen, Arjeh M., Cuypers, Hans, Barreiro, Ernesto Reinaldo, Sterk, Hans
+``Interactive Mathematical Documents on the Web''
+Springer 9783540002576-c1.pdf
+\bibitem[CHK]{CHK}
+Cuypers, Hans, Hendriks, Maxim, and Knopper, Jan Willem
+``Interactive Geometry inside MathDox''
+\verb|www.win.tue.nl/~hansc/MathDox_and_InterGeo_paper.pdf|
+\bibitem[DGW]{DGW}
+Dalmas, St\'ephane, Gae\"tano, Marc, and Watt, Stephen
+``An OpenMath 1.0 Implementation''
+\verb|citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.116.4401.pdf|
\bibitem[Dal92]{Dal92}
S. Dalmas ``A polymorphic functional language applied to symbolic computation''
In Wang [Wan92] pp369-375 ISBN 0-89791-489-9 (soft cover) 0-89791-490-2
@@ -470,6 +498,10 @@ J. H. Davenport ``Primality testing revisited'' Technical Report TR2/93
(ATR/6)(NP2556) Numerical Algorithms Group, Inc., Downer's Grove, IL, USA
and Oxford, UK, August 1993
\verb|http://www.nag.co.uk/doc/TechRep/axiomtr.html|
+\bibitem[Dav00]{Dav00}
+Davenport, James
+``13th OpenMath Meeting''
+\verb|xml.coverpages.org/openmath13.html|
\bibitem[Dav10]{Dav10}
Davenport, J. H. ``Computer Algebra'' \hfill\\
\verb|staff.bath.ac.uk/masjhd/JHD-CA.pdf|
@@ -488,6 +520,10 @@ Computers and Mathematics November 1993, Vol 40, Number 9 pp1203-1210
Dewar, M. C. ``Manipulating Fortran Code in AXIOM and the AXIOM-NAG Link''
Proceedings of the Workshop on Symbolic and Numeric Computing, ed by Apiola, H.
and Laine, M. and Valkeila, E. pp1-12 University of Helsinki, Finland (1994)
+\bibitem{Dew]{Dew}
+Dewar, Mike
+``OpenMath: An Overview''
+\verb|www.sigsam.org/bulletin/articles/132/paper1.pdf|
\bibitem[DGJ84]{DGJ84}
J. Davenport, P. Gianni, R. Jenks, V. Miller, S. Morrison, M. Rothstein,
C. Sundaresan, R. Sutor and B. Trager ``Scratchpad'' Mathematical Sciences
@@ -573,6 +609,9 @@ In Miola [Mio90], pp56-60. ISBN 0-387-52531-9 (New York), 3-540-52531-9
Francois Fouche. ``Une implantation de l'algorithme de Kovacic en Scratchpad''
Technical report, Institut de Recherche Math{\'{e}}matique Avanc{\'{e}}e''
Strasbourg, France, 1990 31pp
+\bibitem[Fris]{Fris}
+Frisco ``Objectives and Results''
+\verb|http://www.nag.co.uk/projects/frisco/frisco/node3.htm
\bibitem[GCL92]{GCL92}
Geddes, Keith O., Czapor, Stephen R., and Labahn, George
``Algorithms For Computer Algebra'' Kluwer Academic Publishers
@@ -601,6 +640,10 @@ I. Gil. ``Computation of the Jordan canonical form of a square matrix (using
the Axiom programming language). In Wang [Wan92], pp138-145.
ISBN 0-89791-489-9 (soft cover), 0-89791-490-2 (hard cover)
LCCN QA76.95.I59 1992
+\bibitem[Gon96]{Gon96}
+Gonnet, Gaston H.
+``Official verion 1.0 of the Meta Content Dictionary''
+\verb|www.inf.ethz.ch/personal/gonnet/ContDict/Meta|
\bibitem[GJ71]{GJ71}
J. H. Griesmer and R. D. Jenks ``SCRATCHPAD/1 -- an interactive facility for
symbolic mathematics'' In Petrick [Pet71], pp42-58. LCCN QA76.5.S94 1971
@@ -661,6 +704,11 @@ L. Huguet and A. Poli, editors. Applied Algebra, Algebraic Algorithms and
Error-Correcting Codes. 5th International Conference AAECC-5 Proceedings.
Springer-Verlag, Berlin, Germany / Heildelberg, Germany / London, UK / etc.,
1989. ISBN 3-540-51082-6. LCCN QA268.A35 1987
+\bibitem[Leb08]{Leb08}
+Lebedev, Yuri
+``OpenMath Library for Computing on Riemann Surfaces''
+PhD thesis, Nov 2008 Florida State University
+\verb|www.math.fsu.edu/~ylebedev/research/HyperbolicGeometry.html|
\bibitem[Jan88]{Jan88}
R. Jan{\ss}en, editor. Trends in Computer Algebra, International Symposium
Bad Neuenahr, May 19-21, 1987, Proceedings, volume 296 of Lecture Notes in
@@ -734,6 +782,10 @@ an abstract datatype system for mathematical computation'' In Jan{\ss}en
\bibitem[JT94]{JT94}
R. D. Jenks and B. M. Trager. ``How to make AXIOM into a Scratchpad'' In ACM
[ACM94], pp32-40 ISBN 0-89791-638-7 LCCN QA76.95.I59 1994
+\bibitem[JT03]{JT03}
+Joswig, Michael and Takayama, Nobuki
+``Algebra, geometry, and software systems''
+Springer-Verlag ISBN 3-540-00256-1 p291
\bibitem[Ken99a]{Ken99a}
Kendall, W.S.
``Itovsn3 in AXIOM: modules, algebras and stochastic differentials''
@@ -847,6 +899,9 @@ Mathematical Software, 1(4) pp346-356 Dec. 1975 CODEN ACMSCU ISSN 0098-3500
\bibitem[Nor75a]{Nor75a}
Norman, A.C. ``The SCRATCHPAD Power Series Package''
IBM T.J. Watson Research RC4998
+\bibitem[OpenMa]{OpenMa}
+``OpenMath Technical Overview''
+\verb|www.openmath.org/overview/technical.html|
\bibitem[Oll89]{Oll89}
F. Ollivier ``Inversibility of rational mappings and structural
identifiablility in automatics'' In ACM [ACM89], pp43-54 ISBN 0-89791-325-6
@@ -1003,6 +1058,9 @@ IBM Research Report RC19529 (85075) May 12, 1994
\bibitem[Wat94a]{Wat94a}
Watt, Stephen M., et. al. ``A\# User's Guide''
Version 1.0.0 O($\epsilon{}^1$) June 8, 1994
+\bibitem[Wat95]{Wat95}
+Watt, S.M. et al, AXIOM Library Compiler Users Guide
+NAG Ltd, 1995
\bibitem[WJST90]{WJST90}
S.M. Watt, R.D. Jenks, R.S. Sutor, and B.M. Trager. ``The Scratchpad II
type system: Domains and subdomains'' in A.M. Miola, editor Computing Tools
@@ -1083,6 +1141,9 @@ Recherche RR-3562, INRIA, 1998
\bibitem[CS03]{CS03}
Conway, John H. and Smith, Derek, A., ``On Quaternions and Octonions''
A.K Peters, Natick, MA. (2003) ISBN 1-56881-134-9
+\bibitem[DA98]{DA98}
+Dalmas, Stephane and Arsac, Olivier ``The INRIA OpenMath Library''
+Projet SAFIR, INRIA Sophia Antipolis Nov 25, 1998
\bibitem[Fl01]{Fl01}
Fletcher, John P. ``Symbolic processing of Clifford Numbers in C++'',
Paper 25, AGACSE 2001.
@@ -1211,6 +1272,9 @@ the lazard/rioboo/trager formula in rational function integration''
Olver, Frank W., Lozier, Daniel W., Boisvert, Ronald F., Clark, Charles W. (ed)
``NIST Handbook of Mathematical Functions'' (2010) Cambridge University
Press ISBN 978-0-521-19225-5
+\bibitem[OpenM]{OpenM}
+``OpenMath Technical Overview''
+\verb|www.openmath.org/overview/technical.html|
\bibitem[Ost1845]{Ost1845}
M.W. Ostrogradsky. De l'int\'{e}gration des fractions
rationelles. {\sl Bulletin de la Classe Physico-Math\'{e}matiques de
diff --git a/changelog b/changelog
index acc0d84..702eea5 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,17 @@
+20111106 tpd src/axiom-website/patches.html 20111106.04.tpd.patch
+20111106 tpd books/bookvolbib Axiom OpenMath references
+20111106 tpd books/bookvol5 OpenMath support
+20111106 tpd zips/cds.tar.gz OpenMath support. add OpenMath CDs
+20111106 tpd src/axiom-website/patches.html 20111106.03.tpd.patch
+20111106 tpd books/bookvol10.3 remove GETREFV
+20111106 tpd src/interp/buildom.lisp remove GETREFV
+20111106 tpd src/interp/category.lisp remove GETREFV
+20111106 tpd src/interp/functor.lisp remove GETREFV
+20111106 tpd src/interp/nruncomp.lisp remove GETREFV
+20111106 tpd src/interp/nrunopt.lisp remove GETREFV
+20111106 tpd src/interp/sys-pkg.lisp remove GETREFV
+20111106 tpd src/interp/template.lisp remove GETREFV
+20111106 tpd src/interp/vmlisp.lisp remove GETREFV
20111106 tpd src/axiom-website/patches.html 20111106.02.tpd.patch
20111106 tpd books/bookvol5 add OpenMath stubs
20111106 tpd src/axiom-website/patches.html 20111106.01.tpd.patch
diff --git a/src/axiom-website/patches.html b/src/axiom-website/patches.html
index d31898f..b6b27e8 100644
--- a/src/axiom-website/patches.html
+++ b/src/axiom-website/patches.html
@@ -3666,5 +3666,9 @@ src/interp/vmlisp.lisp remove makeprop
src/interp/vmlisp.lisp missing/unused function cleanup
20111106.02.tpd.patch
books/bookvol5 add OpenMath stubs
+20111106.03.tpd.patch
+src/interp/vmlisp.lisp remove GETREFV
+20111106.04.tpd.patch
+books/bookvol5 OpenMath support