Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Commit [bd3505] default Maximize Restore History

Renamed all README files to README.txt

Also did some fix up to doc/source/about_pyke/modifying_pyke.txt.

Passes ./testpyke, link checks and spell checks on documentation.

mtnyogi mtnyogi 2009-11-03

1 2 > >> (Page 1 of 2)
added examples/learn_pyke/testall.config
changed doc/source/about_pyke/installing_pyke.txt
changed doc/source/about_pyke/modifying_pyke.txt
changed doc/source/links
changed doc/source/examples.txt
changed doc/cheatsheets/making_a_release
changed doc/html/about_pyke/installing_pyke.html
changed doc/html/about_pyke/modifying_pyke.html
changed doc/html/examples.html
changed doc/html/sitemap.xml
changed examples/web_framework/testall.config
copied doc/cheatsheets/from_svn/README -> doc/cheatsheets/from_svn/README.txt
copied examples/web_framework/TurboGears2/README -> examples/web_framework/TurboGears2/README.txt
copied examples/web_framework/README -> examples/web_framework/README.txt
copied examples/towers_of_hanoi/README -> examples/towers_of_hanoi/README.txt
copied examples/learn_pyke/README -> examples/learn_pyke/README.txt
copied examples/family_relations/README -> examples/sqlgen/README.txt
copied examples/sqlgen/README -> examples/family_relations/README.txt
examples/learn_pyke/testall.config Diff Switch to side-by-side view
Loading...
doc/source/about_pyke/installing_pyke.txt Diff Switch to side-by-side view
Loading...
doc/source/about_pyke/modifying_pyke.txt Diff Switch to side-by-side view
Loading...
doc/source/links Diff Switch to side-by-side view
Loading...
doc/source/examples.txt Diff Switch to side-by-side view
Loading...
doc/cheatsheets/making_a_release Diff Switch to side-by-side view
Loading...
doc/html/about_pyke/installing_pyke.html Diff Switch to side-by-side view
Loading...
doc/html/about_pyke/modifying_pyke.html Diff Switch to side-by-side view
Loading...
doc/html/examples.html Diff Switch to side-by-side view
Loading...
doc/html/sitemap.xml Diff Switch to side-by-side view
Loading...
examples/web_framework/testall.config Diff Switch to side-by-side view
Loading...
examples/towers_of_hanoi/README to examples/towers_of_hanoi/README.txt
--- a/examples/towers_of_hanoi/README
+++ b/examples/towers_of_hanoi/README.txt
@@ -15,5 +15,7 @@
 this to verify the answer...
 
     >>> from examples.towers_of_hanoi import test
-    >>> test.test(num_disks)
+    >>> test.test(2)    # test takes the number of disks as an argument
+    got 1: ((0, 1), (0, 2), (1, 2))
+    got 2: ((0, 2), (0, 1), (2, 0), (1, 2), (0, 2))
 
examples/family_relations/README to examples/sqlgen/README.txt
--- a/examples/family_relations/README
+++ b/examples/sqlgen/README.txt
@@ -1,42 +1,116 @@
-This example determines the relationships between people.
+NOTE: This example is only a proof-of-concept and is not intended for
+      production use!
 
-family.py
-    This has the primary data used by the rest of the rules.  This data is
-    established as universal facts so that it remains after an engine.reset()
-    is done.
+This example generates SQL statements, given a tuple of column names.  It was
+originally written for MySQL but now also supports Sqlite3.  It is relatively
+easy to port to other database engines.
 
-fc_example.krb
-    Forward-chaining example.  This only uses forward-chaining rules, which
-    means that all possible relationships are determined when the rule base is
-    activated.
+The following files can be used to create and populate the database.  A
+pre-populated Sqlite3 database is included in this directory as 'sqlite3.db'.
 
-bc_example.krb
-    Backward-chaining example.  This only uses backward-chaining rules, though
-    these rules are not very efficient.
+    create_database.sql
+        Creates movie_db database and users: movie_admin/admin_pw and
+        movie_user/user_pw.
+    create_tables.sql       # for MySQL
+    create_tables.sqlite3   # for Sqlite3
+        movie
+            id                  int auto_increment
+            title               varchar(100)
+            genre_id            int
+            year                year
+            length              time
+        genre
+            id                  int auto_increment
+            genre_name          varchar(100)
+        director
+            id                  int auto_increment
+            director_name       varchar(100)
+        movie_director_link
+            movie_id            int
+            director_id         int
+            billing             int
+        catalog
+            movie_id            int
+            dvd_number          int
+            selection_number    int default 1
+    drop_tables.sql
 
-bc2_example.krb
-    Backward-chaining example.  This also only uses backward-chaining rules,
-    but a few rule optimizations have been made which results in this rule base
-    running 100 times faster than bc_example.krb.
+This shell script loads 6 movies:
 
-example.krb
-    Combined rule base.  This has some forward-chaining rules, some
-    (unoptimized) backward-chaining rules, and produces plans that return the
-    relationship when run.  (This is a poor use of plans, but demonstrates the
-    syntax and underlying principles).
+    load_tables    # for MySQL
+    load_sqlite3   # for Sqlite3
+        Loads the following files in the indicated order:
+            genre.txt
+            movie.txt
+            director.txt
+            movie_director_link.txt
+            catalog.txt
+
+load_mysql_schema.py
+load_sqlite3_schema.py
+    These provide one function which loads the "schema" fact base from the
+    database connection provided:
+
+        load_schema(pyke_engine, dbi_module, db_connection)
+
+    All facts are asserted as universal facts so that they remain after an
+    engine.reset() is done.
+
+    The following facts are asserted:
+
+        schema.paramstyle(paramstyle) # e.g.: format, qmark
+        schema.column(table_name, col_name, type, null, key, default, extra)
+        schema.primary_key(table_name, columns)
+        schema.many_to_1(table_many, table_1,
+                         table_many_columns, table_1_columns)
+        schema.links_to(depth, start_table, end_table, joins)
+
+database.krb
+    This uses backward-chaining to build SQL statements and cook them into
+    plans that execute them.  The top-level goal is:
+
+        get_data($starting_tables, $needed_data) \
+          taking(db_cursor, starting_keys)
+
+    $starting_tables is a list of tables that you have id values for.  The
+    starting_keys parameter to the plan is a dictionary mapping these table
+    names to id values that identify a unique row in that table.
+
+    The $needed_data is a tuple of column_names and/or (multi-row-name,
+    (options), column_name...).
+
+    The plan will return a dictionary with keys from $needed_data and values
+    from the database.  Where the multi-row-name sub-tuple is used, the key in
+    the top-level dictionary is multi-row-name (this can be anything, it
+    doesn't match anything in the schema).  Its value is a tuple of
+    dictionaries with the indicated column_names as keys and values from the
+    database.
 
 test.py
-    Driver program.  Run:
-        >>> from examples.family_relations import test
-        >>> test.fc_test([person1='bruce'])
-        >>> test.bc_test([person1='bruce'])
-        >>> test.bc2_test([person1='bruce'])
-        >>> test.test([person1='bruce'])
-        >>> test.general([person1=None], [person2=None], [relationship=None])
+test_sqlite3.py
+    These have a debug "cursor" class that can be used instead of a real
+    database cursor.  The debug cursor class does not require a database
+    connection and returns dummy data from any SELECT call.
 
-    The last function uses the bc2_example rule base.  You can pass whatever
-    combinations of values you like.  If you want to specify person1 and/or
-    person2, pass their name; otherwise any person will match.  For the
-    relationship, pass a tuple.  Use '$var_name' strings in the tuple for
-    pattern variables.  You can also have nested tuples (as some of the
-    relationships are nested tuples).
+    Import either test or test_sqlite3 from examples.sqlgen, for example:
+
+    >>> from examples.sqlgen import test_sqlite3
+
+    Test functions:
+
+    >>> test_sqlite3.init()
+            Creates a pyke engine and calls load_schema.
+    >>> test_sqlite3.run()
+            Loops on "goal: " prompt.  Type a goal, or trace/untrace rule_name.
+            Empty string terminates the loop.  Examples:
+
+                goal: get_data((movie), (title, year, length))
+                goal: get_data((director), (director_name, (movies, (), title, year))
+
+            When the plan is run, it first runs it with the debug cursor, then
+            enters a loop prompting for the starting_keys values.  These
+            should be entered space separated.  An empty line terminates the
+            plan loop.  For example:
+
+                ('movie',): 1
+
examples/sqlgen/README to examples/family_relations/README.txt
--- a/examples/sqlgen/README
+++ b/examples/family_relations/README.txt
@@ -1,116 +1,113 @@
-NOTE: This example is only a proof-of-concept and is not intended for
-      production use!
+This example determines the relationships between people.
 
-This example generates SQL statements, given a tuple of column names.  It was
-originally written for MySQL but now also supports Sqlite3.  It is relatively
-easy to port to other database engines.
+family.py
+    This has the primary data used by the rest of the rules.  This data is
+    established as universal facts so that it remains after an engine.reset()
+    is done.
 
-The following files can be used to create and populate the database.  A
-pre-populated Sqlite3 database is included in this directory as 'sqlite3.db'.
+fc_example.krb
+    Forward-chaining example.  This only uses forward-chaining rules, which
+    means that all possible relationships are determined when the rule base is
+    activated.
 
-    create_database.sql
-        Creates movie_db database and users: movie_admin/admin_pw and
-        movie_user/user_pw.
-    create_tables.sql       # for MySQL
-    create_tables.sqlite3   # for Sqlite3
-        movie
-            id                  int auto_increment
-            title               varchar(100)
-            genre_id            int
-            year                year
-            length              time
-        genre
-            id                  int auto_increment
-            genre_name          varchar(100)
-        director
-            id                  int auto_increment
-            director_name       varchar(100)
-        movie_director_link
-            movie_id            int
-            director_id         int
-            billing             int
-        catalog
-            movie_id            int
-            dvd_number          int
-            selection_number    int default 1
-    drop_tables.sql
+bc_example.krb
+    Backward-chaining example.  This only uses backward-chaining rules, though
+    these rules are not very efficient.
 
-This shell script loads 6 movies:
+bc2_example.krb
+    Backward-chaining example.  This also only uses backward-chaining rules,
+    but a few rule optimizations have been made which results in this rule base
+    running 100 times faster than bc_example.krb.
 
-    load_tables    # for MySQL
-    load_sqlite3   # for Sqlite3
-        Loads the following files in the indicated order:
-            genre.txt
-            movie.txt
-            director.txt
-            movie_director_link.txt
-            catalog.txt
-
-load_mysql_schema.py
-load_sqlite3_schema.py
-    These provide one function which loads the "schema" fact base from the
-    database connection provided:
-
-        load_schema(pyke_engine, dbi_module, db_connection)
-
-    All facts are asserted as universal facts so that they remain after an
-    engine.reset() is done.
-
-    The following facts are asserted:
-
-        schema.paramstyle(paramstyle) # e.g.: format, qmark
-        schema.column(table_name, col_name, type, null, key, default, extra)
-        schema.primary_key(table_name, columns)
-        schema.many_to_1(table_many, table_1,
-                         table_many_columns, table_1_columns)
-        schema.links_to(depth, start_table, end_table, joins)
-
-database.krb
-    This uses backward-chaining to build SQL statements and cook them into
-    plans that execute them.  The top-level goal is:
-
-        get_data($starting_tables, $needed_data) \
-          taking(db_cursor, starting_keys)
-
-    $starting_tables is a list of tables that you have id values for.  The
-    starting_keys parameter to the plan is a dictionary mapping these table
-    names to id values that identify a unique row in that table.
-
-    The $needed_data is a tuple of column_names and/or (multi-row-name,
-    (options), column_name...).
-
-    The plan will return a dictionary with keys from $needed_data and values
-    from the database.  Where the multi-row-name sub-tuple is used, the key in
-    the top-level dictionary is multi-row-name (this can be anything, it
-    doesn't match anything in the schema).  Its value is a tuple of
-    dictionaries with the indicated column_names as keys and values from the
-    database.
+example.krb
+    Combined rule base.  This has some forward-chaining rules, some
+    (unoptimized) backward-chaining rules, and produces plans that return the
+    relationship when run.  (This is a poor use of plans, but demonstrates the
+    syntax and underlying principles).
 
 test.py
-test_sqlite3.py
-    These have a debug "cursor" class that can be used instead of a real
-    database cursor.  The debug cursor class does not require a database
-    connection and returns dummy data from any SELECT call.
+    Driver program.  Read this code to see how to call Pyke!
+    
+    Run:
 
-    Import either test or test_sqlite3 from examples.sqlgen, for example:
+        >>> from examples.family_relations import test
 
-    >>> from examples.sqlgen import test_sqlite3
+        # All of the *test functions below default to 'bruce', but I won't use
+        # that here because it generates a lot of output!
 
-    Test functions:
+        # uses fc_example.krb
+        >>> test.fc_test('michael_k')           # doctest: +ELLIPSIS
+        doing proof
+        michael_k, amanda are ('father', 'daughter')
+        michael_k, tammy are ('father', 'daughter')
+        michael_k, crystal are ('father', 'daughter')
+        <BLANKLINE>
+        done
+        family: 9 fact names, 94 universal facts, 6920 case_specific facts
+        fc_example: 20 fc_rules, 6772 triggered, 892 rerun
+        fc_example: 0 bc_rules, 0 goals, 0 rules matched
+                    0 successes, 0 failures
+        fc time ..., ... asserts/sec
 
-    >>> test_sqlite3.init()
-            Creates a pyke engine and calls load_schema.
-    >>> test_sqlite3.run()
-            Loops on "goal: " prompt.  Type a goal, or trace/untrace rule_name.
-            Empty string terminates the loop.  Examples:
+        # uses bc_example.krb
+        >>> test.bc_test('gary')                # doctest: +ELLIPSIS
+        doing proof
+        gary, justin_m are ('father', 'son')
+        <BLANKLINE>
+        done
+        bc_example: 0 fc_rules, 0 triggered, 0 rerun
+        bc_example: 26 bc_rules, 5034 goals, 17901 rules matched
+                    3563 successes, 17901 failures
+        family: 9 fact names, 94 universal facts, 0 case_specific facts
+        bc time ..., ... goals/sec
 
-                goal: get_data((movie), (title, year, length))
-                goal: get_data((director), (director_name, (movies, (), title, year))
+        # uses bc2_example.krb
+        >>> test.bc2_test('chad')               # doctest: +ELLIPSIS
+        doing proof
+        chad, tyler are ('father', 'son')
+        chad, tiffany are ('father', 'daughter')
+        <BLANKLINE>
+        done
+        bc2_example: 0 fc_rules, 0 triggered, 0 rerun
+        bc2_example: 29 bc_rules, 35 goals, 140 rules matched
+                     10 successes, 140 failures
+        family: 9 fact names, 94 universal facts, 0 case_specific facts
+        bc time ..., ... goals/sec
 
-            When the plan is run, it first runs it with the debug cursor, then
-            enters a loop prompting for the starting_keys values.  These
-            should be entered space separated.  An empty line terminates the
-            plan loop.  For example:
+        # uses example.krb
+        >>> test.test('paul')                   # doctest: +ELLIPSIS
+        doing proof
+        paul, nick are father, son
+        paul, katrina are father, daughter
+        <BLANKLINE>
+        done
+        example: 6 fc_rules, 262 triggered, 0 rerun
+        example: 21 bc_rules, 2828 goals, 6221 rules matched
+                 1414 successes, 6221 failures
+        family: 9 fact names, 94 universal facts, 422 case_specific facts
+        fc time ..., ... asserts/sec
+        bc time ..., ... goals/sec
+        total time ...
 
-                ('movie',): 1
 
+        # this has three parameters that all default to None:
+        #     person1, person2 and relationship
+        >>> test.general(person1='bruce',                # uses bc2_example.krb
+        ...              relationship=('father', 'son')) # doctest: +ELLIPSIS
+        doing proof
+        bruce, m_thomas are ('father', 'son')
+        bruce, david_a are ('father', 'son')
+        <BLANKLINE>
+        done
+        bc2_example: 0 fc_rules, 0 triggered, 0 rerun
+        bc2_example: 29 bc_rules, 105 goals, 390 rules matched
+                     82 successes, 390 failures
+        family: 9 fact names, 94 universal facts, 0 case_specific facts
+        bc time ... goals/sec
+
+    The last function uses the bc2_example rule base.  You can pass whatever
+    combinations of values you like.  If you want to specify person1 and/or
+    person2, pass their name; otherwise any person will match.  For the
+    relationship, pass a tuple.  Use '$var_name' strings in the tuple for
+    pattern variables.  You can also have nested tuples (as some of the
+    relationships are nested tuples).
1 2 > >> (Page 1 of 2)