Changes between Version 76 and Version 77 of Clojure Client Tutorial

Timestamp:

Aug 24, 2011 11:04:37 AM (13 years ago)

Author:

kedwar10

Comment:

--

Clojure Client Tutorial

@@ -547 +547 @@
 Although this example was meant to showcase the ways in which Clojure's support for concurrency and parallelism could represent collaborative planning, unfortunately the incorrect type was used to store the shared data, and as a result the program is not thread-safe (though still completes with high probability).  The problem arises in the value iteration algorithm, where the the function "max" is applied to a list that occasionally contains a nil value, which causes an exception (note that this exception doesn't show if the quagent is being run inside of a future and not a regular thread).  This probably occurs because updates to the shared data structure are not coordinated, and as a result, if one quagent is looking up value that another has yet to write, then a nil value will be returned.  This problem could be solved by using refs instead of atoms, since they can be coordinated without the possibility of race conditions. 
 
-To run a 2-quagent demo type the following (adding more than 2 can be problematic as the explorer is not robust to collisions.
+To run a 2-quagent demo type the following (adding more than 2 can be problematic as the explorer is not robust to collisions. Click "no" immediately if a pop-up appears (you have a few seconds before the quagents start spawning.
 
 {{{
@@ -556 +556 @@
 === Rovers ===
 
-The rover domain is a slightly altered version of the problem that appeared in the 2002 ICAPS competition.  Currently, the client uses the LPG-td planner to generate a solution and then executes it using java's scheduled thread pool class (through a wrapper call at-at). There is some difficulty in getting the scheduled functions to execute properly (can't use "at" function inside a doseq; consequently have to generate program data and map over it with "eval".  This has makes it impossible to :require the rover namespace in the core namespace as the rover functions cannot be namespace-qualified in core).  Also tried an alternative library "tron" with the same functionality but no luck.  
+The rover domain is a slightly altered version of the problem that appeared in the 2002 [[http://ipc.icaps-conference.org/ | ICAPS]] competition.  Currently, the client uses the LPG-td planner to generate a solution and then executes it using java's scheduled thread pool class (through a wrapper call at-at). There is some difficulty in getting the scheduled functions to execute properly (can't use "at" function inside a doseq; consequently have to generate program data and map over it with "eval".  This has makes it impossible to :require the rover namespace in the core namespace as the rover functions cannot be namespace-qualified in core).  Also tried an alternative library "tron" with the same functionality but no luck.  
 
 Since the original domain and problem specifications weren't intended to be executed in the real world, some changes have to be made so that they can map onto the quagents environment.  First, the domain assumes that all waypoints are equidistant, and second, it assumes some unreasonable durations for actions.  The current changes are as follows. 
@@ -605 +605 @@
 Some perl scripts are provided for making this process easier (including generating distances and outputting waypoint visibility graphs for mathematica).
 
+The following will execute an example plan.  Click "no" immediately if a pop-up appears (you have a few seconds before the quagents start spawning.
+
+{{{
+client.core=> (time-rover)
+}}}
+
+As the plan is executed, the quagents will report their actions to the .log file in the top level directory.
+
 
 ----