[Avida-cvs] [avida-svn] r886 - development/documentation
brysonda at myxo.css.msu.edu
brysonda at myxo.css.msu.edu
Tue Aug 22 19:43:34 PDT 2006
Author: brysonda
Date: 2006-08-22 22:43:34 -0400 (Tue, 22 Aug 2006)
New Revision: 886
Removed:
development/documentation/devel.html
development/documentation/level_map.html
Modified:
development/documentation/cpu_tour.html
development/documentation/index.html
development/documentation/structure.html
Log:
Update cpu_tour. Remove some incorrect/unnecessary documentation. Begin updating file and directory structure documentation. Also note, I am updating HTML coding so that the documentation is well-formed and standards compliant.
Modified: development/documentation/cpu_tour.html
===================================================================
--- development/documentation/cpu_tour.html 2006-08-22 22:17:55 UTC (rev 885)
+++ development/documentation/cpu_tour.html 2006-08-23 02:43:34 UTC (rev 886)
@@ -1,150 +1,155 @@
<html>
-<title>A guided tour of the an ancestor and its hardware</title>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000AA"
- alink="#0000FF"
- vlink="#000044">
+<head>
+ <title>A guided tour of the an ancestor and its hardware</title>
+</head>
+<body>
-<h2 align=center>A guided tour of an ancestor and its hardware</h2>
+<p><a href="index.html">Return to the Index</a></p>
+<hr />
+<div align="center">
+<h1>A guided tour of an ancestor and its hardware</h1>
+</div>
+
<p>
-This document describes the structure of the virtual CPU and an
+This document describes the structure of the classic virtual CPU and an
example organism running on it.
+</p>
-<h3>The Virtual CPU Structure</h3>
+<h2>The Virtual CPU Structure</h2>
<p>
The virtual CPU, which is the default "body" or "hardware" of the organisms,
contains the following set of components, (as further illustrated in the
figure below).
+</p>
-<menu>
-<li>A <font color="#006666"><b><i>memory</i></b></font> that consists of a sequence
+<ul>
+<li>A <strong style="color: #006666">memory</strong> that consists of a sequence
of instructions, each associated with a set of flags to denote if the
- instruction has been executed, copied, mutated, etc.
-<li>An <font color="#880088"><b><i>instruction pointer</i></b></font> (IP) that
- indicates the next site in the memory to be executed.
-<li>Three <font color="#FF8888"><b><i>registers</i></b></a></font> that can be used
+ instruction has been executed, copied, mutated, etc.</li>
+<li>An <strong style="color: #880088">instruction pointer</strong> (IP) that
+ indicates the next site in the memory to be executed.</li>
+<li>Three <strong style="color: #FF8888">registers</strong> that can be used
by the organism to hold data currently being manipulated. These are often
operated upon by the various instructions, and can contain arbitrary
- 32-bit integers.
-<li>Two <font color="#008800"><b><i>stacks</i></b></font> that are used for storage.
+ 32-bit integers.</li>
+<li>Two <strong style="color: #008800">stacks</strong> that are used for storage.
The organism can theoretical store an arbitrary amount of data in the
stacks, but for practical purposes we currently limit the maximum stack
- depth to ten.
-<li>An <font color="#CCCC00"><b><i>input buffer</i></b></font> and an
- <font color="#CCCC00"><b><i>output buffer</i></b> </font>that the organism
- uses to receive information, and return the processed results.
-<li>A <font color="#8888FF"><b><i>Read-Head</i></b></font>, a
- <font color="#8888FF"><b><i>Write-Head</i></b></font>, and a
- <font color="#8888FF"><b><i>Flow-Head</i></b></font> which are used to
+ depth to ten.</li>
+<li>An <strong style="color: #CCCC00">input buffer</strong> and an
+ <strong style="color: #CCCC00">output buffer</strong>that the organism
+ uses to receive information, and return the processed results.</li>
+<li>A <strong style="color: #8888FF">Read-Head</strong>, a
+ <strong style="color: #8888FF">Write-Head</strong>, and a
+ <strong style="color: #8888FF">Flow-Head</strong> which are used to
specify positions in the CPU's memory. A copy command reads from the
Read-Head and writes to the Write-Head. Jump-type statements move the IP
- to the Flow-Head.
-</menu>
+ to the Flow-Head.</li>
+</ul>
-<p>
-<center>
-<img align=center src="cpu2.gif">
-</center>
+<div align="center">
+<img src="cpu2.gif" />
+</div>
-<br><br><br><br><br>
-<h3>Instruction set design</h3>
+<p> </p>
+<h2>Instruction Set Configuration</h2>
+
<p>
The instruction set in Avida is loaded on startup from a configuration file
-specified in the <tt>genesis</tt> file. This allows selection of different
-instruction sets without recompiling the source code, as well as allowing different sized
-instruction sets to be specified. It is not possible to alter the behavior
+specified in the <kbd>avida.cfg</kbd> file. This allows selection of different
+instruction sets without recompiling the source code, as well as allowing different
+sized instruction sets to be specified. It is not possible to alter the behavior
of individual instructions or add new instructions without recompiling Avida;
such activities have to be done directly in the source code.
<p>
-The available instructions are listed in the <tt>inst_set.*</tt> files with
-a <tt>1</tt> or a <tt>0</tt> next to an instruction to indicate if it
+The available instructions are listed in the <kbd>inst_set.*</kbd> files with
+a <code>1</code> or a <code>0</code> next to an instruction to indicate if it
should or should not be included. Changing the instruction set to be used
simply involves adjusting these flags.
<p>
The instructions were created with three things in mind:
-<menu>
-<li>To be as complete as possible (both in a "Turing complete" sense -- that
- is, it can compute any computable function -- and, more practically, to
- ensure that simple operations only require a few instructions).
+<ul>
+<li>
+To be as complete as possible (both in a "Turing complete" sense -- that
+is, it can compute any computable function -- and, more practically, to ensure that
+simple operations only require a few instructions).
+</li>
+<li>
+For each instruction to be as robust and versatile as possible; all instructions
+should take an "appropriate" action in any situation where they can be
+executed.
+</li>
+<li>
+To have as little redundancy as possible between instructions. (Several instructions
+have been implemented that are redundant, but such combinations will typically not
+be turned on simultaneously for a run.)
+</li>
+</ul>
-<li>For each instruction to be as robust and versatile as possible; all
- instructions should take an "appropriate" action in any situation
- where they can be executed.
-
-<li>To have as little redundancy as possible between instructions.
- (Several instructions have been implemented that are redundant, but such
- combinations will typically not be turned on simultaneously for a run.)
-</menu>
-
<p>
One major concept that differentiates this virtual assembly language from its
-real-world counterparts is in the additional uses of <tt>nop</tt> instructions
+real-world counterparts is in the additional uses of <code>nop</code> instructions
(no-operation commands).
These have no direct effect on the virtual CPU when executed, but often
modify the effect of any instruction that precedes them. In a sense, you
can think of them as purely regulatory genes. The default instruction set
-has three such <tt>nop</tt> instructions: <tt>nop-A</tt>, <tt>nop-B</tt>,
-and <tt>nop-C</tt>.
-
+has three such <code>nop</code> instructions: <code>nop-A</code>, <code>nop-B</code>,
+and <code>nop-C</code>.
+</p>
<p>
The remaining instructions can be seperated into three classes. The first
class is those few instructions that are unaffected by nops. Most of these
-are the "biological" instructions involved directly in the replication
-process. The second class of instructions is those for which a <tt>nop</tt>
+are the "biological" instructions involved directly in the replication
+process. The second class of instructions is those for which a <code>nop</code>
changes the head or register affected by the previous command. For example,
-an <tt>inc</tt> command followed by the instruction <tt>nop-A</tt> would
-cause the contents of the <tt>AX</tt> register to be incremented, while an
-<tt>inc</tt> command followed by a <tt>nop-B</tt> would increment <tt>BX</tt>.
-
+an <code>inc</code> command followed by the instruction <code>nop-A</code> would
+cause the contents of the <code>AX</code> register to be incremented, while an
+<tt>inc</tt> command followed by a <tt>nop-B</tt> would increment <code>BX</code>.
+</p>
<p>
The notation we use in instruction definitions to describe that a default
component (that is, a register or head) can be replaced due to a nop command
-is by surrounding name with <tt>?</tt>'s. The component list is the
-default one to be used, but if a <tt>nop</tt> follows the command, the
+is by surrounding the component name with <code>?</code>'s. The component listed is the
+default one to be used, but if a <code>nop</code> follows the command, the
component it represents in this context will replace this default.
-If the component between the question
-marks is a register than a subsequent <tt>nop-A</tt>
-represents the <tt>AX</tt> register, <tt>nop-B</tt> is <tt>BX</tt>, and
-<tt>nop-C</tt> is <tt>CX</tt>. If the component listed is a head
-(including the instruction pointer) then a <tt>nop-A</tt> represents the
-Instruction Pointer, <tt>nop-B</tt> represents the Read-Head, and
-<tt>nop-C</tt> is the Write-Head. Currently
-the Flow-Head has no <tt>nop</tt> associated with it.
-
+If the component between the question marks is a register than a
+subsequent <code>nop-A</code> represents the <code>AX</code> register,
+<code>nop-B</code> is <code>BX</code>, and <code>nop-C</code> is <code>CX</code>.
+If the component listed is a head (including the instruction pointer) then a
+<code>nop-A</code> represents the Instruction Pointer, <code>nop-B</code> represents
+the Read-Head, and <code>nop-C</code> is the Write-Head. Currently
+the Flow-Head has no <code>nop</code> associated with it.
+</p>
<p>
The third class of instructions are those that use a series of <tt>nop</tt>
instructions as a template (label) for a command that needs to reference
another position in the code, such as
-<tt>h-search</tt>. If <tt>nop-A</tt> follows a search command, it scans for
-the first complementary template (<tt>nop-B</tt>) and moves the Flow-Head
-there. Templates may be composed of more than a single <tt>nop</tt>
+<code>h-search</code>. If <code>nop-A</code> follows a search command, it scans for
+the first complementary template (<code>nop-B</code>) and moves the Flow-Head
+there. Templates may be composed of more than a single <code>nop</code>
instruction. A series of nops is typically abbreviated to the associated
-letter and separated by colons. This the sequence "<tt>nop-A nop-A nop-C</tt>"
-would be displayed as "<tt>A:A:C</tt>".
-
+lecodeer and separated by colons. This the sequence "<code>nop-A nop-A nop-C</code>"
+would be displayed as "<code>A:A:C</code>".
+</p>
<p>
The label system used in Avida allows for an arbitrary number of nops. By
-default, we have three: <tt>nop-A</tt>'s complement is <tt>nop-B</tt>,
-<tt>nop-B</tt>'s is <tt>nop-C</tt>, and <tt>nop-C</tt>'s is <tt>nop-A</tt>.
+default, we have three: <code>nop-A</code>'s complement is <code>nop-B</code>,
+<code>nop-B</code>'s is <code>nop-C</code>, and <code>nop-C</code>'s is <code>nop-A</code>.
Likewise, some instructions talk about the complement of a register or head
--- the same pattern is used in those cases. So if an instruction tests if
-<tt>?BX?</tt> is equal to its complement, it will test if
-<tt>BX == CX</tt> by default, but if it is followed by a
-<tt>nop-C</tt> it will test if <tt>CX == AX</tt>.
+-- the same pacodeern is used in those cases. So if an instruction tests if
+<code>?BX?</code> is equal to its complement, it will test if
+<code>BX == CX</code> by default, but if it is followed by a
+<code>nop-C</code> it will test if <code>CX == AX</code>.
+</p>
-<p>
-I've often considered to moving to four <tt>nop</tt> instructions by default;
-A, C, G, and T with the expected complements.
-<h3>Instruction Set Reference</h3>
+<h2>Instruction Set Reference</h2>
<p>
The full instruction set description is included
@@ -153,68 +158,69 @@
<p>
<table>
-<tr><th valign=top>(a-c) <td><tt>nop-A</tt>, <tt>nop-B</tt>, <br> and <tt>nop-C</tt>
+<tr><th valign=top>(a-c) <td><code>nop-A</code>, <code>nop-B</code>, <br> and <code>nop-C</code>
<td valign=top>No-operation instructions; these modify other instructions.</tr>
-<tr><th>(d) <td><tt>if-n-equ</tt>
+<tr><th>(d) <td><code>if-n-equ</code>
<td>Execute next instruction only-if ?BX? does not equal its complement</tr>
-<tr><th>(e) <td><tt>if-less</tt>
+<tr><th>(e) <td><code>if-less</code>
<td>Execute next instruction only if ?BX? is less than its complement</tr>
-<tr><th>(f) <td><tt>pop</tt>
+<tr><th>(f) <td><code>pop</code>
<td>Remove a number from the current stack and place it in ?BX?</tr>
-<tr><th>(g) <td><tt>push</tt>
+<tr><th>(g) <td><code>push</code>
<td>Copy the value of ?BX? onto the top of the current stack</tr>
-<tr><th>(h) <td><tt>swap-stk</tt>
+<tr><th>(h) <td><code>swap-stk</code>
<td>Toggle the active stack</tr>
-<tr><th>(i) <td><tt>swap</tt>
+<tr><th>(i) <td><code>swap</code>
<td>Swap the contents of ?BX? with its complement.</tr>
-<tr><th>(j) <td><tt>shift-r</tt>
+<tr><th>(j) <td><code>shift-r</code>
<td>Shift all the bits in ?BX? one to the right</tr>
-<tr><th>(k) <td><tt>shift-l</tt>
+<tr><th>(k) <td><code>shift-l</code>
<td>Shift all the bits in ?BX? one to the left</tr>
-<tr><th>(l) <td><tt>inc</tt>
+<tr><th>(l) <td><code>inc</code>
<td>Increment ?BX?</tr>
-<tr><th>(m) <td><tt>dec</tt>
+<tr><th>(m) <td><code>dec</code>
<td>Decrement ?BX?</tr>
-<tr><th>(n) <td><tt>add</tt>
+<tr><th>(n) <td><code>add</code>
<td>Calculate the sum of BX and CX; put the result in ?BX?</tr>
-<tr><th>(o) <td><tt>sub</tt>
+<tr><th>(o) <td><code>sub</code>
<td>Calculate the BX minus CX; put the result in ?BX?</tr>
-<tr><th>(p) <td><tt>nand</tt>
+<tr><th>(p) <td><code>nand</code>
<td>Perform a bitwise NAND on BX and CX; put the result in ?BX?</tr>
-<tr><th>(q) <td><tt>IO</tt>
+<tr><th>(q) <td><code>IO</code>
<td>Output the value ?BX? and replace it with a new input</tr>
-<tr><th>(r) <td><tt>h-alloc</tt>
+<tr><th>(r) <td><code>h-alloc</code>
<td>Allocate memory for an offspring</tr>
-<tr><th>(s) <td><tt>h-divide</tt>
+<tr><th>(s) <td><code>h-divide</code>
<td>Divide off an offspring located between the Read-Head and Write-Head.</tr>
-<tr><th>(t) <td><tt>h-copy</tt>
+<tr><th>(t) <td><code>h-copy</code>
<td>Copy an instruction from the Read-Head to the Write-Head and advance both.</tr>
-<tr><th>(u) <td><tt>h-search</tt>
+<tr><th>(u) <td><code>h-search</code>
<td>Find a complement template and place the Flow-Head after it.</tr>
-<tr><th>(v) <td><tt>mov-head</tt>
+<tr><th>(v) <td><code>mov-head</code>
<td>Move the ?IP? to the same position as the Flow-Head</tr>
-<tr><th>(w) <td><tt>jmp-head</tt>
+<tr><th>(w) <td><code>jmp-head</code>
<td>Move the ?IP? by a fixed amount found in CX</tr>
-<tr><th>(x) <td><tt>get-head</tt>
+<tr><th>(x) <td><code>get-head</code>
<td>Write the position of the ?IP? into CX</tr>
-<tr><th>(y) <td><tt>if-label</tt>
+<tr><th>(y) <td><code>if-label</code>
<td>Execute the next instruction only if the given template complement was just copied</tr>
-<tr><th>(z) <td><tt>set-flow</tt>
+<tr><th>(z) <td><code>set-flow</code>
<td>Move the Flow-Head to the memory position specified by ?CX?</tr>
</table>
-<h3>An example Ancestor</h3>
-The following organism is stored in the file <tt>organism.heads.15</tt>,
-which you should find in the source/support/config/ directory. This is a
-simplified version of <tt>organism.default</tt> and
-<tt>organism.heads.100</tt>, of lengths 50 and 100 respectively (each has
+<h3>An Example Ancestor</h3>
+
+The following organism is stored in the file <kbd>organism.heads.15</kbd>,
+which you should find in the <kbd>support/config/misc/</kbd> directory. This is a
+simplified version of <kbd>organism.default</kbd> and
+<kbd>organism.heads.100</kbd>, of lengths 50 and 100 respectively (each has
additional instructions placed before the copy loop)
<p>
<table>
<tr><td colspan=2><font color="#886600"># --- Setup ---</font><br>
-<tr><td><b><tt>h-alloc</tt></b> <td><font color="#886600"># Allocate extra space at the end of the genome to copy the offspring into.</font><br>
+<tr><td><b><code>h-alloc</code></b> <td><font color="#886600"># Allocate extra space at the end of the genome to copy the offspring into.</font><br>
<tr><td><b><tt>h-search </tt></b> <td><font color="#886600"># Locate an
<tt>A:B</tt> template (at the end of the organism) and
place the Flow-Head after it</font><br>
@@ -229,22 +235,21 @@
<tr><td>
<tr><td colspan=2><font color="#886600"># --- Copy Loop ---</font><br>
<tr><td><b><tt>h-search</tt></b> <td><font color="#886600"># No template,
- so place the Flow-Head on the next line (to mark the beginning of the copy
- loop)</font><br>
-<tr><td><b><tt>h-copy</tt></b> <td><font color="#886600"># Copy a single
+ so place the Flow-Head on the next line code</font><br>
+<tr><td><b><code>h-copy</code></b> <td><font color="#886600"># Copy a single
instruction from the read head to the write head (and advance both
heads!)</font><br>
-<tr><td><b><tt>if-label</tt></b> <td><font color="#886600"># Execute the
+<tr><td><b><code>if-label</code></b> <td><font color="#886600"># Execute the
line following this template <i>only if</i> we have just copied an
- <tt>A:B</tt> template.</font><br>
-<tr><td><b><tt>nop-C</tt></b> <td><font color="#886600">#</font><br>
-<tr><td><b><tt>nop-A</tt></b> <td><font color="#886600">#</font><br>
-<tr><td><b><tt>h-divide</tt></b> <td><font color="#886600"># ...Divide off offspring! (note if-statement above!)</font><br>
-<tr><td><b><tt>mov-head</tt></b> <td><font color="#886600"># Otherwise,
+ <code>A:B</code> template.</font><br>
+<tr><td><b><code>nop-C</code></b> <td><font color="#886600">#</font><br>
+<tr><td><b><code>nop-A</code></b> <td><font color="#886600">#</font><br>
+<tr><td><b><code>h-divide</code></b> <td><font color="#886600"># ...Divide off offspring! (note if-statement above!)</font><br>
+<tr><td><b><code>mov-head</code></b> <td><font color="#886600"># Otherwise,
move the IP back to the Flow-Head at the beginning of the copy
loop.</font><br>
-<tr><td><b><tt>nop-A</tt></b> <td><font color="#886600"># End label.</font><br>
-<tr><td><b><tt>nop-B</tt></b> <td><font color="#886600"># End label.</font><br>
+<tr><td><b><code>nop-A</code></b> <td><font color="#886600"># End label.</font><br>
+<tr><td><b><code>nop-B</code></b> <td><font color="#886600"># End label.</font><br>
</table>
<p>
@@ -254,53 +259,55 @@
of its genome (where this new space was just placed) so that it will know
where to start copying. First the Flow-Head is placed there, and then the
Write-Head is moved to the same point.
-
+</p>
<p>
It is after this initial setup and before the actual copying process
-commences that extra <tt>nop</tt> instructions can be included. The only
+commences that extra <code>nop</code> instructions can be included. The only
caveat is that you need to make sure that you don't duplicate any templates
that the program will be searching for, or else it will no longer function
-properly. The easiest thing to do is insert a long sequence of <tt>nop-C</tt>
+properly. The easiest thing to do is insert a long sequence of <code>nop-C</code>
instructions.
-
+</p>
<p>
Next we have the beginning of the "copy loop". This segement of code starts
-off with an <tt>h-search</tt> command with no template following it. In
+off with an <code>h-search</code> command with no template following it. In
such as case, the Flow-Head is placed on the line immediately following the
search. This head will be used to designate the place that the IP keeps
returning to with each cycle of the loop.
-
+</p>
<p>
-The <tt>h-copy</tt> command will copy a single instruction from the Read-Head
+The <code>h-copy</code> command will copy a single instruction from the Read-Head
(still at the very start of the genome, where it begins) to the Write-Head
(which we placed at the beginning of the offspring). With any copy command
there is a user-specified chance of a copy mutation. If one occurs, the
Write-Head will place a random instruction rather than the one that it
-gathered from the Read-Head. After the copy occurs (for better or worse),
+gathered from the Read-Head. After the copy occurs (for becodeer or worse),
both the Read-Head and the Write-Head are advanced to the next instruction
in the genome. It is for this reason that a common mutation we see happening
will place a long string of h-copy instruction one after another.
-
+</p>
<p>
-The next command, <tt>if-label</tt> (followed by a <tt>nop-C</tt> and a
-<tt>nop-A</tt>) tests to see if the complement of <tt>C:A</tt> is the most
+The next command, <code>if-label</code> (followed by a <code>nop-C</code> and a
+<code>nop-A</code>) tests to see if the complement of <code>C:A</code> is the most
thing copied. That is, if the two most
-recent instructions copied were a <tt>nop-A</tt> followed by a <tt>nop-B</tt>
+recent instructions copied were a <code>nop-A</code> followed by a <code>nop-B</code>
as is found at the end of the organism. If so, we are done! Execute the
-next instruction which is <tt>h-divide</tt> (when this occurs, the read and
+next instruction which is <code>h-divide</code> (when this occurs, the read and
write heads will surround the portion of memory to be split off as the
offspring's genome). If not, then we need to keep
-going. Skip the next instruction and move on to the <tt>mov-head</tt> which
-will move the head specified by the <tt>nop</tt> that follows (in this case
-<tt>nop-A</tt> which is the Instruction Pointer) to the Flow-Head at the
+going. Skip the next instruction and move on to the <code>mov-head</code> which
+will move the head specified by the <code>nop</code> that follows (in this case
+<code>nop-A</code> which is the Instruction Pointer) to the Flow-Head at the
beginning of the copy loop.
-
+</p>
<p>
This process will continue until all of the lines of code have been copies,
and an offspring is born.
+</p>
-<h3>An example logic gene</h3>
+<h3>An Example Logic Gene</h3>
+
<p>
Here is a short example program to demonstrate one way for an organism to
perform the "OR" logic operation. This time I'm only going to show the
@@ -357,7 +364,9 @@
<td bgcolor="#AAFFAA">? <td bgcolor="#FFFF88"> X or Y
</table>
</center>
-<br><hr>
-Project hosted by:<br>
-<a href="http://sourceforge.net"><img src="http://sourceforge.net/sflogo.php?group_id=46761&type=2" width="125" height="37" border="0" alt="SourceForge.net"/></a>
-
\ No newline at end of file
+
+<hr />
+<p><a href="index.html">Return to the Index</a></p>
+
+</body>
+</html>
Deleted: development/documentation/devel.html
===================================================================
--- development/documentation/devel.html 2006-08-22 22:17:55 UTC (rev 885)
+++ development/documentation/devel.html 2006-08-23 02:43:34 UTC (rev 886)
@@ -1,123 +0,0 @@
-<html>
-<title>Retrieving and compiling the <i>Developmental Version</i> of Avida</title>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000AA"
- alink="#0000FF"
- vlink="#000044">
-
-<h2 align=center>Retrieving and compiling the <i>Developmental Version</i> of Avida</h2>
-
-<p>
-This document will get you up and running with the developmental version of
-avida. Please make sure that you have setup the <a href="cvs.html">CVS</a>
-in your account before starting. The process of setting up avida out of the
-CVS is slightly more complicated than retrieving it as a package, but
-will give you access to the most recent features and changes.
-
-<p>
-To begin, create a new sub-directory to place the avida source code in, and
-enter that sub-directory. Do this directly off of your home directory,
-you could type:
-
-<p>
- <tt>cd ~</tt><br>
- <tt>mkdir avida</tt><br>
- <tt>cd avida</tt><br>
-
-<p>
-Now that we have the place to put avida, we need to download it from the
-CVS. We have many different versions in the cvs, but you only want the most
-current version, which we have labeled "current".
-
-<p>
- <tt>cvs get current</tt><br>
-
-<p>
-If you are downloading from a SourceForge account, it will ask you for your
-password. You will then see a stream of filenames fly by you on the screen as
-it downloads them one at a time. When it is finished, you want to enter the
-directory it has created, and perhaps look at the files available:
-
-<p>
- <tt>cd current</tt><br>
- <tt>ls -sF</tt><br>
-
-<p>
-You may notice that there are both a bunch of files and a few sub-directories.
-The CVS/ sub-directory is where the cvs keeps all of its information about
-what's up to date. The source/ sub-directory is where the source code is,
-and work/ is where you will be doing your runs. Most importantly, the
-doc/ sub-directory contains lots of documentations for doing Avida runs.
-
-<p>
-Your next step is to tell avida that it has just been taken out of the CVS,
-and that it should unpack any special files related to this. The program
-called "make" is used to execute a series of commands related to compiling
-source code. Normally it looks at the file "Makefile" for instructions, but
-this time we tell it to use the special file "Makefile.cvs" that tells it
-what to do when its removed from the CVS. The file Makefile.cvs is not
-included when we package avida up for other people to use.
-
-<p>
- <tt>make -f Makefile.cvs</tt><br>
-
-<p>
-This should have run quickly. Now that we have avida setup as it would
-be were we installing it from a package, we can use the normal utilities.
-First, you want to configure it for your machine. Do this by typing:
-
-<p>
- <tt>./configure --enable-viewer</tt><br>
-
-<p>
-If you don't care about compiling the ncurses (text) viewer, you can just
-type "./configure" by itself. The flags allow us to tell configure what it
-should and shouldn't setup to be compiled. For example, if we wanted to
-compile avida with the special debug modules turned on, we could also include
-"--enable-debug". For the moment, we're not going to worry about
-the graphical viewer (--enable-qt-viewer) since its not quite ready yet, and
-you would need to install extra packages on your machine. See the document
-on the <a href="qt-viewer.html">qt-viewer</a> for more information on that.
-
-<p>
-When we're done with the configuration, we finally compile to source code!
-
-<p>
- <tt>make</tt><br>
-
-<p>
-This will take a while; depending on the speed of the machine, it should
-be about 5 minutes. When it finally finishes, you should type:
-
-<p>
- <tt>make install</tt><br>
-
-<p>
-This will "install" all of the avida configuration files into the work
-directory, so you can do everything you need to right there. If you change
-a file in the work directory, CVS will *not* modify it on you then next time
-you do an update (nor will it assume that you want to commit the changes).
-If, as a developer, you do want to make permanent changes to everyone's
-configuration files, you need to do this in the source/support/ sub-directory.
-
-<p>
-And with that, we're done!
-
-<p>
-Try it out. Go into the work directory, and run avida:
-
-<p>
- <tt>cd work</tt><br>
- <tt>viewer</tt><br>
-
-<p>
-The viewer has problems showing up properly on some systems, if it doesn't
-work for you, you can always just run avida in "primitive" move by typing
-"<tt>primitive</tt>" instead of "<tt>viewer</tt>".
-
-<br><hr>
-Project hosted by:<br>
-<a href="http://sourceforge.net"><img src="http://sourceforge.net/sflogo.php?group_id=46761&type=2" width="125" height="37" border="0" alt="SourceForge.net"/></a>
-
\ No newline at end of file
Modified: development/documentation/index.html
===================================================================
--- development/documentation/index.html 2006-08-22 22:17:55 UTC (rev 885)
+++ development/documentation/index.html 2006-08-23 02:43:34 UTC (rev 886)
@@ -13,42 +13,45 @@
<h2>General Information</h2>
<p>
-<a href="cpu_tour.html">A Guided Tour of an Avida Ancestor and its Hardware</a><br>
-<a href="devel.html">Retriving the Developmental Version of Avida</a><br>
-<a href="structure.html">The Directory and File Structure of Avida</a><br>
-<a href="level_map.html">A levelization Map of the Avida Source Code</a><br>
-<a href="svn.html">Using Subversion to Obtain Avida</a><br>
+<a href="cpu_tour.html">A Guided Tour of an Avida Ancestor and its Hardware</a>
+<br /><a href="structure.html">The Directory and File Structure of Avida</a>
+<br /><a href="svn.html">Using Subversion to Obtain Avida</a>
+</p>
<h2>Configuration Files</h2>
<p>
-<a href="genesis.html">Setting up the Genesis File</a><br>
-<a href="inst_set.html">Setting up the Instruction Set</a><br>
-<a href="events.html">Guidelines to setting Events</a><br>
-<a href="environment.html">Guidelines to setting up Environments</a><br>
-<a href="analyze_mode.html">Guidelines to Analyze Mode</a><br>
-<a href="analyze_samples.html">Sample Analyze Programs</a><br>
+<a href="genesis.html">Setting up the Genesis File</a>
+<br /><a href="inst_set.html">Setting up the Instruction Set</a>
+<br /><a href="events.html">Guidelines to setting Events</a>
+<br /><a href="environment.html">Guidelines to setting up Environments</a>
+<br /><a href="analyze_mode.html">Guidelines to Analyze Mode</a>
+<br /><a href="analyze_samples.html">Sample Analyze Programs</a>
+</p>
+
<h2>Guides to Modifying the Avida Source Code</h2>
<p>
-<a href="code_c++_intro.html">Introduction to C++ Coding in Avida</a><br>
-<a href="code_death_birth.html">Guide to the Death/Birth Cycle</a><br>
-<a href="code_init_file.html">Guide to Initialization Files</a><br>
-<a href="code_life_cycle.html">Guide to an Avidan Life Cycle</a><br>
-
+<a href="code_c++_intro.html">Introduction to C++ Coding in Avida</a>
+<br /><a href="code_death_birth.html">Guide to the Death/Birth Cycle</a>
+<br /><a href="code_init_file.html">Guide to Initialization Files</a>
+<br /><a href="code_life_cycle.html">Guide to an Avidan Life Cycle</a>
+</p>
<p>
-<a href="code_genesis.html">Implementing New Genesis Settings</a><br>
-<a href="code_events.html">Implementing New Events</a><br>
-<a href="code_instruction.html">Implementing New Instructions</a><br>
-<a href="code_environment.html">The Environment Source Code</a><br>
+<a href="code_genesis.html">Implementing New Genesis Settings</a>
+<br /><a href="code_events.html">Implementing New Events</a>
+<br /><a href="code_instruction.html">Implementing New Instructions</a>
+<br /><a href="code_environment.html">The Environment Source Code</a>
+</p>
<h2>Other Tools</h2>
<p>
-<a href="screen.html">The "screen" Virtual Terminal</a><br>
+<a href="screen.html">The "screen" Virtual Terminal</a>
+</p>
</body>
</html>
Deleted: development/documentation/level_map.html
===================================================================
--- development/documentation/level_map.html 2006-08-22 22:17:55 UTC (rev 885)
+++ development/documentation/level_map.html 2006-08-23 02:43:34 UTC (rev 886)
@@ -1,117 +0,0 @@
-<html>
-<title>An Avida Levelization Map</title>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000AA"
- alink="#0000FF"
- vlink="#000044">
-
-<h2 align=center>An Avida Levelization Map</h2>
-
-<p>
-Levelization is an important tool for large software projects, though
-few seem to use it. The concept is that all components in the project should
-be part of a well defined hierarchy. In C++, a component is defined as a
-pair of files, one of which is a header (ending in .hh) and the other is a
-code file (ending in .cc).
-
-<p>
-So what do I mean about hierarchy? Basically, for any two components A
-and B, if B requires A in to successfully compile, than A should not
-also require B. Thus, A is a "lower level" component than B.
-To illustrate this in avida, we can use the example of the "genome" and
-"organism" components. The cOrganism class requires the cGenome class to
-be compiled, so we need make sure that the reverse is not true.
-For those of you who are familiar with graph theory, a project being
-levelized simply means that the project's components and their dependencies
-form a directed, acyclic graph (DAG).
-
-<p>
-This is not always as easy as it sounds. For example, when I decided to
-levelize the Avida source code, my biggest challenge was with the pair of
-classes cOrganism and cPopulation. The population has a collection of
-organisms inside of it, so obviously it needs to know about them.
-Unfortunately, the organism <i>also</i> needs to interact with the
-population, for example to let it know when it is ready to have its child be
-born. To solve this problem,
-I created the cPopulationInterface class. This class, is at a lover level
-than either population or organism, so they both have access to it.
-The object of class cPopulation (or of class cTestCPU, for when we need to
-test an organism) will give the population interface pointers to the
-functions that
-should be executed under specific conditions, and then the organism will
-use those function pointers as needed. Don't worry too much about this now;
-this example is merely intended to illustrate that levelization is not
-always easy, but its also not impossible.
-
-<p>
-The term "levelization" refers to the levels in the hierarchy. All of those
-components that don't have any dependencies are on level 0. Those that only
-depend on components in level zero are themselves at level one, and so on.
-
-<h3>Levelization Chart</h3>
-
-Below are a listing of all of the files in the
-<tt><font color="#008844">main/</font></tt> and
-<tt><font color="#008844">cpu/</font></tt> directories. Files in
-<tt><font color="#008844">tools/</font></tt> are not listed because they
-are internally levelized, and do not depend on any other avida files outside
-of that directory. Conversely, no files in these directories depend on
-anything in either of the viewer directories, so they are not listed either.
-Files in the <tt><font color="#008844">events/</font></tt> directory are
-auto-generated and not being discussed at this point. So, basically, these
-are only those files that are at the core of avida.
-
-
-<p>
-<table>
-<tr><td><b>Level</b> <td><b>Component</b> <td><b>Dependencies</b>
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">config</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">cpu/</font><font color="#000088">cpu_stats</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">cpu/</font><font color="#000088">cpu_stack</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">inst</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">cpu/</font><font color="#000088">label</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">mutations</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">pop_interface</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">reaction</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">reaction_result</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">resource</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">resource_count</font></tt> <td>[none]
-<tr><th>0 <td><tt><font color="#008844">main/</font><font color="#000088">tasks</font></tt> <td>[none]
-<tr><th>1 <td><tt><font color="#008844">main/</font><font color="#000088">genome</font></tt> <td>inst
-<tr><th>1 <td><tt><font color="#008844">main/</font><font color="#000088">inst_lib</font></tt> <td>inst
-<tr><th>1 <td><tt><font color="#008844">main/</font><font color="#000088">stats</font></tt> <td>config
-<tr><th>2 <td><tt><font color="#008844">main/</font><font color="#000088">environment</font></tt> <td>reaction, resource, tasks, inst_lib, mutations, reaction_result
-<tr><th>2 <td><tt><font color="#008844">cpu/</font><font color="#000088">cpu_memory</font></tt> <td>genome
-<tr><th>2 <td><tt><font color="#008844">main/</font><font color="#000088">genome_util</font></tt> <td>genome
-<tr><th>2 <td><tt><font color="#008844">cpu/</font><font color="#000088">hardware_base</font></tt> <td>inst, inst_lib
-<tr><th>2 <td><tt><font color="#008844">main/</font><font color="#000088">inst_util</font></tt> <td>inst_lib, genome
-<tr><th>3 <td><tt><font color="#008844">main/</font><font color="#000088">phenotype</font></tt> <td>environment, config
-<tr><th>3 <td><tt><font color="#008844">cpu/</font><font color="#000088">head</font></tt> <td>inst, inst_lib, hardware_base, cpu_memory, label
-<tr><th>4 <td><tt><font color="#008844">main/</font><font color="#000088">organism</font></tt> <td>mutations, pop_interface, cpu_stats, phenotype, config, inst_lib, inst_util, genome, genome_util, hardware_base
-<tr><th>5 <td><tt><font color="#008844">main/</font><font color="#000088">population_cell</font></tt> <td>mutations, organism
-<tr><th>5 <td><tt><font color="#008844">cpu/</font><font color="#000088">test_cpu</font></tt> <td>config, hardware_base, inst_lib, inst_util, organism, phenotype, pop_interface, resource_count, tasks
-<tr><th>6 <td><tt><font color="#008844">main/</font><font color="#000088">fitness_matrix</font></tt> <td>stats, organism, test_cpu, config, inst_lib
-<tr><th>6 <td><tt><font color="#008844">main/</font><font color="#000088">genotype</font></tt> <td>genome, config, genome_util, organism, phenotype, stats, test_cpu
-<tr><th>6 <td><tt><font color="#008844">cpu/</font><font color="#000088">hardware_cpu</font></tt> <td>cpu_memory, cpu_stack, label, head, config, inst_lib, genome_util, organism, phenotype, test_cpu
-<tr><th>7 <td><tt><font color="#008844">cpu/</font><font color="#000088">hardware_factory</font></tt> <td>hardware_base, hardware_cpu
-<tr><th>7 <td><tt><font color="#008844">cpu/</font><font color="#000088">hardware_util</font></tt> <td>inst_lib, inst_util, hardware_base, hardware_cpu
-<tr><th>7 <td><tt><font color="#008844">main/</font><font color="#000088">species</font></tt> <td>genome, stats, genotype, genome_util, test_cpu
-<tr><th>7 <td><tt><font color="#008844">cpu/</font><font color="#000088">test_util</font></tt> <td>genome, genotype, inst_util, organism, phenotype, stats, hardware_base, test_cpu
-<tr><th>8 <td><tt><font color="#008844">main/</font><font color="#000088">genebank</font></tt> <td>species, genotype, config, stats, test_util
-<tr><th>8 <td><tt><font color="#008844">main/</font><font color="#000088">landscape</font></tt> <td>genome, test_cpu, cpu_memory, stats, inst_lib, organism, phenotype, test_util
-
-<tr><th>9 <td><tt><font color="#008844">main/</font><font color="#000088">analyze</font></tt> <td>genome, config, species, fitness_matrix, inst_lib, inst_util, landscape, phenotype, genome_util, test_cpu, hardware_util, test_util, environment
-<tr><th>10 <td><tt><font color="#008844">main/</font><font color="#000088">population</font></tt> <td>resource_count, inst_lib, pop_interface, mutations, config, genebank, genome_util, genotype, hardware_base, hardware_factory, hardware_util, inst_util, organism, phenotype, population_cell, species, stats, tasks
-<tr><th>11 <td><tt><font color="#008844">main/</font><font color="#000088">analyze_util</font></tt> <td>config, genebank, genome, genome_util, genotype, inst_lib, inst_util, landscape, organism, phenotype, population, population_cell, species, stats, test_cpu, test_util
-<tr><th>11 <td><tt><font color="#008844">main/</font><font color="#000088">callback_util</font></tt> <td>avida, genotype, organism, population, population_cell, pop_interface, hardware_base, hardware_factory, test_cpu
-<tr><th>12 <td><tt><font color="#008844">main/</font><font color="#000088">avida</font></tt> <td>stats, environment genotype, genebank, analyze, config, species, genome_util, test_cpu, callback_util, population, {events}, {viewers}
-</table>
-
-
-
-<br><hr>
-Project hosted by:<br>
-<a href="http://sourceforge.net"><img src="http://sourceforge.net/sflogo.php?group_id=46761&type=2" width="125" height="37" border="0" alt="SourceForge.net"/></a>
-
\ No newline at end of file
Modified: development/documentation/structure.html
===================================================================
--- development/documentation/structure.html 2006-08-22 22:17:55 UTC (rev 885)
+++ development/documentation/structure.html 2006-08-23 02:43:34 UTC (rev 886)
@@ -1,26 +1,34 @@
<html>
-<title>Directory and File Structure of Avida</title>
-<body
- bgcolor="#FFFFFF"
- text="#000000"
- link="#0000AA"
- alink="#0000FF"
- vlink="#000044">
+<head>
+ <title>Directory and File Structure of Avida</title>
+</head>
+<body>
-<h2 align=center>Directory and File Structure of Avida</h2>
+<p><a href="index.html">Return to the Index</a></p>
+<hr />
+<div align="center">
+<h1>Directory and File Structure of Avida</h1>
+</div>
+
<p>
-This document contains a guide to all of the files present in avida, and
-where they are located.
+This document contains a guide to the files present in Avida, and where they are located.
+</p>
+<h2>Filenames</h2>
-<h3>Filenames</h3>
-
<p>
Source code files in avida follow a standard naming convention.
-A file that ended in "<tt><font color="000088">.hh</font></tt>" is a called
-a "header" file, while one that ends in
-"<tt><font color="000088">.cc</font></tt>" is a "code" file. Headers
+All header files end with <code style="color: #000088">.h</code>.
+C++ source files use the extension <code style="color: #000088">.cc</code>.
+Python files are identified using <code style="color: #000088">.py</code>.
+In the main C++ source files, the general convention of one class per
+header/source file pair is used, with only very specific exceptions.
+
+
+
+
+Headers
tend to contain class descriptions with only the declaration of their
methods, while their corresponding code files contain the method
definitions. When one file needs to use a class defined in another, all
@@ -507,7 +515,8 @@
with additional, optional configuration files that you may want to look at
to see other possible pre-configured settings.
-<br><hr>
-Project hosted by:<br>
-<a href="http://sourceforge.net"><img src="http://sourceforge.net/sflogo.php?group_id=46761&type=2" width="125" height="37" border="0" alt="SourceForge.net"/></a>
-
\ No newline at end of file
+<hr />
+<p><a href="index.html">Return to the Index</a></p>
+
+</body>
+</html>
More information about the Avida-cvs
mailing list