1 | The routines in this directory provide some simple tests of the MP put |
---|
2 | and get routines. They may also be used as a first example for writing |
---|
3 | MP code. The programs are divded into three sets. |
---|
4 | |
---|
5 | First Set: |
---|
6 | |
---|
7 | gmptest.c - test arbitrary precision integer routines |
---|
8 | |
---|
9 | This program simply tests the use of the arbitrary precision integer |
---|
10 | routines. Respond to the prompts and compare the output with what you |
---|
11 | entered. |
---|
12 | |
---|
13 | |
---|
14 | Second and Third Sets: |
---|
15 | |
---|
16 | The second and third sets of test programs communicate MP data between |
---|
17 | a client (the sender) and a server (the receiver). The data may be |
---|
18 | sent via files or sockets. |
---|
19 | |
---|
20 | See the documention for how to access the TCP and FILE transport |
---|
21 | mechanisms and the additional arguments required. |
---|
22 | |
---|
23 | Second Set: |
---|
24 | |
---|
25 | The client.c and server.c programs use the packet-level routines |
---|
26 | (e.g., MP_PutSint32Packet()), while the imp-client and imp-server |
---|
27 | programs use data level routines (the packets are sent/received |
---|
28 | piecemeal; for example, IMP_PutNodeHeader() followed by |
---|
29 | IMP_PutSint32Type()). See the documentation in doc subdirectory of |
---|
30 | this distribution for further explanation of packet-level versus |
---|
31 | data-level access. |
---|
32 | |
---|
33 | client.c - send MP data using packet-level routines |
---|
34 | imp-client.c - send MP data using data-level routines |
---|
35 | server.c - receive MP data using packet-level routines |
---|
36 | imp-server.c - receive MP data using data-level routines |
---|
37 | |
---|
38 | You may use either of the sample test file (test.ex1 or test.ex2) as |
---|
39 | input. Output produced by the server is sent to the screen and to the |
---|
40 | output file test.out in an ascii format for comparison with the source |
---|
41 | file (e.g., with diff). test.ex2 contains Label and Reference |
---|
42 | annotations not recognized by the code in the second set of test |
---|
43 | programs (see the test programs in the third set below for that). |
---|
44 | |
---|
45 | Note that, on the client side, there is no understanding of what a |
---|
46 | tree "looks like". Specifically, MP_EndMsgReset() is not called until |
---|
47 | after all the source input has been read. Similarly, on the receving |
---|
48 | side, MP_SkipMsg() is called only once, before any MP data is read. |
---|
49 | The code in the third set of examples is more realistic in this |
---|
50 | respect. For this reason, the client-side test routines from the |
---|
51 | second set will only work with the server-side test routines from the |
---|
52 | second set. Similarly for the routines from the third set. |
---|
53 | |
---|
54 | |
---|
55 | Third Set: |
---|
56 | |
---|
57 | send-tree.c - send an MP tree using data-level routines |
---|
58 | recv-tree.c - receive an MP tree using data-level routines. |
---|
59 | |
---|
60 | The client code (send-tree.c) and server code (recv-tree.c) know |
---|
61 | something of MP tree structure. So the client will make a call to |
---|
62 | MP_EndMsgReset() at the end of each tree. Correspondingly, the server |
---|
63 | makes a call to MP_SkipMsg() before receiving each tree. The server |
---|
64 | code (recv-tree.c and node.c) builds the incoming tree in memory |
---|
65 | before printing it out to the file test.out. The server recognizes |
---|
66 | Label and Reference annotations, but expects the Label annotation to |
---|
67 | appear before the Reference annotation. Test this code with file |
---|
68 | test.ex2, but don't expect the test.out to be identical to the input |
---|
69 | since Labels and References are used. |
---|
70 | |
---|
71 | |
---|
72 | Format of the test files: |
---|
73 | |
---|
74 | To make the comparison of the source files and the server's output |
---|
75 | file (test.out), the format of the source file must be precise. There |
---|
76 | must be no trailing blanks and one a single blank space separating |
---|
77 | fields (e.g. type field from number-of-annotations field). |
---|
78 | |
---|
79 | For data nodes the format is: |
---|
80 | |
---|
81 | Type [dictionary] Data-value Number-of-annotations [Number-of-children] |
---|
82 | |
---|
83 | with fields given between brackets ([]) not present for all types. |
---|
84 | See the MP documentation for more information. |
---|
85 | |
---|
86 | For annotation nodes the format is: |
---|
87 | |
---|
88 | Type dictionary Flags |
---|
89 | |
---|
90 | Currently the annotation Type field is a string representing a MP |
---|
91 | defined annotation. The Flags field is given as a hexadecimal number. |
---|
92 | |
---|
93 | The dictionary is identified by it tag number. Values for the common |
---|
94 | types defined in dictionaries (common operator and common constant) |
---|
95 | are specified using their tag number. |
---|