MASON-INTEREST-L Archives

April 2013

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Wed, 10 Apr 2013 15:34:25 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (76 lines)
What I meant was: why use finish()?  Why not just re-create all the data structures in start() and let the previous ones, if they exist, naturally gc?

Sean

On Apr 10, 2013, at 3:30 PM, Mark Coletti wrote:

> I believe that's what I was saying, though perhaps I wasn't clear enough.  A finish() method that's automatically invoked at the end of the run with appropriate GeomVectorField.clear() invocations will do exactly that.
> 
> 
> On Wed, Apr 10, 2013 at 3:22 PM, Sean Luke <[log in to unmask]> wrote:
> Why not just throw away all of the JTS objects and build from scratch at start() time?
> 
> Sean
> 
> On Apr 10, 2013, at 3:16 PM, Mark Coletti wrote:
> 
> > Try adding a finish() method that clears out everything at the end of a run.
> >
> >
> > On Wed, Apr 10, 2013 at 3:02 PM, Luís de Sousa <[log in to unmask]> wrote:
> > Mark and Sean, thanks for the replies.
> >
> > This solves things at run time, but agents left over from previous runs are still portrayed in subsequent runs (in the little example I sent you can try hitting the stop button before it gets to setp 20 and then restart).
> >
> > I imagine the updateSpatialIndex() method or something else that permanently destroys the Stoppable objects must be invoked when the run ends. I tried to do it in the GUIState class but without success. There doesn't seem to exist any way in the Scheduler class to set something to run at simulation end either. How else can I do it?
> >
> > Thank you,
> >
> > Luís
> >
> >
> >
> >
> > On 9 April 2013 04:19, Sean Luke <[log in to unmask]> wrote:
> > On Apr 8, 2013, at 10:05 PM, Mark Coletti wrote:
> >
> > > In other words, I think I resolved your problem by adding the following to your Sim.start():
> > >
> > >         schedule.scheduleRepeating(new Steppable()
> > >         {
> > >             public void step(SimState state)
> > >             {
> > >                 trailSpace.updateSpatialIndex();
> > >             }
> > >
> > >         });
> >
> > Quick suggested improvement:
> >
> >
> > >         schedule.scheduleRepeating(new Steppable()
> > >         {
> > >             public void step(SimState state)
> > >             {
> > >                 trailSpace.updateSpatialIndex();
> > >             }
> > >
> > >         }, -1, 1);
> >
> > This will cause updateSpatialIndex() to happen before anything else each timestep.
> >
> > Sean
> >
> >
> >
> >
> > --
> > [log in to unmask]
> >
> 
> 
> 
> -- 
> [log in to unmask]
> 

ATOM RSS1 RSS2