xcfit 0.9.0 → 1.0.0

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/QueryTable/content.txt

@@ -1,67 +0,0 @@
-The rows in a query table represent the expected results of a query.  
-You can specify them precisely if you like as in the following:
-
-| Query:employees hired before | 10-Dec-1980 |
-| company number | employee number | first name | last name | hire date |
-| 4808147 | 9942 | Bill | Mitchell | 19-Dec-1966 |
-| 4808147 | 1429 | Bob | Martin | 10-Oct-1975 |
-
-Or you can leave cells blank and allow them to be filled in:
-
-| Query:employees hired before | 10-Dec-1980 |
-| employee number | first name | last name | hire date |
-| 1429 | | | |
-| 8832 | | | |
-
-The code for the fixture is:{{{package fitnesse.slim.test;
-
-import java.util.Date;
-import java.util.List;
-
-import static java.util.Arrays.asList;
-
-public class EmployeesHiredBefore {
-
-  public EmployeesHiredBefore(Date date) {
-  }
-
-  public void table(List<List<String>> table) {
-    // optional function
-  }
-
-  public List<List<List<String>>> query() {
-
-    return
-      asList( // table level
-        asList( // row level
-          asList("company number", "4808147"), // cell column name, value
-          asList("employee number", "1429"),
-          asList("first name", "Bob"),
-          asList("last name", "Martin"),
-          asList("hire date", "10-Oct-1974")
-        ),
-        asList(
-          asList("company number", "5123122"),
-          asList("employee number", "8832"),
-          asList("first name", "James"),
-          asList("last name", "Grenning"),
-          asList("hire date", "15-Dec-1979")
-        )
-      );
-  }
-}
-}}}
-Note the ''list'' function simply builds an !-ArrayList-! from it's arguments.  It's in the !-ListUtility-! class
-
-The first thing to notice is the ''Query:'' in the first cell of the table.  This tells the Slim table processor that this is a query table.  Next notice the constructor argument.  (See ConstructorArguments).  The column headers are ''field names''.  The fixture class must have a ''query'' method that returns a list of rows.  Each row is a list of fields.  Each field is a two-element list composed of the ''field name'' and it's string value.
-
-Each row in the table is checked to see if there is a match in the query response.  The fields are matched left to right.  If the leftmost field matches, then the row is considered to be "found".  Fields that don't matche are marked in error as in the 10-Oct-1974 field above.  A cell that is left blank in the table will be filled in from the result and counted as ignored.  If the first cell of a row cannot be matched, then the row is considered ''missing''.  If there is an unmatched row remaining in the query response, it is added to the table and marked ''surplus''. The order of the rows is irrelevant.
-
-If a !style_code(table) method is declared in the fixture it will be called before the !style_code(query) function is called.  It will be passed a list of rows which are themselves lists of cells.  The rows and cells represent the all but the first row of the table.  This is the same format at the !style_code(doTable) method of Table table, and the !style_code(table) method of Decision table.
-
-In analogy to decision tables you can define comment columns by prefixing the header with the hash symbol.
-
-| Query:employees hired before | 10-Dec-1980 |
-| last name | hire date | # comment |
-| Grenning | | |
-| Martin | | we hired him first |

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/QueryTable/properties.xml

@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Edit/>
-<Files/>
-<Properties/>
-<RecentChanges/>
-<Refactor/>
-<Search/>
-<Test/>
-<Versions/>
-<WhereUsed/>
-<saveId>1234379903398</saveId>
-<ticketId>6607618891543149048</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ScenarioTable/content.txt

@@ -1,146 +0,0 @@
-!include -c .FitNesse.SuiteAcceptanceTests.SetUp
-----
-A Scenario table is a table that can be called from other tables; namely ScriptTable and DecisionTable.
-
-The format of a Scenario table is the same as the format of a ScriptTable, but with a few differences.  You can see a Scenario table in action [[here][.FitNesse.SuiteAcceptanceTests.SuiteWidgetTests.SimpleWidgets]].
-
-!4 Declaring Scenarios using ''Interposed'' style
-The basic format looks like this:
-
-!| scenario | widget | wikiText | renders | htmlText |
-| create page | WidgetPage | with content | @wikiText |
-| check | request page | WidgetPage | 200 |
-| ensure | content matches | @htmlText |
-| show | content |
-
-!***> No Peeking
-
-| script | page driver |
-
-*!
-The first word in the table is ''Scenario''.  Following that is the signature of the scenario.  This signature is a lot like a function declaration.  The name of the scenario in the table above is ''!-WidgetRenders-!'', and it takes two arguments: ''wikiText'' and ''htmlText''.  Notice how this looks a lot like a function call in a ScriptTable.  The name is composed of every other table cell appropriately camel-cased.  The arguments are the interposed cells, also appropriately camel-cased.  Scenario names will be camel-cased with a leading upper-case letter.  Arguments will be camel-cased with a leading ''lower-case'' letter.
-
-!4 Declaring Scenarios using ''Parameterized'' style.
-You can also declare a scenario by embedding underscores within a string.  Each underscore represents an argument.  The arguments are named in a comma separated list in the following cell.
-
-!| scenario | widget _ renders _ | wikiText,htmlText |
-| create page | WidgetPage | with content | @wikiText |
-| check | request page | WidgetPage | 200 |
-| ensure | content matches | @htmlText |
-| show | content |
-
-The body of the scenario uses the arguments by prefixing them with an '@' sign. The token that follows the '@' ''must be the camel-cased name of the argument.''   Arguments that share a common root string can use optional braces to force the correct evaluation of the full name of the argument.  Thus, if you have arguments ''job'' and ''job code'', you can use @{jobCode} to make sure you get the argument with the longer name.
-
-!4 Invoking a scenario from a DecisionTable
-!| widget renders |
-| wiki text | html text |
-| this is ''italic'' text | this is <i>italic</i> text | italic widget |
-| this is '''bold''' text | this is <b>bold</b> text | bold widget |
-
-Notice that the name of the decision table, once camel-cased, will be ''!-WidgetRenders-!''.  Since this is the name of the above scenario, the scenario will be called rather than a fixture.  This is important!  Remember that if a scenario is on your page, or included into your page, then its name will override any fixture that has the same name.  Scenarios come first!
-
-If you'd rather you can reference the scenario with parameters so long as you make sure the argument names in the reference exactly match the argument names in the declaration.  For example the above test could have been written as:
-
-!| widget | wiki text | renders | html text |
-| wiki text | html text |
-| this is ''italic'' text | this is <i>italic</i> text | italic widget |
-| this is '''bold''' text | this is <b>bold</b> text | bold widget |
-
-The column headers of the DecisionTable are named for the arguments of the scenario (again, once properly camel-cased).  The scenario processor simply replaces the arguments in the scenario with the contents of the table cells below the corresponding header.
-
-If you hit the test button, you will see the scenario operate.  It's pretty self-explanatory.  If you look at the resulting DecisionTable you'll see that an extra column has been added to each row.  That column contains a collapsed section with the entire scenario table with all the arguments replaced.  You can expand it by clicking on the litte arrow. Try it.
-
-!5 Output parameters
-You can also use ''output parameters'' with scenarios. These are basically symbols you assign in the scenario that you can then refer to in the decision table by creating a column whose name ends on '?'. This allows you to capture values in your scenario, making the symbols filled explicit and allowing different comparisons (for instance equality, greater than, etc) in different rows.
-
-!| scenario | widget _ renders _ code _ | wikiText,htmlText,responseCode? |
-| create page | WidgetPage | with content | @wikiText |
-| $responseCode= | request page | WidgetPage |
-| ensure | content matches | @htmlText |
-| show | content |
-
-!| widget renders code |
-| wiki text | html text | response code? |
-| this is ''italic'' text | this is <i>italic</i> text | 200 |
-| this is '''bold''' text | this is <b>bold</b> text | > 100 |
-
-!5 Constructor parameters
-When all rows in a decision table need to set the same value for some parameters these can be specified using ‘’constructor parameters’’, instead of repeating them for each row. This can make the decision tables more readable. In the example below the input variables "wiki text" and “html text” are given on the table construction line and not repeated in each row.
-
-!| widget renders code | given | wiki text | this is ''italic'' text | html text | this is <i>italic</i> text |
-| response code? |
-| 200 |
-| > 100 |
-
-The Syntax is - Scenario Name - !-[given|having]-! - 1. Variable Name - 1. Variable Value - 2. Variable Name - 2. Variable Value - ....
-
-To ensure backward compatibility constructor parameters are first checked if they are part of a scenario name.
-
-If a senario is found it will be used and no constructor values are passed. Only if no such scenario is found the constructor parameters can be used.
-
-!4 Invoking a scenario from a script table using ''Interposed'' style
-!| Script |
-| widget | !3 hello | renders | <h3>hello</h3> |
-
-Notice how the scenario is called exactly the way a function is called.  Remember though that scenarios do not have return values.  So you can't call a scenario from within a 'check' or 'show' row in a script table.  Also keep in mind that scenario names come first, so a scenario will override a function in the current fixture.
-
-By the way, what fixture was being used here?  If you look inside the ''No Peeking'' section above, you'll see where I started the fixture.  What's neat about this is that you can start any fixture you like, so long as it has appropriately named functions.  So the scenario and script calls are ''polymorphic'' with respect to the fixture.  (Let the reader understand and beware!)
-
-!4 Invoking a scenario using ''Parameterized'' style
-!| Script |
-| widget !3 hello renders <h3>hello</h3> |
-
-As you can see you can also drop the table cells and simply write the scenario name and arguments on a single line without any separators.  The scenario with the ''most'' arguments that matches the statement will be selected.  So given two scenarios: !style_code(widget _ renders _) and !style_code(widget _), both match the statement !style_code(widget foo renders bar), but the first will be invoked because it has more arguments than the second.
-
-!4 A complex example
-It's even possible to have multiple arguments at the end of the scenario declaration. Nested scenario's can be called similarly, with a semi-colon after the "method" name:
-
-| scenario | show values _ | a,b,c |
-| note | a = @a |
-| note | b = @b |
-| note | c = @c |
-
-| scenario | execute this _ | a,b,c |
-| show values; | @a | @b | @c |
-
-Called from decision table:
-
-| execute this |
-| a | b | c |
-| 1 | 2 | 2 |
-
-!4 Nested Scenarios
-Scenarios can also be nested! If you hit the test button, you'll see scenarios executing within other scenarios.
-
-!| scenario | make page | page name | with | wikiText |
-| create page | @pageName | with content | @wikiText |
-| check | request page | @pageName | 200 |
-
-!| scenario | page | wiki text | renders | html text |
-| make page | MyPage | with | @wikiText |
-| ensure | content matches | @htmlText |
-| show | content |
-
-!| Script |
-| page | !3 hello | renders | <h3>hello</h3> |
-
-!4 A note on parameter matching
-Note that the replacement of parameters is based on straightforward text matching. In the following example the outcome may look a bit weird, but the algorithm has been kept as simple as possible:
-
-!| scenario | make misleading page _ with content _ | page, pageContent |
-| create page | @page | with content | @pageContent |
-| check | request page | @page | 200 |
-
-!| Script |
-| make misleading page | PageName | with content | some content |
-| reject | content matches | some content |
-
-In this example, the ''@page'' tokens are replaced with the page name, hence ''@pageContent'' becomes ''!-<i>PageNameContent</i>-!'' (''@page'' is replaced, ''-Content'' remains).
-
-!4 Philosophy
-There are no ''if'' or ''while'' statements within scenarios.  They are macros, not programs.  They are constructed via text substitution.  Their purpose is to help you eliminate redundancy in your tests.
-
-!4 Scenario Libraries
-See <UserGuide.SpecialPages.  You can place libraries of scenarios into pages named !-ScenarioLibrary-!. These pages will be automatically included into any Slim test page using the familiar ''uncle hierarchy'' used for !-SetUp-!, !-TearDown-!, etc.  !-ScenarioLibrary-! pages are special because all uncles and brothers are loaded.
-
-!include -c .FitNesse.SuiteAcceptanceTests.TearDown

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ScenarioTable/properties.xml

@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Edit/>
-<Files/>
-<Properties/>
-<RecentChanges/>
-<Refactor/>
-<Search/>
-<Test/>
-<Versions/>
-<WhereUsed/>
-<saveId>1238174209178</saveId>
-<ticketId>1483156031156832784</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ScriptTable/content.txt

@@ -1,71 +0,0 @@
-| script | login dialog driver | Bob | xyzzy |
-| login with username | Bob | and password | xyzzy |
-| check | login message | Bob logged in. |
-| reject | login with username | Bob | and password | bad password |
-| check | login message | Bob not logged in. |
-| check not | login message | Bob logged in. |
-| ensure | login with username | Bob | and password | xyzzy |
-| note | this is a comment |
-| show | number of login attempts |
-| $symbol= | login message |
-
-The fixture for this table is:{{{public class LoginDialogDriver {
-  private String userName;
-  private String password;
-  private String message;
-  private int loginAttempts;
-
-  public LoginDialogDriver(String userName, String password) {
-    this.userName = userName;
-    this.password = password;
-  }
-
-  public boolean loginWithUsernameAndPassword(String userName, String password) {
-    loginAttempts++;
-    boolean result = this.userName.equals(userName) && this.password.equals(password);
-    if (result)
-      message = String.format("%s logged in.", this.userName);
-    else
-      message = String.format("%s not logged in.", this.userName);
-    return result;
-  }
-
-  public String loginMessage() {
-    return message;
-  }
-
-  public int numberOfLoginAttempts() {
-    return loginAttempts;
-  }
-} }}}
-
-This should be pretty clear.  Each row is a single instruction in the script.
-
-The first row is simply the word "Script" followed by the name and constructor arguments of the fixture (known as the "actor") that will be used by the rest of the table.  If there is no actor specified then the previous script table's actor on this test page will be used.
-
-The first cell could also have been 
-|Script:login dialog driver | Bob | xyzzy |
-
-Most instructions involve some kind of function call.  By default, the name of the function is assembled from tokens in ''every other'' cell.  The arguments of the function are the intervening cells. Appending ";" to the end of a function name in a cell invokes sequential argument processing, which means that the arguments to the function are all subsequent cells.
-
-''Interposing Function Call (Default)''
-
--| comment |
-| login with username | Bob | and password | xyzzy |
-
-''Sequential Argument Processing Function Call''
-
--| comment |
-| login with username and password; | Bob | xyzzy |
-
- * A function alone in a row will turn !style_red(red) or !style_green(green) if it returns a boolean.  Otherwise it will simply remain uncolored.
- * If [[a symbol assignment][SymbolsInTables]] is in the first cell, then it should be followed by a function.  The symbol is assigned the value returned by that function.
- * If the word '''''check''''' is in the first cell of a row, then a function call follows it.  The last cell of the table is the expression we expect to be matched by what the function actually returns.
- * If the word '''''check not''''' is in the first cell of a row, then a function call follows it.  The last cell of the table is the expression we expect ''not'' to be matched by what the function actually returns.
- * If the word '''''ensure''''' is in the first cell, then it should be followed by a function that should return a boolean ''true'' for !style_green(green) and ''false'' for !style_red(red).
- * If the word '''''reject''''' is in the first cell, then it should be followed by a function that should return a boolean ''false'' for !style_green(green) and ''true'' for !style_red(red).
- * If the word '''''note''''' is in the first cell, all other cells in that row will be ignored.
-   * Or if the first cell is blank.
-   * Or if the first cell begins with # or *.
- * If the word '''''show''''' is in the first cell, then it should be followed by a function.  A new cell will be added when the test is run, and it will contain the return value of the function.
- * If the word '''''start''''' appears in the first cell, then the rest of the row is the name and constructor arguments for a new actor, which replaces the existing actor.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/ScriptTable/properties.xml

@@ -1,14 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit/>
-	<Files/>
-	<Properties/>
-	<RecentChanges/>
-	<Refactor/>
-	<Search/>
-	<Test/>
-	<Versions/>
-	<WhereUsed/>
-	<saveId>1232649253653</saveId>
-	<ticketId>-7576501324773113274</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/SetUp/content.txt

@@ -1,6 +0,0 @@
-!*> setup
-|import|
-|fitnesse.slim.test|
-|fitnesse.fixtures|
-
-*!

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/SetUp/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1231691120894</saveId>
-	<ticketId>2877052885879097211</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/SlimProtocol/PortManagement/content.txt

@@ -1 +0,0 @@
-The !-SlimServer-! opens and listens to a server socket.  It gets the port number from !-FitNesse-! via the command line.  The default is 8085 and it cycles through the next 10 ports to avoid collisions.  If 8085 is not convenient for you, you can set the !style_code(SLIM_PORT) variable to any port you like.  This variable can be defined on a page by page basis with !-!define-!, or it can be specified with !style_code(-DSLIM_PORT=xxxx) on the !style_code(java) command line, or it can be an environment variable.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/SlimProtocol/PortManagement/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1237228442617</saveId>
-	<ticketId>-1593763266452230916</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/WritingAcceptanceTests/SliM/SlimProtocol/content.txt

@@ -1,145 +0,0 @@
-!2 The Slim Protocol, version 0.4
-
-!-FitNesse-! communicates with Slim over a socket (see >PortManagement).  When you hit the ''Test'' button, !-FitNesse-! starts up a !-SlimServer-! process by issuing the appropriate command line.  !-FitNesse-! then sends a list of instructions to the !-SlimServer-!, and expects a list of responses back.  The instructions are things like ''call function f(a,b,c)'' or ''make instance of class X with arguments p,q,r''.  The responses are simply the values that are returned by the instructions.
-
-{{{
-             instruction list
-  +----------+    o--->     +------------+      +----------+       +-----+
-  | FitNesse |---[socket]-->| SlimServer |----->| Fixtures |------>| SUT |
-  +----------+    <---o     +------------+      +----------+       +-----+
-               response list
-}}}
-
-Each instruction in the list is itself a list of strings.  Here is a typical instruction list:{{{
-      [
-        [id_0, make, instance, fixture, argument],
-        [id_1, call, instance, f, 3],
-      ]}}}The first instruction in this list tells the !-SlimServer-! to create an instance of a class named ''fixture'' using the constructor argument ''argument'', and register the newly created instance under the name ''instance''.  The next instruction causes the function ''f'' to be called on the instance ''instance'', passing the value ''3''.  The first column in each instruction is simply an instruction id.
-
-The response to this instruction list might look like this:{{{
-      [
-        [id_0, OK],
-        [id_1, 9]
-      ]
-}}}Again, each element of the response list is itself a list of strings.  The first string in each response is the id of the instruction being responded to.  The second is the response value.  In this case the construction in instruction ''id_0'' was successful, and the call to function ''f'' with value ''3'' in instruction ''id_1'' returned a ''9''.
-
-That's pretty much it.  Lists of instructions go out.  Lists of responses come back.  Typically the instructions for an entire test page will be sent in one large list, yielding one large response list.
-
-There is no type information in the instructions.  Each instruction is a list of strings.  Each response is a list of strings.  Strings and lists are the only two types in the entire protocol.  It is up to the !-SlimExecutor-! to find the functions and constructors that match the instructions, and to do the necessary type conversion.
-
-!3 The Data
-The !-SlimServer-! maintains five pieces of data that are operated on by the instructions that it processes.
-
- * A list of class search path items.
- * A dictionary of created objects. Each object is addressed by an instance name string.
- * A dictionary of symbol values. Each symbol value is addressed by a symbol name string.
- * ''[0.1]'' '''Library Instances:''' A stack of library objects.
- * ''[0.3]'' '''Actors:''' A stack of actor objects.
-
-!3 The Instructions
-There are five instructions in the Slim protocol.  import, make, call, callAndAssign, and ''[0.4]'' assign.  That's all.
-
-!4 Import
-[''<id>'', import, ''<path>'']
-
-This instruction causes the <path> to be added to the list of class search path items.  In java <path> gets added to the ''CLASSPATH''.  In ''.NET'', the <path> is a namespace.  You can send as many imports as you like.  The Slim system will use all imported paths to find fixture classes.  This instruction returns ''OK''.
-
-!4 Make
-[''<id>'', make, ''<instance>'', ''<class>'', ''<arg>...'']
-
-This instruction causes slim to search for a class named ''<class>'' using the list of class search path items.  ''<class>'' can also be fully qualified.  If found slim looks for a constructor with the right number of arguments.  If found, the ''<arg>'' strings are converted to the appropriate types, and the constructor is called.  The newly created instance is added to the dictionary of created objects with the name ''<instance>'', and the instruction returns ''OK''.
-
-''[0.1]'' '''Library Instances:''' If a ''make'' instruction creates an object with an instance name that begins with !style_code(library) then that instance is pushed on the stack of library objects.  These objects endure for the entire duration of the !-SlimServer-! execution.
-
-''[0.2]'' '''Fixture Chaining:''' Symbols can be used in the ''Make'' command to represent a class name.  If the ''<class>'' argument of the ''Make'' command contains '$' characters, then Slim should replace any symbols that have been created by previous ''callAndAssign'' commands.  This allows !-FitNesse-! to compose fixture names from symbols set by fixtures, and therefore enables fixture chaining.
-
-''[0.3]'' '''Symbol Copy:''' If ''<class>'' consists entirely of a single symbol name prefixed with $, and the item from the dictionary of symbol values with the symbol name is not a string, then the item is added to the dictionary of created objects with the name ''<instance>''. The ''<arg>'' strings are ignored and no constructor is called.
-
-!4 Call
-[''<id>'', call,''<instance>'',''<function>'',''<arg>...'']
-
-This instruction causes slim to find a function named ''<function>'' in the class of the object from the dictionary of created objects with the name ''<instance>''.  The function must have the same number of arguments as the instruction.  If found, each argument in the instruction is converted to the appropriate type, and then the function is called on the instance.  The ''<arg>'' strings may contain symbols (see below) which will be substituted before the type conversion is done. If the function returns a value, it is converted to a string and returned.  Otherwise the instruction returns the string: ''/__VOID__/''.
-
-''[0.1]'' '''System Under Test:''' Each fixture may have a way to declare a particular object to be the ''System Under Test''.  In java this is done with the @SystemUnderTest attribute.  In !-RubySlim-! the object is accessed using the ''sut'' method.  In .NET, the fixture implements the !-DomainAdapter-! interface.  Whatever mechanism is used, if a the method specified by a ''Call'' or ''!-CallAndAssign-!'' is not found on the specified instance, then if there is a ''System Under Test'' object specified, and the method exists on that object, then it will be called.
-
-''[0.1]'' '''Library Instances:''' If a method specified by a ''Call'' or ''!-CallAndAssign-!'' is not found on either the specified instance, or on the ''System Under Test'' then the stack of library objects is searched, starting at the top (latest).  If the method is found, it is called.
-
-''[0.3]'' '''Symbol As Object:''' If an ''<arg>'' consists entirely of a single symbol name prefixed with $, then the item from the dictionary of symbol values with the symbol name is used directly as an argument in the function call.
-
-!4 !-CallAndAssign-!
-[''<id>'', callAndAssign, ''<symbol>'', ''<instance>'', ''<function>'', ''<arg>...'']
-
-This instruction is identical to ''call'' except that the return value is saved in the dictionary of symbol values with the name ''<symbol>''.  Symbol names may only contain letters.
-
-!4 ''[0.4]'' !-Assign-!
-[''<id>'', assign, ''<symbol>'', ''<value>'']
-
-This instruction is used to set symbols on the SUT. The ''<value>'' is saved in the dictionary of symbol values with the name ''<symbol>''. This instruction returns ''OK''.
-
-!3 Symbols
-That last one was probably puzzling.  Symbol values are strings or objects (or null values) that are kept in a dictionary.  The ''callAndAssign'' instruction is the only thing that can create a symbol.  Symbols are used in in the ''<arg>'' strings of the ''make'', ''call'', and ''callAndAssign'' instructions.  If one of those ''<arg>'' strings contains a $ followed by a symbol name (as in $V), and if the symbol has been assigned, then that string will be replaced by the value of the symbol. What this means is that the !-FitNesse-! side can tell Slim to remember a value in a symbol, and then to use that value later.
-
-''[0.3]'' '''Symbol As Object:''' If the symbol is replaced within a string context, it will be converted to a string. If only the $ followed by a symbol name is given and an object is stored for that symbol, then the object will be used.
-
-!3 Actors
-''[0.3]'' The stack of library objects should be initialized with an instance of a class with the following 3 methods:
-
- * getFixture(): returns the object from the dictionary of created objects named "scriptTableActor". Throws an exception if no object exists.
- * pushFixture(): pushes the object from the dictionary of created objects named "scriptTableActor" on to the stack of actor objects. Throws an exception if no object exists.
- * popFixture(): pops an object from the stack of actor objects and adds it to the dictionary of created objects with the name "scriptTableActor". Throws an exception if the stack is empty.
-
-To support symbol assignments in Decision Tables which are implemented with a Scenario function is required in a Library:
-
- * cloneSymbol
-
-!3 Strings and Lists
-As we will see, slim views a list as a special kind of string.  Therefore functions can take and return lists as well as strings.  The lists must be lists of strings, but since a list is a special kind of string, lists of lists of lists of ... are possible.  The Slim executor will convert back and forth between these forms as needed.
-
-A string is encoded as six or more digits followed by a colon, followed by the characters of the string.  The six+ digits are the number of characters in the string, not including the digits themselves.  Thus, the empty string is "000000:".  This length encoding scheme is used in other places so we'll use the token ''<length>'' to mean six digits followed by a colon.
-
-If a string is ''<null>'', then the four character string ''null'' will replace it.
-
-A list is encoded as a string that begins with a '[', followed by a ''<length>'' specifying the number of items in the list.  This is followed by that many strings, each terminated by a colon, and then finally a ']'  Thus, this list: ''[hello,world]'' is encoded as the following string:{{{000035:[000002:000005:hello:000005:world:]}}}Take careful note of all the colons and counts.  Colons are terminators not separators.
-
-As you can see, each item of a list is a string.  But since a string can encode a list, each item of a list can be another list.  So we can have very deep recursive definitions.
-
-''[0.4]'' For versions older than 0.4, the length part of an encoded string was exactly six digits. For version 0.4 the size can grow beyond 6 digits for really long messages.
-
-!3 Slim Server
-So when you send a list of instructions, what you are really sending is a string.  When you receive a list of responses, what you are really receiving is a string.  So the high level protocol of Slim is just strings.  It looks like this:
-
- 1 !-FitNesse-! invokes the Slim Server via a command line.  One of the command line arguments is the port number of the socket to listen on.  !-FitNesse-! opens that socket.
- 1 Slim Server responds with the string "Slim !----! ''V<version>''\n", where ''<version>'' is the version number of the slim ''protocol''.  If this protocol ever changes, ''that'' version number will change.  This is the only string that is ever sent without the ''<length>'' encoding.  It is terminated by the '''\n''' instead.  Every other message that slim sends will be prefixed by a ''<length>'' in ''!style_red(bytes)'', followed by a colon.  !style_red(NOTE:) Every other length in this document is in UTF-8 ''characters''.  This one length is in bytes.
- 1 !-FitNesse-! sends a list of instructions encoded as a string of course.
- 1 Slim Server sends a list of responses similarly encoded.
- 1 3 and 4 repeat until !-FitNesse-! sends a ''bye'' directive.  This is simply the string ''bye'' properly encoded with ''<length>''.  e.g. "000003:bye".
- 1 Slim Server shuts down.
-
-!3 Exceptions
-Sometimes a function or a constructor will throw an exception in response to a ''make'', ''call'', or ''callAndAssign'' instruction. When this happens, the response value for that instruction will be: "__EXCEPTION__:''<exception string>''".  The ''<exception string>'' ought to be a stack trace or some other relevant debugging information.  If you want a nice yellow message to appear in one of the SLIM tables, then somewhere in the ''<<exception string>>'' put ''message:<<'' in front of the message and ''>>'' after it.  e.g.   !style_code(message:<<can't find constructor>>)
-
-!4 Standard exception messages
-There are some standard exception messages that every Slim implementation should create.
-
-| COULD_NOT_INVOKE_CONSTRUCTOR ''<some class>'' | Where ''<some class>'' is the name of the class whose constructor cannot be invoked. |
-| NO_METHOD_IN_CLASS ''<some method>'' ''<some class>'' | Where ''<some method>'' is the name of the missing method. |
-| NO_CONSTRUCTOR ''<some class>'' | Where ''<some class>'' is the name of the class that is missing the constructor. |
-| NO_CONVERTER_FOR_ARGUMENT_NUMBER ''<argument type>'' | Where ''<argument type>'' is the class that has no corresponding converter. |
-| NO_INSTANCE ''<instance name>'' | Where ''<instance name>'' is the name of the missing instance. |
-| NO_CLASS ''<some class>'' | Where ''<some class>'' is the class that could not be found. |
-| MALFORMED_INSTRUCTION [''instruction list''] | Where ''instruction list'' is a comma separated list of the instruction strings. |
-| TIMED_OUT ''<n>'' | The instruction timed out after ''<n>'' seconds. To enforce timeouts, set the ''-s xx'' flag (via the ''slim.flags'' variable) |
-
-!4 Aborting a Test 
-If a fixture throws an exception with a ''class'' name that contains "!style_code(!-StopTest-!)", then Slim should stop executing the instructions in the current batch, and return immediately.   The response for this type of exception should be "!style_code(__EXCEPTION__:ABORT_SLIM_TEST:)" which may have an optional suffix of: "!style_code(message:<<''reason''>>)".
-
-To abort the test suite (stop execution directly), throw an exception with a class name that contains "!style_code(!-StopSuite-!)". The syntax is identical to !-StopTest-!.
-
-!3 Type Conversions
-The only types in the instructions and responses are lists and strings, and since the leaves of the lists must eventually be strings, all we really have to worry about are strings.  But we don't want to restrict our fixtures to use only Strings.  So Slim comes with some standard type converters that allow fixtures to take more convenient data types.
-
-!see DataTypes.
-''[0.1]'' '''Hashes:''' !style_note(Optional) If one of the method arguments int a ''Make'', ''Call'', or ''!-CallAndAssign-!'' matches the "hash" format, then it should be converted into a dictionary, or a hash, or some convenient form for the fixture authors.  In Java they are converted into Maps.  In Ruby they are converted into Hashes.  Other languages may use other structures.  The "hash" format is the format produced by the [[Hash Widget][<UserGuide.MarkupHashTable]], and is simply the HTML for a table with two columns and ''n'' rows. !style_code(<table><tr><td>name</td><td>value</td></tr>...</table>).
-
-!3 Conclusion
-That's pretty much it.  If you want to port Slim to a new platform, I suggest you look at the code in the fitnesse.slim package.  Pay special attention to the !-ListSerializer-! and !-ListDeserializer-! classes.  Also check out the logic in Statement and !-StatementExecutor-! classes.  The unit tests ought to be expecially educational. You should be able to build equivalent unit tests without much fuss.  Finally, take a look at the unit tests in fitnesse.responders.run.slimResponder.  These should all still run with your new port (although you'll have to replace the command line that invokes the Slim Server).