Changes between Version 76 and Version 77 of Clojure Client Tutorial


Ignore:
Timestamp:
Aug 24, 2011 11:04:37 AM (13 years ago)
Author:
kedwar10
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Clojure Client Tutorial

    v76 v77  
    547547Although 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.
    548548
    549 To run a 2-quagent demo type the following (adding more than 2 can be problematic as the explorer is not robust to collisions.
     549To 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.
    550550
    551551{{{
     
    556556=== Rovers ===
    557557
    558 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. 
     558The 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. 
    559559
    560560Since 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.
     
    605605Some perl scripts are provided for making this process easier (including generating distances and outputting waypoint visibility graphs for mathematica).
    606606
     607The following will execute an example plan.  Click "no" immediately if a pop-up appears (you have a few seconds before the quagents start spawning.
     608
     609{{{
     610client.core=> (time-rover)
     611}}}
     612
     613As the plan is executed, the quagents will report their actions to the .log file in the top level directory.
     614
    607615
    608616----