Re: [Repast-developer] Re: [Repast-interest] BaseController, Controller and BatchController (and Jelly)

[Nick C. <nic...@ve...>]

Forgot the jpg. Here is is.



On Mon, 2002-12-23 at 21:19, Andy Cleary wrote:
> At 03:35 PM 12/16/2002 -0500, you wrote:
> >Hi,
> >
> >The new IController interface defines methods for executing (starting,
> >stopping etc.) a simulation. The BaseController implements this
> >Interface in an asynchronous way, that is, it creates a thread and
> >executes scheduled actions in this thread. Start, stop etc. merely
> >(oversimplifying a bit) start and stop this thread. The batch controller
> >and gui controller add parameter handling on top of this. A new
> >controller, Thin Controller, adds a bit more that is necessary for a
> >non-abstract controller, but it still relies on BaseController to set up
> >the thread.
> >
> >So, if you want a controller that not so asynchronous then what repast
> >supplies won't work. However, it would be fairly easy to construct such
> >a thing using BaseController as a model. In fact it sounds like all you
> >want is to create a Schedule add actions to it for execution and then
> >iterate over the Schedule calling execute some number of times. Again,
> >looking at the code in Schedule and ScheduleBase would might help you
> >out here.
> 
> After studying the APIs and the code (out of 2.0) for the above classes, I 
> can say... I partially get it. ;-)
> 
> Do you happen to have any documents, scribbles, backs of envelopes, etc., 
> that help layout the "object interaction" amongst these various things? I 
> forget what the official UML-ish name for that is, but the point is that 
> the APIs do a fine job of laying out the class hierarchy and such; the 
> pattern of communication between controllers, simModels, and Schedules 
> remains confusing to me, probably largely because of the separate threads 
> being used, and partially because I formed preconceived notions based only 
> on the names of these classes and they don't seem to match what is there, 
> and mostly because one has to read the code to figure it out rather than 
> being able to see it in some sort of documentation. As you correctly 
> surmised, my case should actually be easier since I will be controlling 
> things programmatically and can, for example, avoid separate threads.
> 
> Obviously, though, I want to A) make changes that actually work, B) do the 
> minimal amount of changes so that any future change to repast will have a 
> minimal effect on whatever I write. To do that intelligently means I need a 
> better understanding of the overall vision of the architecture associated 
> with these things. The long way to do this is to keep studying the code, 
> run it through the debugger and follow the call stack, etc., but if there's 
> a headstart I'll take it.
> 
> 
> >I've often thought that it should be possible to create composite nested
> >simulations out of pieces that repast provides, and it would be good to
> >see someone try!
> 
> I am going to try... How long I'll go before I give up remains unclear. If 
> I get it working, we can discuss whether there is anything that can be 
> reused in the Repast framework more generally...
> 
> Cheers,
> Andy
> ============================================
> Andrew J. Cleary, Software Engineer/Computational Scientist
> Lawrence Livermore National Labs, 925-424-5890.
> ============================================
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net