repast-developer

Re: [Repast-developer] DisplaySurface bug

[Mark R. D. <mdi...@la...>]

Done. Thanks for the fix.

-Mark

Vos, Jerry R. wrote:
> If a key listener is added to the Display Surface before the frame is 
> created (before it is displayed) there is no way to remove that listen=
er 
> until after the frame is created.  addKeyListener(=85) stores the 
> listeners until the surface is displayed, but removeKeyListener is not=
 
> overridden to remove key listeners from the stored list.
> 
> For instance:
> 
>  
> 
> DisplaySurface foo =3D new DisplaySurface(=85);
> 
> foo.addKeyListener(new KeyAdapter());
> 
>  
> 
> There=92s no way to remove that listener until after foo.display();
> 
>  
> 
> Fix:
> 
> *public* *void* removeKeyListener(KeyListener listener) {
> 
>       *if* (frame !=3D *null*)
> 
>         frame.removeKeyListener(listener);
> 
>       *else*
> 
>         keyListeners.remove(listener);
> 
> }
> 

[Repast-developer] DisplaySurface bug

[Vos, J. R. <jv...@an...>]

If a key listener is added to the Display Surface before the frame is
created (before it is displayed) there is no way to remove that listener
until after the frame is created.  addKeyListener(...) stores the
listeners until the surface is displayed, but removeKeyListener is not
overridden to remove key listeners from the stored list.

For instance:

=20

DisplaySurface foo =3D new DisplaySurface(...);

foo.addKeyListener(new KeyAdapter());

=20

There's no way to remove that listener until after foo.display();

=20

Fix:

public void removeKeyListener(KeyListener listener) {

      if (frame !=3D null)

        frame.removeKeyListener(listener);

      else

        keyListeners.remove(listener);

}

Re: [Repast-developer] RePast and extensibity

[Kelly P. <kel...@ya...>]

The issue is important and because of its potential impact people should take the time to think and express their opinions. Although a newcomer to RePast here is mine.
 
Separating appearance from behavior may be a first step towards defining a "plugability" layer. 
G1. I would personally like to see the objects/agents "registering" with a display server (this would for example allow to zoom on a certain region of the space).
G2. A flexible way of mapping agent features onto graphics objects (this may include mapping a cellular 2 or 3D space onto a different representation space) that are visible on the interface layer
G3. Implement (for a starter) point 1 and 2 of Mark's Repast <--> Platform X interface
 
The same method may be applied to creating a data collection interface. The "observability" layer.
O1. On the one hand various objects/agents can "register" with supplying certain information into the "observability" interface
O2. On the other hand the user may plug in methods of processing (of data) into the "O" layer
O3. Plug the output of O2 into a data collection graphical representation G1-G2 to end up with a (graphical) representation of the collected data.
 
Kelly

"Mark R. Diggory" <mdi...@la...> wrote:
I'm curious what others think about RePast in relation providing support 
for features such as Java3D and Geotools. I think we start to really 
reach an unrealistic limit in terms of packaging all this functionality 
directly into RePast as one monlithic project. It also becomes 
questionable as to whether RePast gets added to GeoTools (or any other 
Platform) or the other way around during this extension process.

Maybe it would be wise to begin a goal of defining a "plugability" layer 
for RePast such that the "core" features of RePast can be isolated from 
the "extensions". This way one can either use the "bare-bones" of 
RePast in thier project without having to drag along all the features 
they may not actually be interested in, or they can provide an extension 
to RePast itself if it is acting as the framework.

Mostly, these extensions tend to be isolated in the area of rendering. 
But they do also involve mapping between various datastructures in both 
RePAst and the Framework of question. It would be logical to consider in 
the future that plugging RePAst into "X" platform will involve providing 
"Graphical" and "Nongraphical" bindings to and from that framework.


RePast Platform X


1.) Implementatation of RePast space, graph or topology interfaces in 
external API's for execution from within RePast.

RePast Interfaces <-- Platform X Data Structures

2.) Mapping model data structures to an external rendering engine.

RePast Model Data Structures --> Platform X Rendering Engine

3.) Exposing model controls and properties to external platform.

RePast Model Properties/Controls <-- Platform X

As we are starting to do to more of this "extension" these days. It 
would be wise to begin such discussions while the interest is there. 
This can happen at a couple of levels both internally to RePast with its 
own displays/controls and external to RePast in relation to GeoTools and 
other platforms that we are interested in "interfacing" with RePast.

-Mark




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Repast-developer mailing list
Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

[Repast-developer] RePast and extensibity

[Mark R. D. <mdi...@la...>]

I'm curious what others think about RePast in relation providing support 
for features such as Java3D and Geotools. I think we start to really 
reach an unrealistic limit in terms of packaging all this functionality 
directly into RePast as one monlithic project. It also becomes 
questionable as to whether RePast gets added to GeoTools (or any other 
Platform) or the other way around during this extension process.

Maybe it would be wise to begin a goal of defining a "plugability" layer 
for RePast such that the "core" features of RePast can be isolated from 
the "extensions".  This way one can either use the "bare-bones" of 
RePast in thier project without having to drag along all the features 
they may not actually be interested in, or they can provide an extension 
to RePast itself if it is acting as the framework.

Mostly, these extensions tend to be isolated in the area of rendering. 
But they do also involve mapping between various datastructures in both 
RePAst and the Framework of question. It would be logical to consider in 
the future that plugging RePAst into "X" platform will involve providing 
"Graphical" and "Nongraphical" bindings to and from that framework.


      RePast                             Platform X


1.) Implementatation of RePast space, graph or topology interfaces in 
external API's for execution from within RePast.

RePast Interfaces <-- Platform X Data Structures

2.) Mapping model data structures to an external rendering engine.

RePast Model Data Structures --> Platform X Rendering Engine

3.) Exposing model controls and properties to external platform.

RePast Model Properties/Controls <-- Platform X

As we are starting to do to more of this "extension" these days. It 
would be wise to begin such discussions while the interest is there. 
This can happen at a couple of levels both internally to RePast with its 
own displays/controls and external to RePast in relation to GeoTools and 
other platforms that we are interested in "interfacing" with RePast.

-Mark

Re: [Repast-developer] 3d models in Repast

[Phil F. <pfe...@co...>]

>
> I don't think I will get that detailed when it comes to rendering, I 
> think initially it should be kept to simple polygons that fit in the 
> grid structure, like in 2D with some similar support like 
> SimGraphics.drawFastCircle()...
>
> This way we can start with some simple rendering support and expand 
> from there, but still keep the presentation separate from the data 
> model. Issues such as collision avoidance an animation are probably 
> more advanced features that I would not necessarily want the display 
> engine to handle because theres too much of a mix between model and 
> presentation if one uses them. 

The way I dealt with that and also leave room for additional development 
was to have a "Drawable3D" base class that knew how to draw itself as a 
sphere. That class was extended to become Agent3D base classes. All the 
graphics functionality was contained in the createSceneGraph() method in 
the Drawable3D class, so you could either forget about it and have 
reasonable graphics that could be easily swapped out for the next API 
(as long as "Scene Graph" makes sense), or overload in your agent class 
for all the nifty graphics. That part seems to have worked out pretty well.

>
>
> For example, If one were to write a 2D model, lets say it had 
> individual agents that grew over time to acquire more "grid" locations 
> on an Object2DGrid, then the control over if two agents are occupying 
> the same grid location would be programmed into the model itself and 
> not really be the responsibility of the Object2DDisplay to control. I 
> think grids give us a simple starting point for working with this sort 
> of behavior in 3D as well. 

It does, but you may find yourself limited in the long run. One of the 
advantages of 3D is the ability to portray much more complex scenes that 
have object interaction playing an important role. This could be an 
agent moving across a surface that it interrogates, or running along a 
link that connects two nodes on a network. One of the projects I'm 
working on now is modeling an autonomous vehicle with a laser 
rangefinder. The entire vehicle is a hierarchical arrangement of agents, 
LIDAR, turret, transmission, motor, even the terrain. And this is built 
on the same base classes that I use to model epidemics in populations. 
That would have been tougher to do if the rendering geometry had been 
isolated from the simulation geometry.

Anyway, that's my $0.02 :-)

Good luck!

Phil

>

Re: [Repast-developer] bug in RasterSpace

[Mark R. D. <mdi...@la...>]

I fixed it in the CVS tree. Thanks.

Ian Turton wrote:

> The constructor for RasterSpace shown below,
> public RasterSpace(double left, double bottom, double right, double top, 
> double cellSize, int w, int h) {
>         this.cellSize = cellSize;
>         originx = left;
>         originy = bottom;
>         termx = right;
>         termy = top;
>         height = h;
>         width = w;
>     }
> 
> 
> needs to have
>     matrix = new DoubleMatrix(h, w);
> added at the end.
> 
> Ian
> Ian Turton, Director, Centre for Computational Geography, University of 
> Leeds, Leeds, LS2 9JT
> http://www.geog.leeds.ac.uk/people/i.turton http://www.ccg.leeds.ac.uk 
> http://www.geotools.org
> +44 (0) 113 343 3392 fax: +44 (0) 113 343 3308
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] 3d models in Repast

[Mark R. D. <mdi...@la...>]

Phil Feldman wrote:
> Hi Mark,
> 
> Here's the code for DisplaySurface3D. Let me know what questions you have.
> 

I'll take a look at it this evening, thanks!

> Initially, I also wanted to separate appearance from behavior, but it 
> really got too difficult. Imagine an agent that can walk and move its 
> limbs, with collision detection and response for all surfaces. The 
> geometry and the behavior are so tied together that separating them 
> would entail a massive data channel between them, at which point you've 
> negated the advantage.

I don't think I will get that detailed when it comes to rendering, I 
think initially it should be kept to simple polygons that fit in the 
grid structure, like in 2D with some similar support like 
SimGraphics.drawFastCircle()...

This way we can start with some simple rendering support and expand from 
there, but still keep the presentation separate from the data model. 
Issues such as collision avoidance an animation are probably more 
advanced features that I would not necessarily want the display engine 
to handle because theres too much of a mix between model and 
presentation if one uses them.

For example, If one were to write a 2D model, lets say it had individual 
agents that grew over time to acquire more "grid" locations on an 
Object2DGrid, then the control over if two agents are occupying the same 
grid location would be programmed into the model itself and not really 
be the responsibility of the Object2DDisplay to control. I think grids 
give us a simple starting point for working with this sort of behavior 
in 3D as well.

> 
> BTW, it appears that Java3D will not be supported (or at least not 
> actively developed) by Sun in the future, so I'd reccomend implementing 
> on some other platform.
 >
 > Regards,
 >
 > Phil Feldman
 >

This is the benefit of keeping the Data Model and the Presentation 
separate, depending on the technology that become "prevalent" in the 
future, there will be room to expand the visualization onto that 
platform without having to "rewrite" any particular model 
implementations themselves.

With this in mind, working with Java3D is still ok even if Sun's scaling 
down its development (note, Sun also scaled down its development of JNDI 
and LDAP after its initial development, yet these are still prevalent 
packages that get allot of use). I'm sure if other 3D technologies arise 
for java that there will be discussion in the community in relation to 
migrating from Java3D to such technologies.

Cheers,
Mark

>> I would be interested in seeing how you've built the (DisplaySurface) 
>> rendering of your vector of objects in 3D. When it boils down to it, 
>> even when rendering 2D grids, the optimized way of doing it is to 
>> iterate over the ArrayList of Agents. We would apply the same strategy 
>> in 3d, only the Display engine would be the 3D scene graph instead of 
>> the 2D DisplaySurface
>>
>> From my understanding of Java 3D theres considerable work to implement 
>> it on top of graphics acceleration on many different platforms:
>> http://www.j3d.org/download.html
>>
>> I've seen it run quite efficiently on a project that provides Java 
>> based 3D visualization of Complex Protien Molecules:
>> http://mbt.sdsc.edu/
>>
>> I've been extending my topology.space library to also support 3D 
>> spaces as grids. Alot of work still needs to get done in separating 
>> the displays "presentation" from the Data Model when it comes to 
>> displaying objects/grids of objects in both 2D and 3D.
>>
>> Unfortunately, the old space/display library approaches rendering by 
>> mixing the presentation and data objects at the "Agent" level, this 
>> means that agents are both "Data Objects" and "Display Objects" for 
>> the 2D DisplaySurface. This is problematic when using different 
>> implementations for display rendering 2D, 3D, various GIS tools, etc).
>>
>> Our future intent it to separate the objects data and presentation 
>> aspects so that the "presentation" of the object is not encapsulated 
>> in the same class as the object itself. This way the object may hold 
>> the information about its position, but the DisplaySurface/Volumn will 
>> manage the presentation aspects separately via some sort of 
>> "stylesheet" strategy.
>>
>> -Mark
>>
>> Phil Feldman wrote:
>>
>>> For my stuff, I worked entirely in VectorSpace. Basically, I create a 
>>> pile of objects and build a java3d scene graph out of them. Then it's 
>>> a matter of moving things about. For a DescreteSpace (cell-based) 
>>> system, it might make sense to look at volume rendering, since each 
>>> texel could cerrespond to a cell. The problem is that I'm not sure if 
>>> it's yet possible to update a 3D texture in real time on anything 
>>> other than an SGI. There-s a lot of memory to move. Isosurfaces could 
>>> also work, but you'd have to avoid the scene graph. SGI and SUN are 
>>> coming out with "OEM" java bindings to openGL, so that might be the 
>>> way to go.
>>>
>>> Phil Feldman
>>>
>>>> I suspect it would be fun for us to explore the future of 
>>>> Object3DSpaces for our new topology.space library we've been 
>>>> building too. with the establishment of a Spaces methods only 
>>>> accepting/returning "Locations" instead of x/y coordinates, this 
>>>> would free us up to make > 2 dimensional spaces without being 
>>>> restricted by the interfaces.
>>>>
>>>>
>>>> interface DiscreteSpace {
>>>>
>>>>   public Location removeLocation(Location loc);
>>>>
>>>>   public Location getLocation(Location loc);
>>>>
>>>>   public void removeObjectAt(Object obj, Location loc);
>>>>
>>>>   public void putObjectAt(Object obj, Location loc);
>>>>
>>>>   public void getObjectAt(Location loc);
>>>>
>>>> }
>>>>
>>>> class Discrete2DSpace implements DiscreteSpace {
>>>>
>>>>   ...
>>>>
>>>> }
>>>>
>>>> class Discrete3DSpace implements DiscreteSpace {
>>>>
>>>>   ...
>>>>
>>>> }
>>>>
>>>> class Object2DLocation implements Location{
>>>>
>>>>   public int getX(){
>>>>    ...
>>>>   }
>>>>
>>>>   public int getY(){
>>>>    ...
>>>>   }
>>>>
>>>> }
>>>>
>>>>
>>>> class Object3DLocation extends Object2DLocation{
>>>>
>>>>   public int getZ(){
>>>>    ...
>>>>   }
>>>>
>>>> }
>>>>
>>>> I imagine it would be interesting to have Different "Display 
>>>> Surfaces" for the space, imagine "top", "side", "front", "isometric" 
>>>> and "3D adjustable" Displays, the 2D (top, side, front) Could easily 
>>>> be superimposed on a 2D DisplaySurface while a 3D display surface 
>>>> would need to be created for isometric and adjustable 3D Displays.
>>>>
>>>> -Mark
>>>>
>>>>
>>>> Phil Feldman wrote:
>>>>
>>>>> I've been doing a lot of work in that area for the past year or so. 
>>>>> It's not quite ready for prime time, but I may be able to help you 
>>>>> out a bit.
>>>>>
>>>>> Phil Feldman
>>>>>
>>>>>> Has anyone done any work on 3d-space models (like Heatbugs in 
>>>>>> 3d-space) in Repast or anyone planning on it ?  Like with Java3D ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>>>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>>>>
>>>>> _______________________________________________
>>>>> Repast-developer mailing list
>>>>> Rep...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>>>
>>>> _______________________________________________
>>>> Repast-developer mailing list
>>>> Rep...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>>
>>> _______________________________________________
>>> Repast-developer mailing list
>>> Rep...@li...
>>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>
>> _______________________________________________
>> Repast-developer mailing list
>> Rep...@li...
>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
> 
> 
> ------------------------------------------------------------------------
> 
> package edu.umd.geographs;
> 
> import javax.swing.*;
> import java.awt.*;
> import java.io.*;
> import java.awt.event.*;
> import java.lang.reflect.*;
> import java.util.ArrayList;
> import java.util.Hashtable;
> 
> import javax.media.j3d.*;
> import javax.vecmath.*;
> 
> //import com.sun.j3d.utils.geometry.*;
> import com.sun.j3d.utils.universe.*;
> import com.sun.j3d.utils.image.*;
> import com.sun.j3d.utils.picking.*;
> import com.sun.j3d.utils.geometry.*;
> 
> import uchicago.src.sim.space.VectorSpace;
> import uchicago.src.sim.util.*;
> import uchicago.src.sim.gui.Named;
> import uchicago.src.sim.engine.CustomProbeable;
> import uchicago.src.sim.engine.SimEvent;
> import uchicago.src.sim.engine.SimEventListener;
> import uchicago.src.reflector.DescriptorContainer;
> 
> 
> public class DisplaySurface3D 
> 	extends JFrame 
> 	implements SimEventListener, ItemListener
> {
> 	private String name = null;
> 	private JMenu menu = new JMenu("Options");
> 	private JButton flyDragButton = new JButton("Dragging");
> 	private JButton freezeThawButton = new JButton("Thawed");
> 	private Point location = new Point (0, 0);
> 	private SimpleUniverse u = null;
> 	private Canvas3D canvas;
> 	private double rotVal = 0.0;
> 	private	BranchGroup rootBG = null;
> 	private TransformGroup rootTG;
> 	private TransformGroup viewerRootTG;
> 	private Xform xform = new Xform();
> 	private ScrollingMouseData flyMouse;
> 	private ArrayList toRender = new ArrayList();
> 	private float stepbackDist = 25.0f;
> 	private boolean surfViewable = true;
> 	private boolean isFrozen = false;
> 	private int mouseX = 0;
> 	private int mouseY = 0;
> 	private int index = 0;
> 	private int indent = 0;
> 	private PickCanvas pickCanvas;
> 	private final int BEST_AGENTS = 0;
> 	private final int FASTEST_AGENTS = 1;
> 	private final int NO_AGENTS = 2;
> 	private final int BEST_NODES = 3;
> 	private final int FASTEST_NODES = 4;
> 	private final int NO_NODES = 5;
> 	//private DUpdate du = new DUpdate();
> 
> 	private WindowAdapter dsWindowAdapter = new WindowAdapter() 
> 	{
> 		public void windowIconified(WindowEvent evt) {
> 			surfViewable = false;
> 		}
> 
> 		public void windowDeiconified(WindowEvent evt) {
> 			surfViewable = true;
> 		}
> 
> 		public void windowClosing (WindowEvent evt) {
> 			//f.removeWindowListener (this);
> 			System.out.println("windowClosing "+evt);
> 			removeWindowListener (this);
> 			dispose ();
> 			System.exit (0);
> 		}
> 
> 		public void windowClosed (WindowEvent evt) {
> 			//System.out.println("windowClosed "+evt);
> 		}
> 		public void windowDeactivated (WindowEvent evt) {
> 			//System.out.println("windowDeactivated ");
> 		}
> 		public void windowStateChanged (WindowEvent evt) {
> 			//System.out.println("windowStateChanged "+evt);
> 		}
> 	}; 
> 
> 	private MouseMotionAdapter dsMouseMotionAdapter = new MouseMotionAdapter()
> 	{
> 		public void mouseDragged(MouseEvent e)
> 		{
> 			//System.out.println("mouseDragged");
> 			flyMouse.updateDeltas(e.getX(), e.getY());
> 		}
> 	};
> 
> 	private MouseAdapter dsMouseAdapter = new MouseAdapter()
> 	{
> 		public void mousePressed(MouseEvent e)
> 		{
> 			int mods = e.getModifiers();
> 			if((mods & InputEvent.BUTTON1_MASK) != 0)
> 				flyMouse.setIsRotating(true); // rotate
> 			else if((mods & InputEvent.BUTTON3_MASK) != 0)
> 				flyMouse.setIsRotating(false); // translate
> 			flyMouse.setOldXY(e.getX(), e.getY());
> 		}
> 		public void mouseReleased(MouseEvent e)
> 		{
> 			flyMouse.reset();
> 		}
> 		public void mouseClicked(MouseEvent e)
> 		{
> 			pickCanvas.setShapeLocation(e.getX(), e.getY());
> 			PickResult[] results = pickCanvas.pickAll();
> 			examinePickResults(results);
> 		}
> 	};
> 
> 	class DUpdate implements Runnable
> 	{
> 		public void run()
> 		{
> 			paint();
> 		}
> 	};
> 
> 
> 	public DisplaySurface3D()
> 	{
> 		this("Untitled");
> 	}
> 
> 	public DisplaySurface3D(String name)
> 	{
> 		super(name);
> 		this.name = name;
> 	}
> 	
> 	public void addDisplayabe3D(Drawable3D d)
> 	{
> 		if(d instanceof Drawable3D)
> 			toRender.add(d);
> 	}
> 
> 
> 	private void setVisibleFlag(int type)
> 	{
> 		System.out.println("setVisibleFlag = "+type);
> 		for(int i = 0; i < toRender.size(); i++)
> 		{
> 			if(toRender.get(i) instanceof Node3D)
> 			{
> 				//System.out.println("instanceof Node3D");
> 				Node3D d = (Node3D)toRender.get(i);
> 				if(type == BEST_NODES) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_BEST);
> 					d.switchRenderNode(Drawable3D.GR_BEST);
> 				}
> 				else if(type == FASTEST_NODES) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_FASTEST);
> 					d.switchRenderNode(Drawable3D.GR_FASTEST);
> 				}
> 				else if(type == NO_NODES) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_OFF);
> 					d.switchRenderNode(Drawable3D.GR_OFF);
> 				}
> 			}
> 			else if(toRender.get(i) instanceof Agent3D)
> 			{
> 				Agent3D d = (Agent3D)toRender.get(i);
> 				if(type == BEST_AGENTS) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_BEST);
> 					d.switchRenderNode(Drawable3D.GR_BEST);
> 				}
> 				else if(type == FASTEST_AGENTS) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_FASTEST);
> 					d.switchRenderNode(Drawable3D.GR_FASTEST);
> 				}
> 				else if(type == NO_AGENTS) 
> 				{
> 					d.setDesiredGraphicsStyle(Drawable3D.GR_OFF);
> 					d.switchRenderNode(Drawable3D.GR_OFF);
> 				}
> 			}
> 		}
> 	}
> 
> 	public void itemStateChanged(ItemEvent e)
> 	{
> 		//System.out.println(e.paramString());
> 		String s = (String)e.getItem();
> 		if(e.getStateChange() == ItemEvent.SELECTED)
> 		{
> 			System.out.println(s+" selected");
> 			if(s.equals("Best Agents"))
> 				setVisibleFlag(BEST_AGENTS);
> 			else if(s.equals("Fastest Agents"))
> 				setVisibleFlag(FASTEST_AGENTS);
> 			else if(s.equals("No Agents"))
> 				setVisibleFlag(NO_AGENTS);
> 			else if(s.equals("Best Nodes"))
> 				setVisibleFlag(BEST_NODES);
> 			else if(s.equals("Fastest Nodes"))
> 				setVisibleFlag(FASTEST_NODES);
> 			else if(s.equals("No Nodes"))
> 				setVisibleFlag(NO_NODES);
> 		}
> 	}
> 
> 	public void simEventPerformed(SimEvent evt)
> 	{
> 		int id = evt.getId();
> 		//System.out.println("surface got a SimEvent. ID = " + id);
> 		if(id == SimEvent.STOP_EVENT)
> 		{
> 			try{
> 				//System.out.println("saving mouse position");
> 				//flyMouse.dump();
> 				FileOutputStream out = new FileOutputStream("flyMousePos");
> 				ObjectOutputStream s = new ObjectOutputStream(out);
> 				s.writeObject(flyMouse);
> 				s.flush();
> 			} 
> 			catch (Exception e)
> 			{
> 				//System.out.println("Unable to serialize flyMousePos: "+e);
> 			}
> 		}
> 	}
> 
> 	public void addVectorSpace(VectorSpace vs)
> 	{
> 		// Go through the VectorSpace's members, see if they are Drawables,
> 		// and if they are, then add them to the toRender list
> 		ArrayList l = vs.getMembers();
> 		for(int i = 0; i < l.size(); i++)
> 		{
> 			if(l.get(i) instanceof Drawable3D)
> 				toRender.add(l.get(i));
> 		}
> 	}
> 
> 	public void setStepBack(float val)
> 	{
> 		stepbackDist = val;
> 	}
> 
> 	public boolean isRunning()
> 	{
> 		return (!isFrozen);
> 	}
> 
> 	public boolean isFrozen()
> 	{
> 		return isFrozen;
> 	}
> 
> 	public boolean isShowing()
> 	{
> 		return surfViewable;
> 	}
> 
> 	public void hide()
> 	{
> 		super.hide();
> 		surfViewable = false;
> 	}
> 
> 	// Creates the 3D display, and for now also loads the scene graph. 
> 	// That part may have to be broken out.
> 	public void display()
> 	{
> 		JPanel jp = new JPanel();
> 		jp.setVisible(true);
> 		jp.setLayout(new BorderLayout());
> 
> 		GraphicsConfiguration config = 
> 			SimpleUniverse.getPreferredConfiguration();
> 		canvas = new Canvas3D(config);
> 
> 		jp.add("Center", canvas);
> 
> 		try
> 		{
> 			rootBG = createSceneGraph();
> 		}
> 		catch (FileNotFoundException e)
> 		{
> 			System.out.println(e);
> 			System.exit(-1);
> 		}
> 		//rootBG.compile();
> 
> 		u = new SimpleUniverse(canvas);
> 		ViewingPlatform vp = u.getViewingPlatform();
> 		viewerRootTG = vp.getViewPlatformTransform();
> 		Viewer viewer = u.getViewer();
> 		View view = viewer.getView();
> 		view.setBackClipDistance(100.0);
> 		u.addBranchGraph(rootBG);
> 		pickCanvas = new PickCanvas(canvas, rootBG);
> 		pickCanvas.setMode(PickTool.BOUNDS);
> 		pickCanvas.setTolerance(4.0f);
> 
> 		setLocation(new Point(10,10));
> 		setSize(new Dimension(600,500));
> 		getContentPane().setLayout(new BorderLayout());
> 		getContentPane().add(jp, BorderLayout.CENTER);
> 		addWindowListener (dsWindowAdapter);
> 
> 		// make a dropdown menu to support multiple views
> 		String[] views =
> 		{
> 			"home view",
> 			"3/4 view",
> 			"top view"
> 		};
> 		final JComboBox viewBox = new JComboBox(views);
> 		viewBox.setBorder(BorderFactory.createTitledBorder("Viewing angle"));
> 		viewBox.addActionListener(new ActionListener(){
> 			public void actionPerformed(ActionEvent e)
> 			{
> 				flyMouse.setIsDragging(true);
> 				flyDragButton.setActionCommand("fly");
> 				flyDragButton.setText("Dragging");
> 				flyMouse.setNumberedView(viewBox.getSelectedIndex());
> 				viewerRootTG.setTransform(flyMouse.getFlyTransform());
> 			}
> 		});
> 
> 		String[] visibleList =
> 		{
> 			"Fastest Agents",
> 			"Best Agents",
> 			"No Agents",
> 			"Fastest Nodes",
> 			"Best Nodes",
> 			"No Nodes",
> 		};
> 		final JComboBox visibleListBox = new JComboBox(visibleList);
> 		visibleListBox.setBorder(
> 				BorderFactory.createTitledBorder("Visibility"));
> 		visibleListBox.addItemListener(this);
> 
> 			
> 
> 		JPanel sidePanel = new JPanel();
> 		getContentPane().add(sidePanel,BorderLayout.WEST);
> 
> 		JPanel buttonPanel = new JPanel();
> 		buttonPanel.setLayout(new GridLayout(6, 1));
> 		buttonPanel.add(viewBox);
> 		buttonPanel.add(flyDragButton);
> 		buttonPanel.add(freezeThawButton);
> 		buttonPanel.add(visibleListBox);
> 		sidePanel.add(buttonPanel);
> 		setVisible (true);
> 
> 		canvas.addMouseListener(dsMouseAdapter);
>     	canvas.addMouseMotionListener(dsMouseMotionAdapter);
> 
> 		flyDragButton.addActionListener(new ActionListener(){
> 			public void actionPerformed(ActionEvent e)
> 			{
> 				if(e.getActionCommand().equals("fly"))
> 				{
> 					flyMouse.setIsDragging(false);
> 					flyDragButton.setActionCommand("drag");
> 					flyDragButton.setText("Flying");
> 				}
> 				if(e.getActionCommand().equals("drag"))
> 				{
> 					flyMouse.setIsDragging(true);
> 					flyDragButton.setActionCommand("fly");
> 					flyDragButton.setText("Dragging");
> 				}
> 			}
> 		});
> 
> 		freezeThawButton.addActionListener(new ActionListener(){
> 			public void actionPerformed(ActionEvent e)
> 			{
> 				if(e.getActionCommand().equals("freeze"))
> 				{
> 					freezeThawButton.setActionCommand("thaw");
> 					freezeThawButton.setText("Frozen");
> 					isFrozen = true;
> 				}
> 				if(e.getActionCommand().equals("thaw"))
> 				{
> 					freezeThawButton.setActionCommand("freeze");
> 					freezeThawButton.setText("Thawed");
> 					isFrozen = false;
> 				}
> 			}
> 		});
> 
> 
> 		// set up the initial viewpoint
> 		try{
> 			FileInputStream in = new FileInputStream("flyMousePos");
> 			ObjectInputStream s = new ObjectInputStream(in);
> 			flyMouse = (ScrollingMouseData)s.readObject();
> 			//System.out.println("Restoring mouse position");
> 			//flyMouse.dump();
> 		}
> 		catch (Exception e)
> 		{
> 			flyMouse = new ScrollingMouseData(10.0f);
> 			flyMouse.setIsDragging(false);
> 			flyMouse.stepBack(stepbackDist);
> 			flyMouse.setIsDragging(true);
> 			//System.out.println("Initializing new mouse position: "+e);
> 		}
> 		viewerRootTG.setTransform(flyMouse.getFlyTransform());
> 		flyDragButton.setActionCommand("fly");
> 
> 		freezeThawButton.setActionCommand("freeze");
> 	}
> 
> 	// look through an array of PickResults to find an simulation
> 	// object. Basically, this means that we look for a scene graph node
> 	// that has an InfoObject embedded in its userData
> 	private void examinePickResults(PickResult[] results)
> 	{
> 		if(results != null)
> 		{
> 			boolean foundIt = false;
> 			for(int i = 0; i < results.length; i++)
> 			{
> 				// SceneGraphPaths have less irrelevant information than
> 				// PickResult, so just get that
> 				SceneGraphPath path = results[i].getSceneGraphPath();
> 				if(path != null)
> 				{
> 					// if there are more than one nodes in the branch we're 
> 					// looking at, then it's probable that the node we're 
> 					// interested in is the 0th node. NOTE!! This needs to
> 					// be rechecked as we start working with more sophisticated
> 					// loaders
> 					//System.out.println(path.toString());
> 					Node n = null;
> 					if(path.nodeCount() > 0)
> 					{
> 						for(int j = 0; j < path.nodeCount(); j++)
> 							if(checkUserData(path.getNode(j)))
> 							{
> 								foundIt = true;
> 								break;
> 							}
> 					}
> 					else
> 					{
> 						foundIt = checkUserData(path.getObject());
> 					}
> 				}
> 				if(foundIt)
> 					break;
> 			}
> 		}
> 	}
> 
> 	private boolean checkUserData(Node n)
> 	{
> 		if(n != null)
> 		{
> 			// Open up a data window as in a RePast Probable object
> 			//System.out.println("Node = " + n.toString());
> 			ObjectInfo info = (ObjectInfo)n.getUserData();
> 			if(info != null)
> 			{
> 				//System.out.println("\tInfo = " + info.toString());
> 				ProbeUtilities.probe(info);
> 				return true;
> 			}
> 		}
> 		return false;
> 	}
> 
> 
> 	private void paint()
> 	{
> 		if(flyMouse.isDragging())
> 		{
> 			rootTG.setTransform(flyMouse.transRot());
> 		}
> 		else // flying
> 		{
> 			viewerRootTG.setTransform(flyMouse.getFlyTransform());
> 		}
> 	}
> 
> 	public void updateDisplay()
> 	{
> 		updateDisplayDirect();
> 		/***
> 		try
> 		{
> 			SwingUtilities.invokeAndWait(du);
> 		}
> 		catch(InterruptedException e)
> 		{
> 			// keep interuppting until the thread that called this method
> 			// i.e. BaseControler.runThread terminates. When that terminates
> 			// we are okay.   
> 			Thread.currentThread().interrupt();
> 		}
> 		catch (InvocationTargetException e)
> 		{
> 			e.printStackTrace();
> 		}
> 		***/
> 	}
> 
> 	public void updateDisplayDirect()
> 	{
> 		paint();
> 
> 	}
> 
> 	public void dispose()
> 	{
> 		System.out.println("Disposing");
> 
> 		// Remove all the components from this container
> 		removeAll();
> 
> 		// kill the components
> 		canvas.removeMouseListener(dsMouseAdapter);
>     	canvas.removeMouseMotionListener(dsMouseMotionAdapter);
> 		menu = null;
> 		flyDragButton = null;
> 		freezeThawButton = null;
> 		flyMouse = null;
> 		pickCanvas = null;
> 		canvas = null;
> 		rootBG = null;
> 		rootTG = null;
> 		viewerRootTG = null;
> 		for(int i = 0; i < toRender.size(); i++)
> 		{
> 			Object o = toRender.get(i);
> 			o = null;
> 		}
> 		toRender = null;
> 		u.removeAllLocales();
> 		u = null;
> 		removeWindowListener(dsWindowAdapter);
> 		// serialize the viewpoint information
> 		//f.dispose();
> 		super.dispose();
> 	}
> 
> 	public BranchGroup createSceneGraph() 
> 		throws FileNotFoundException
> 	{
> 		BranchGroup rootBG = new BranchGroup();
> 		rootTG = new TransformGroup();
> 		
> 		// Add all the renderable elements to the scene graph
> 		for(int i = 0; i < toRender.size(); i++)
> 		{
> 			Drawable3D d = (Drawable3D)toRender.get(i);
> 			BranchGroup bg = d.getBG();
> 			rootTG.addChild(bg);
> 		}
> 		rootTG.setCapability(TransformGroup.ALLOW_TRANSFORM_WRITE);
> 
> 		rootBG.addChild(rootTG);
> 
>    		// make lights
>     	Color3f light1Color = new Color3f(1f, 1f, 1f);
>     	// lights need a bounding sphere to know when to turn on
> 		BoundingSphere bounds = 
> 			new BoundingSphere(new Point3d(0.0,0.0,0.0), 100.0);
> 		Vector3f light1Direction = new Vector3f(4.0f, -7.0f, -12.0f);
> 		DirectionalLight light1 = 
> 			new DirectionalLight(light1Color, light1Direction);
> 		light1.setInfluencingBounds(bounds);
> 		
> 		rootBG.addChild(light1);
> 		
> 		AmbientLight ambientLight = new AmbientLight(new Color3f(.5f,.5f,.5f));
> 		ambientLight.setInfluencingBounds(bounds);
> 		rootBG.addChild(ambientLight);
> 
>         // Set up the background
>         Color3f bgColor = new Color3f(0.05f, 0.05f, 0.5f);
>         Background bgNode = new Background(bgColor);
>         bgNode.setApplicationBounds(bounds);
>         rootBG.addChild(bgNode);
> 
> 		rootBG.setCapability(RenderingAttributes.ALLOW_VISIBLE_READ);
> 		rootBG.setCapability(RenderingAttributes.ALLOW_VISIBLE_WRITE);
> 		rootBG.setCapability(Appearance.ALLOW_RENDERING_ATTRIBUTES_READ);
> 		rootBG.setCapability(Appearance.ALLOW_RENDERING_ATTRIBUTES_WRITE);
> 		rootBG.setCapability(RenderingAttributes.ALLOW_VISIBLE_READ);
> 		rootBG.setCapability(RenderingAttributes.ALLOW_VISIBLE_WRITE);
> 		rootBG.setCapability(Shape3D.ALLOW_APPEARANCE_READ);
> 		rootBG.setCapability(Shape3D.ALLOW_APPEARANCE_WRITE);
> 
> 		return rootBG;
> 	}
> }
> 

Re: [Repast-developer] bug in RasterSpace

[Mark R. D. <mdi...@la...>]

I also notice that the "parameterization of the constructors is rather 
inconsistent and could easily confuse a user and introduce undesired 
behavior

public RasterSpace(double top, double left, double cellSize, int h, int w) {
         ...
     }
public RasterSpace(double left, double bottom, double right, double top, 
double cellSize, int w, int h) {
	...
     }

when a constructor is has alot of

double, double, double, double, double, int, int ...

consistent ordering would be good to maintain

double top, double left, double cellSize,
double left, double bottom, double right, double top, double cellSize,

and

int w, int h
int h, int w

can be confusing, it would be better to have

int w, int h, double cellSize, double top, double left
int w, int h, double cellSize, double top, double left, double bottom, 
double right


-Mark

Ian Turton wrote:

> The constructor for RasterSpace shown below,
> public RasterSpace(double left, double bottom, double right, double top, 
> double cellSize, int w, int h) {
>         this.cellSize = cellSize;
>         originx = left;
>         originy = bottom;
>         termx = right;
>         termy = top;
>         height = h;
>         width = w;
>     }
> 
> 
> needs to have
>     matrix = new DoubleMatrix(h, w);
> added at the end.
> 
> Ian
> Ian Turton, Director, Centre for Computational Geography, University of 
> Leeds, Leeds, LS2 9JT
> http://www.geog.leeds.ac.uk/people/i.turton http://www.ccg.leeds.ac.uk 
> http://www.geotools.org
> +44 (0) 113 343 3392 fax: +44 (0) 113 343 3308
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] bug in RasterSpace

[Ian T. <ia...@ge...>]

The constructor for RasterSpace shown below,
public RasterSpace(double left, double bottom, double right, double top, 
double cellSize, int w, int h) {
         this.cellSize = cellSize;
         originx = left;
         originy = bottom;
         termx = right;
         termy = top;
         height = h;
         width = w;
     }


needs to have
	matrix = new DoubleMatrix(h, w);
added at the end.

Ian
Ian Turton, Director, Centre for Computational Geography, University of 
Leeds, Leeds, LS2 9JT
http://www.geog.leeds.ac.uk/people/i.turton http://www.ccg.leeds.ac.uk 
http://www.geotools.org
+44 (0) 113 343 3392 fax: +44 (0) 113 343 3308

Re: [Repast-developer] 3d models in Repast

[Mark R. D. <mdi...@la...>]

I would be interested in seeing how you've built the (DisplaySurface) 
rendering of your vector of objects in 3D. When it boils down to it, 
even when rendering 2D grids, the optimized way of doing it is to 
iterate over the ArrayList of Agents. We would apply the same strategy 
in 3d, only the Display engine would be the 3D scene graph instead of 
the 2D DisplaySurface

 From my understanding of Java 3D theres considerable work to implement 
it on top of graphics acceleration on many different platforms:
http://www.j3d.org/download.html

I've seen it run quite efficiently on a project that provides Java based 
3D visualization of Complex Protien Molecules:
http://mbt.sdsc.edu/

I've been extending my topology.space library to also support 3D spaces 
as grids. Alot of work still needs to get done in separating the 
displays "presentation" from the Data Model when it comes to displaying 
objects/grids of objects in both 2D and 3D.

Unfortunately, the old space/display library approaches rendering by 
mixing the presentation and data objects at the "Agent" level, this 
means that agents are both "Data Objects" and "Display Objects" for the 
2D DisplaySurface. This is problematic when using different 
implementations for display rendering 2D, 3D, various GIS tools, etc).

Our future intent it to separate the objects data and presentation 
aspects so that the "presentation" of the object is not encapsulated in 
the same class as the object itself. This way the object may hold the 
information about its position, but the DisplaySurface/Volumn will 
manage the presentation aspects separately via some sort of "stylesheet" 
strategy.

-Mark

Phil Feldman wrote:
> For my stuff, I worked entirely in VectorSpace. Basically, I create a 
> pile of objects and build a java3d scene graph out of them. Then it's a 
> matter of moving things about. For a DescreteSpace (cell-based) system, 
> it might make sense to look at volume rendering, since each texel could 
> cerrespond to a cell. The problem is that I'm not sure if it's yet 
> possible to update a 3D texture in real time on anything other than an 
> SGI. There-s a lot of memory to move. Isosurfaces could also work, but 
> you'd have to avoid the scene graph. SGI and SUN are coming out with 
> "OEM" java bindings to openGL, so that might be the way to go.
> 
> Phil Feldman
> 
>> I suspect it would be fun for us to explore the future of 
>> Object3DSpaces for our new topology.space library we've been building 
>> too. with the establishment of a Spaces methods only 
>> accepting/returning "Locations" instead of x/y coordinates, this would 
>> free us up to make > 2 dimensional spaces without being restricted by 
>> the interfaces.
>>
>>
>> interface DiscreteSpace {
>>
>>   public Location removeLocation(Location loc);
>>
>>   public Location getLocation(Location loc);
>>
>>   public void removeObjectAt(Object obj, Location loc);
>>
>>   public void putObjectAt(Object obj, Location loc);
>>
>>   public void getObjectAt(Location loc);
>>
>> }
>>
>> class Discrete2DSpace implements DiscreteSpace {
>>
>>   ...
>>
>> }
>>
>> class Discrete3DSpace implements DiscreteSpace {
>>
>>   ...
>>
>> }
>>
>> class Object2DLocation implements Location{
>>
>>   public int getX(){
>>    ...
>>   }
>>
>>   public int getY(){
>>    ...
>>   }
>>
>> }
>>
>>
>> class Object3DLocation extends Object2DLocation{
>>
>>   public int getZ(){
>>    ...
>>   }
>>
>> }
>>
>> I imagine it would be interesting to have Different "Display Surfaces" 
>> for the space, imagine "top", "side", "front", "isometric" and "3D 
>> adjustable" Displays, the 2D (top, side, front) Could easily be 
>> superimposed on a 2D DisplaySurface while a 3D display surface would 
>> need to be created for isometric and adjustable 3D Displays.
>>
>> -Mark
>>
>>
>> Phil Feldman wrote:
>>
>>> I've been doing a lot of work in that area for the past year or so. 
>>> It's not quite ready for prime time, but I may be able to help you 
>>> out a bit.
>>>
>>> Phil Feldman
>>>
>>>> Has anyone done any work on 3d-space models (like Heatbugs in 
>>>> 3d-space) in Repast or anyone planning on it ?  Like with Java3D ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>>
>>> _______________________________________________
>>> Repast-developer mailing list
>>> Rep...@li...
>>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>
>> _______________________________________________
>> Repast-developer mailing list
>> Rep...@li...
>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] 3d models in Repast

[Phil F. <pfe...@co...>]

For my stuff, I worked entirely in VectorSpace. Basically, I create a 
pile of objects and build a java3d scene graph out of them. Then it's a 
matter of moving things about. For a DescreteSpace (cell-based) system, 
it might make sense to look at volume rendering, since each texel could 
cerrespond to a cell. The problem is that I'm not sure if it's yet 
possible to update a 3D texture in real time on anything other than an 
SGI. There-s a lot of memory to move. Isosurfaces could also work, but 
you'd have to avoid the scene graph. SGI and SUN are coming out with 
"OEM" java bindings to openGL, so that might be the way to go.

Phil Feldman

> I suspect it would be fun for us to explore the future of 
> Object3DSpaces for our new topology.space library we've been building 
> too. with the establishment of a Spaces methods only 
> accepting/returning "Locations" instead of x/y coordinates, this would 
> free us up to make > 2 dimensional spaces without being restricted by 
> the interfaces.
>
>
> interface DiscreteSpace {
>
>   public Location removeLocation(Location loc);
>
>   public Location getLocation(Location loc);
>
>   public void removeObjectAt(Object obj, Location loc);
>
>   public void putObjectAt(Object obj, Location loc);
>
>   public void getObjectAt(Location loc);
>
> }
>
> class Discrete2DSpace implements DiscreteSpace {
>
>   ...
>
> }
>
> class Discrete3DSpace implements DiscreteSpace {
>
>   ...
>
> }
>
> class Object2DLocation implements Location{
>
>   public int getX(){
>    ...
>   }
>
>   public int getY(){
>    ...
>   }
>
> }
>
>
> class Object3DLocation extends Object2DLocation{
>
>   public int getZ(){
>    ...
>   }
>
> }
>
> I imagine it would be interesting to have Different "Display Surfaces" 
> for the space, imagine "top", "side", "front", "isometric" and "3D 
> adjustable" Displays, the 2D (top, side, front) Could easily be 
> superimposed on a 2D DisplaySurface while a 3D display surface would 
> need to be created for isometric and adjustable 3D Displays.
>
> -Mark
>
>
> Phil Feldman wrote:
>
>> I've been doing a lot of work in that area for the past year or so. 
>> It's not quite ready for prime time, but I may be able to help you 
>> out a bit.
>>
>> Phil Feldman
>>
>>> Has anyone done any work on 3d-space models (like Heatbugs in 
>>> 3d-space) in Repast or anyone planning on it ?  Like with Java3D ?
>>
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>
>> _______________________________________________
>> Repast-developer mailing list
>> Rep...@li...
>> https://lists.sourceforge.net/lists/listinfo/repast-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
>

Re: [Repast-developer] 3d models in Repast

[Mark R. D. <mdi...@la...>]

I suspect it would be fun for us to explore the future of Object3DSpaces 
for our new topology.space library we've been building too. with the 
establishment of a Spaces methods only accepting/returning "Locations" 
instead of x/y coordinates, this would free us up to make > 2 
dimensional spaces without being restricted by the interfaces.


interface DiscreteSpace {

   public Location removeLocation(Location loc);

   public Location getLocation(Location loc);

   public void removeObjectAt(Object obj, Location loc);

   public void putObjectAt(Object obj, Location loc);

   public void getObjectAt(Location loc);

}

class Discrete2DSpace implements DiscreteSpace {

   ...

}

class Discrete3DSpace implements DiscreteSpace {

   ...

}

class Object2DLocation implements Location{

   public int getX(){
    ...
   }

   public int getY(){
    ...
   }

}


class Object3DLocation extends Object2DLocation{

   public int getZ(){
    ...
   }

}

I imagine it would be interesting to have Different "Display Surfaces" 
for the space, imagine "top", "side", "front", "isometric" and "3D 
adjustable" Displays, the 2D (top, side, front) Could easily be 
superimposed on a 2D DisplaySurface while a 3D display surface would 
need to be created for isometric and adjustable 3D Displays.

-Mark


Phil Feldman wrote:

> I've been doing a lot of work in that area for the past year or so. It's 
> not quite ready for prime time, but I may be able to help you out a bit.
> 
> Phil Feldman
> 
>> Has anyone done any work on 3d-space models (like Heatbugs in 
>> 3d-space) in Repast or anyone planning on it ?  Like with Java3D ?
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] 3d models in Repast

[Phil F. <pfe...@co...>]

I've been doing a lot of work in that area for the past year or so. It's 
not quite ready for prime time, but I may be able to help you out a bit.

Phil Feldman

> Has anyone done any work on 3d-space models (like Heatbugs in 
> 3d-space) in Repast or anyone planning on it ?  Like with Java3D ?

[Repast-developer] 3d models in Repast

[Ted P. <phi...@ai...>]

Has anyone done any work on 3d-space models (like Heatbugs in 3d-space) =
in Repast or anyone planning on it ?  Like with Java3D ?

[Repast-developer] Bug in NetUtilities?

[Laszlo G. <gu...@la...>]

Hi,

I think I've found a bug in NetUtilities. More specifically, I think
randomRewire() messes up the internal structure of DefaultNodes.
What happens is that the collection returned by getOutNodes()
and the one resulting from calling getTo() on each member of
the list returned by getOutEdges() will be inconsistent. The
reason for this, I believe, is that the following lines in randomRewire()

           ((Node) nodes.get (j)).removeInEdge (edge);
           edge.setTo ((Node) nodeIndexer.get (newJ));
           ((Node) nodes.get (newJ)).addInEdge (edge);

should rather read as follows:

             ((Node) nodes.get (j)).removeInEdge (edge);
             ((Node) nodes.get (i)).removeOutEdge (edge);
             edge.setTo ((Node) nodeIndexer.get (newJ));
             ((Node) nodes.get (newJ)).addInEdge (edge);
             ((Node) nodes.get (i)).addOutEdge (edge);


A similar fix may be in order for randomRewireSymmetric(), too.

Regards,

-=- gulya

Types -- was (Re: [Repast-developer] Evolutionaries and Revolutionaries)

[Mark R. D. <mdi...@la...>]

Mark R. Diggory wrote:
> 
> Tom Howe wrote:
>> First off, we should just get rid of space2.  It was a
>> brief playground I was using.  

> I've been working your demo model package, replacing space2 with space 
> in it to see how well my changes work with your current strategy. It 
> almost works, accept for some of the "Type" issues I pointed out to in 
> my last email.

This issue is is something I'm struggling with at the moment. Maybe we 
should discuss the policy for defining "types" or "labels" for this 
particular subject.

1.) In some situations we'd really like to use things like

	context.getRelation(object, object, SomeTopology.type);

to have this capability requires that all Toppologies be separate 
classes and a Context can never contain two RelationalTopologies of the 
same class.

2.) If in some situations we may want to define two Topologies that are 
of the same class, then some other mechanism needs to be used:

RelationTopology.getRelationType();

and

RelationTopology.setRelationType("foo");

accomplish this task, but are fraught with risk of altering the 
Topologies type from that of the key its actually stored under in the 
Context mapping.

3.) I proposed that we possibly remove the setTopologyType from the 
interface and force all implementations to accept String arguments of 
assigning type in the constructors.

private String type;

public FooTopology(String type, ...){
    this.type = type;
}

public String getRelationType(){
    return type;
}

...

By this means types become more immutable over the lifetime of the object.

4.) The problem is that FooTopology.type is a simplified means of 
getting at the lookup key for a specific Topology in the Context. The 
ease of being able to do a static "SomeTopology.type" is nice. We still 
do not get this kind of capability. It is a "shot in the foot" to not 
have this kind of capability in "types" because otherwise you need to 
either keep track of the keys and know which your working with, or you 
need to keep track of the objects to know which one to get the 
"getRelationType()" content from to look it up in the Context.

As such I do not know what the best solution here at this point is. Do 
we want it to be the case that when a model writer is building a model 
that they extend all the classes to create a different Topology class 
for each Topology they want to map?

public class FooTopology extends Object2DGrid {
    public static final String type = "foo";
    ...
}

public class BarTopology extends Object2DGrid {
    public static final String type = "bar";
}

I'm not sure I like this idea either.


-Mark

Re: [Repast-developer] Context - Topology vs. Model - Graph

[Mark R. D. <mdi...@la...>]

Tom Howe wrote:
> I'm feel like the Topology needs to have an internal type as well as the
> context.  Here's why:
> 
> You have a Context called Workplace.  In this Context, there is a
> Reports-To topology,
> a gets-advice-from topology and a friends topology. (Apologies to
> Krackhardt).  But they all fall under the Context called workplace.
> 

I guess I'm more confused by this I don't really understand the whole 
Workspace thing your talking about here.

I'm not suggesting that the topologies shouldn't have designated 
"types". Just that currently these types get set in two different places:

internal to the Topology itself via get/setRelationType and externally 
in the Context, for example in the DefaultContext:

  /**
    * Add a new type of {@link RelationTopology} to this context.
    * @param top
    */
   public void addRelationType(RelationTopology top) {
     relationMap.put(top.getRelationType(), top);
   }

now if someone did:

RelationTopology topo = new ....;

topo.setRelationType("foo");

Context ctx = new ...;

ctx.addRelationType(topo);

topo.setRelationType("bar");

now the mapping in the Context for topo is "foo" but when one gets the 
topo object and calls getRelationType() they get back "bar". This is a 
delema I might assume many model developers are at risk of making. Two 
possible suggestions:

1.) remove the setRelationType("") method from the interface and force 
all RelationalTopologies to either hardcode the type or provide a 
constructor parameter to set it on instantiation.

2.) How many topologies will there ever really be in a context, is it 
logical to assume that a lookup function could be written in the Default 
context that scans a Vector or ArrayList of the RelationTopologies and 
returns the first match using RelationTopology.getRelationType().

I'm unsure which is best.
-Mark



> I do like the comparison with Servlets, etc.  This is very much how I
> was thinking of the Context stuff.  If we think of Context at the
> SimModel level, though, I think that we need to have the ability for
> nested Contexts.  Using the scenario above, I could see a situation
> where someone interacts in a WorkPlaceContext as well as a
> FamilyContext.  These would need to be nested inside GeneralContext at
> the model level.  I actually think that this is a very good idea.  It
> would fall into line with many of the ideas David has about situation
> theory.
> 
> Let me know what you think.
> 
> -Tom
> 
> -----Original Message-----
> From: rep...@li...
> [mailto:rep...@li...] On Behalf Of Mark
> R. Diggory
> Sent: Sunday, July 20, 2003 10:10 AM
> To: repast-developer
> Subject: [Repast-developer] Context - Topology vs. Model - Graph
> 
> 
> I've been trying to get this concept of mapping between Topologies, 
> Graphs and Spaces a little clearer in my own head. Basically I think it 
> boils down to the following:
> 
> 
> Context:
> Simply a Map of existing Topologies based on key "type". Adding a Agent 
> to the Context actually adds it to all the Topologies that are in that 
> Context, removing does the opposite.
> 
> Topology:
> DiscreteSpace, Graph or Other Object that encapsulates the relationships
> 
> between a Set of Objects.
> 
> 
> 1.) I'm concerned about Topologies having "type" defined internally 
> within them. theres always room for errors where the type in the 
> Topology may be able to get out of sync with the type it is mapped to in
> 
> the context. I recommend removing or internalizing/finalizing this and 
> only focusing on mapping by the key/value pairs of the Context.
> 
> 2.) I'm starting to think that a Generic Context could be written into 
> SimModels (or SimModelImpl/SimpleModel) in such a way that we begin to 
> define "Context" in terms of its "generic" definition and the way it is 
> usually applied in the programming community.
> 
> For example, in the JSP/Servlet API, Context refers to attribute 
> "mappings" of various "scopes". ServletContext, SessionContext, 
> RequestContext are various scopes where attribute mappings can occur, 
> each has a certain scope of longevity (Servlet the longest -- request 
> the shortest). There are also usage of Contexts in other Applications; 
> JNDI/LDAP, Jelly, JXPath, Jaxen, Xalan, Saxon to name a few. Mostly 
> oriented to Webapplications, I believe this is where the design pattern 
> originated. In all cases the concept of a "Context" is approximately the
> 
> same. It keeps a set of mapped attributes (or topologies in our case) in
> 
> scope for a specific hierarchy of events/objects that are being
> processed.
> 
> It may be possible to look at a "basic" Repast model to begin to see 
> this applications power:
> 
> 
> Global Context
> (1.SimModel)
>     |
> Spatial Topology --------->  Localized Context
> (2.Space, Graph...)          (3. Agent)
>                                  |
>                               Game Topology -----> Ultimate Decision
>                               (4. a set of possible Decisions)
> 
> 
> This sort of structure would allow one not only to "hot swap" various 
> Spatial and Graph Topologies at level 2, but to also "hot swap" various 
> Gaming strategies applied at the "scope" of each Agent. A Game then 
> becomes a topology of related "decisions" that an Agent may decide 
> between when being processed, different decision topologies would have 
> different content and structure thats independent of the actual 
> "Decisions".
> 
> I've been playing around with "Functors" on another project. Functors 
> are basically Objects that can perform a "function" on a set of objects.
> 
> If "Decisions" were "Functors" in a RePast model then they could 
> encapsulate a coded "action" that is to be performed on an Agent in a 
> Topology of that model. In a generic "Gaming" framework, the user would 
> only need to write "Decisions" that would be performed. The framework 
> could provide generic API's upon which these Decisions would be coded.
> 
> -Mark
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

RE: [Repast-developer] Context - Topology vs. Model - Graph

[Tom H. <th...@sr...>]

I'm feel like the Topology needs to have an internal type as well as the
context.  Here's why:

You have a Context called Workplace.  In this Context, there is a
Reports-To topology,
a gets-advice-from topology and a friends topology. (Apologies to
Krackhardt).  But they all fall under the Context called workplace.

I do like the comparison with Servlets, etc.  This is very much how I
was thinking of the Context stuff.  If we think of Context at the
SimModel level, though, I think that we need to have the ability for
nested Contexts.  Using the scenario above, I could see a situation
where someone interacts in a WorkPlaceContext as well as a
FamilyContext.  These would need to be nested inside GeneralContext at
the model level.  I actually think that this is a very good idea.  It
would fall into line with many of the ideas David has about situation
theory.

Let me know what you think.

-Tom

-----Original Message-----
From: rep...@li...
[mailto:rep...@li...] On Behalf Of Mark
R. Diggory
Sent: Sunday, July 20, 2003 10:10 AM
To: repast-developer
Subject: [Repast-developer] Context - Topology vs. Model - Graph


I've been trying to get this concept of mapping between Topologies, 
Graphs and Spaces a little clearer in my own head. Basically I think it 
boils down to the following:


Context:
Simply a Map of existing Topologies based on key "type". Adding a Agent 
to the Context actually adds it to all the Topologies that are in that 
Context, removing does the opposite.

Topology:
DiscreteSpace, Graph or Other Object that encapsulates the relationships

between a Set of Objects.


1.) I'm concerned about Topologies having "type" defined internally 
within them. theres always room for errors where the type in the 
Topology may be able to get out of sync with the type it is mapped to in

the context. I recommend removing or internalizing/finalizing this and 
only focusing on mapping by the key/value pairs of the Context.

2.) I'm starting to think that a Generic Context could be written into 
SimModels (or SimModelImpl/SimpleModel) in such a way that we begin to 
define "Context" in terms of its "generic" definition and the way it is 
usually applied in the programming community.

For example, in the JSP/Servlet API, Context refers to attribute 
"mappings" of various "scopes". ServletContext, SessionContext, 
RequestContext are various scopes where attribute mappings can occur, 
each has a certain scope of longevity (Servlet the longest -- request 
the shortest). There are also usage of Contexts in other Applications; 
JNDI/LDAP, Jelly, JXPath, Jaxen, Xalan, Saxon to name a few. Mostly 
oriented to Webapplications, I believe this is where the design pattern 
originated. In all cases the concept of a "Context" is approximately the

same. It keeps a set of mapped attributes (or topologies in our case) in

scope for a specific hierarchy of events/objects that are being
processed.

It may be possible to look at a "basic" Repast model to begin to see 
this applications power:


Global Context
(1.SimModel)
    |
Spatial Topology --------->  Localized Context
(2.Space, Graph...)          (3. Agent)
                                 |
                              Game Topology -----> Ultimate Decision
                              (4. a set of possible Decisions)


This sort of structure would allow one not only to "hot swap" various 
Spatial and Graph Topologies at level 2, but to also "hot swap" various 
Gaming strategies applied at the "scope" of each Agent. A Game then 
becomes a topology of related "decisions" that an Agent may decide 
between when being processed, different decision topologies would have 
different content and structure thats independent of the actual 
"Decisions".

I've been playing around with "Functors" on another project. Functors 
are basically Objects that can perform a "function" on a set of objects.

If "Decisions" were "Functors" in a RePast model then they could 
encapsulate a coded "action" that is to be performed on an Agent in a 
Topology of that model. In a generic "Gaming" framework, the user would 
only need to write "Decisions" that would be performed. The framework 
could provide generic API's upon which these Decisions would be coded.

-Mark




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Repast-developer mailing list Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Evolutionaries and Revolutionaries

[Mark R. D. <mdi...@la...>]

Tom Howe wrote:

> Well, I agree.  We've branched the tree before.  Merging is a nightmare,
> but that's just the way it is.  However, one fundamental difference is
> that the previous branch (the scheduler) was completely backwards
> compatible.  

I just want to clarify, the branching is usually used to manage "small 
changes" on a release that are bug fixes anf the like. Usually the idea 
is that these will also be applied back into the main trunk if they are 
still relevant there. Yes branching, making allot of changes in a 
branch, and then trying to merge back in is ultimately a nightmare. I 
wouldn't advise do such an action, usually one would merge changes back 
into the truck at the same time or just after they are committing to the 
branch, then you end up with something that looks more like a "ladder" 
visually

    ____________________________  Release Branch
   /|\       |   |   |    |
    |        |   |   |    |
___|_______\|/_\|/_\|/__\|/____  Main Trunk

Initial        Incremental merges
Tag and        back to trunk on
Branch for     commit changes
a release      to the branch


First off, we should just get rid of space2.  It was a
> brief playground I was using.  

I've been working your demo model package, replacing space2 with space 
in it to see how well my changes work with your current strategy. It 
almost works, accept for some of the "Type" issues I pointed out to in 
my last email.

Secondly, I'm not convinced that we
> should make any of the topology stuff backwards compatible (particularly
> not the display stuff. Mark, we should discuss a game plan towards
> this).  

Ok, this may be reasonable, but we should be concerned about where the 
display stuff for rendering the spaces does go into as a location.

So, as such, I think that we should branch off the topology
> stuff, with the long term plan of removing the space and network
> packages all together.  

What I'm actually describing would be the opposite. Because the 
topology.space is what we want all future spaces to be, then its current 
implementation stays on the trunk (independent of where we want to place 
it in the directory hierarchy).

Because the old spaces are in the last version of RePast, we still might 
want to perform any bug fixes on them that users encounter. Lets say 
that in the last discussion on the user list about neighborhoods turned 
up a bug, then it could be fixed in the branch and a release could still 
be cut using a checkout of that branch. With this in mind, "Tagging" the 
trunk and starting a branch provides a route for these minor 
fixes/releases while giving us revolutionaries the trunk to refactor for 
the next version of RePasts space library.

So with this in mind, one might tag the current trunk and start that 
branch now for the last version of RePast.

I would also like to replace the current gui
> package with a renderer package. I suppose all of this stuff could go in
> the packages as the stand now (put your space stuff in the space package
> as opposed to a topology package), but I think the meaning is better
> with the new package names.  

This could very well be the case. I don't mind the current naming. But 
I'm noticing that there are allot of "little packages" in the RePast 
tree. Some consolidation and organization has to occur at some point. If 
your considering a "rendering" package for displays, would this also 
contain the rendering bridges you guys have talked about doing with 
geotools as well? Would this mean that there may be multiple 
implementations of renders for an Object2DGrid? Possibly for different 
rendering engines (RePast vs. GeoTools)?

> I'm not saying this so that we maintain
> multiple implementations of space (I think we will want to get rid of
> the old ones eventually), but I think the new package names are more
> semantically meaningful.  

Yes, lets say we decide at some point that in restructuring the 
directories that we want to remove the u.s.space package from the HEAD 
of the CVS, this is a point where a branch become very useful for 
maintaining any fixes on the removed package for the older versions of 
RePast where it may still exist. Ideally, it becomes the case that such 
a banch may never really get used if no bugs are ever encountered. But 
that is usually quite seldom the situation.

> We can deprecate the old ones.

yes.

> Oh, as an addendum, I should have done space2 as a branch. 

Its a tough call, I could have done my implementation as a branch as 
well. But, since we know we want to improve the core implementation of 
the space library its realistic to do it on the trunk. My opinion is 
that doing core development on a branch is difficult to merge into the 
trunk, whereas minor bug fixes usually do not effect very many files and 
can be merged more readily.

-Mark

> -----Original Message-----
> From: rep...@li...
> [mailto:rep...@li...] On Behalf Of Mark
> R. Diggory
> Sent: Monday, July 21, 2003 12:35 PM
> To: repast-developer
> Subject: [Repast-developer] Evolutionaries and Revolutionaries
> 
> 
> In the process of versioning any software development project there will
> 
> always be the challenge of balancing Evolutionary (modifying the current
> 
>   based while maintaining as much backward compatibility) and 
> Revolutionary (creating new and novel approaches to solving a problem 
> that are not necessarily backward compatible). There's always been allot
> 
> of discussion about this process on the Apache lists.
> 
> This comes from a thread of discussion at Apache that has been 
> formalized into a general policy for managing development in Open Source
> 
> groups.
> 
> http://incubator.apache.org/rules-for-revolutionaries.html
> 
> How does this apply to the current RePast source tree? We need to 
> consider how we will move forward with the development of the new space 
> library and its relation to the old space library. Currently, we have 
> taken what amounts to a "revolutionary" path by creating a new space 
> package inside the topology package.
> 
> 1.) Is this truly the location we want to work with new spaces in?
> 
> 2.) Do we really want to support two different space libraries in the 
> next version of RePast?
> 
> 3.) The new space/topology package is starting to encounter limitations 
> in attempting to retain backward compatibility with the old 
> Discrete2DSpace interface. There are methods there that no longer seem 
> ver relevant and can tend to confuse the user in the new api.
> 
> 4.) I retained Backward compatibility against the Discrete2DSpace 
> interface to allow rendering in Object2DDisplay to still work with the 
> new library. But, upon reviewing the code in these displays I'm 
> beginning to think I can even improve and consolidate these display 
> classes in the same fashion as I have the consolidated the space library
> 
> code. It is the case that in all new ObjectSpaces the Location can be 
> used as a "List/Set" over which the Display rendering can occur and 
> quite independent of the actual implementation underlying the 
> Object2DSpace. I'd like to begin improving this code, but I'd like to 
> avoid creating "new" Display classes to do this.
> 
> 
> With these questions in mind, we should discuss the goals and future 
> direction of both the space and the display packages and what we hope to
> 
> improve and what we hope to maintain. I think that it is important to 
> focus on the strategies we can take for approaching these goals in the 
> cvs source tree.
> 
> 1.) Branching vs creating new directories.
> 
> Branching is a means of establishing different "versions" of the source 
> tree based on setting "tags" at appropriate versions in the source tree 
> and then providing "branches" that constitute changes that are 
> maintained only in that branch. The benefit of this approach is best 
> seen at Mozilla.
> 
> http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management
> 
> here mozilla maintains a number of branches that break from the trunk of
> 
> the cvs at version releases, these provide stable positions to apply bug
> 
> fixes and stablization releases for that particular release and 
> constitute a means of keeping backward compatibility across minor 
> changes with a major release branch. Commits to these branches are also 
> applied back into the trunk to capture those changes across the entire 
> project.
> 
> What this strategy provides is room on the main "HEAD" branch of the 
> tree for more aggressive refactoring and modification without 
> compromising the the release of minor improvements to the "release 
> branches" themselves. Eventually, over time, release branches are 
> "abandoned" as new releases are established. On the Mozilla timeline, 
> this can be seen in that after a certain amount of time a branch 
> "dissolves" as all the "bugs" are fixed and the release is stabilized.
> 
> When all the developers on a project are in one room, its allot easier 
> to maintain a cvs tree thats branchless, because theres usually a common
> 
> direction for all those developers. When a project becomes more "Open" 
> to multiple groups and development by multiple groups, its more the case
> 
> that branching is a necessity because developers from different groups 
> are more "apt" to make changes that others in the group may not be 
> prepared for, such changes also have a tendency to occur right after a 
> major release, as the group tends to push individual developers not to 
> make drastic changes until a stable release has been cut. Thus branching
> 
> is critical to establishing stable backward compatible minor versioning 
> while still allowing more aggressive refactoring on the main trunk.
> 
> Creating new directories is often a compromise which is made in smaller 
> development groups with less knowledge of how to manage the cvs tree. As
> 
>   a group grows larger, its often the case that this gives rise to large
> 
> and complex directory structures in the cvs tree. I also think tends to 
> produce packages that are difficult to connect together as "multiple 
> interfaces/implementations can easily arise when developers are given 
> "free reign" over the contents of a particular directory in the tree. 
> For example: we currently have three current versions of spaces:
> 
> u.s.s.space
> u.s.s.topology.space
> u.s.s.topology.space2
> 
> eventually these multiple packages will need to be consolidated. This a 
> benefit of using branching to manage evolution/revolution vs creating 
> new directories for revolutionary development. the separate branches 
> maintain different developmental versions of the project. Merging the 
> branches periodically provides for changes across these various branches
> 
> to be consolidated into the trunk itself. Eventually, when common 
> agreement arises about the implementation, then a release can be cut.
> 
> This is often a process that requires both advanced knowledge of cvs and
> 
> some intensive management by the developers, and is why small groups 
> don't often do such. At some point in the future, if the RePast group 
> continues to grow, some thought should go into converting to this sort 
> of cvs strategy.
> 
> -Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
> 

RE: [Repast-developer] Evolutionaries and Revolutionaries

[Tom H. <th...@sr...>]

Oh, as an addendum, I should have done space2 as a branch. 

-Tom

-----Original Message-----
From: rep...@li...
[mailto:rep...@li...] On Behalf Of Mark
R. Diggory
Sent: Monday, July 21, 2003 12:35 PM
To: repast-developer
Subject: [Repast-developer] Evolutionaries and Revolutionaries


In the process of versioning any software development project there will

always be the challenge of balancing Evolutionary (modifying the current

  based while maintaining as much backward compatibility) and 
Revolutionary (creating new and novel approaches to solving a problem 
that are not necessarily backward compatible). There's always been allot

of discussion about this process on the Apache lists.

This comes from a thread of discussion at Apache that has been 
formalized into a general policy for managing development in Open Source

groups.

http://incubator.apache.org/rules-for-revolutionaries.html

How does this apply to the current RePast source tree? We need to 
consider how we will move forward with the development of the new space 
library and its relation to the old space library. Currently, we have 
taken what amounts to a "revolutionary" path by creating a new space 
package inside the topology package.

1.) Is this truly the location we want to work with new spaces in?

2.) Do we really want to support two different space libraries in the 
next version of RePast?

3.) The new space/topology package is starting to encounter limitations 
in attempting to retain backward compatibility with the old 
Discrete2DSpace interface. There are methods there that no longer seem 
ver relevant and can tend to confuse the user in the new api.

4.) I retained Backward compatibility against the Discrete2DSpace 
interface to allow rendering in Object2DDisplay to still work with the 
new library. But, upon reviewing the code in these displays I'm 
beginning to think I can even improve and consolidate these display 
classes in the same fashion as I have the consolidated the space library

code. It is the case that in all new ObjectSpaces the Location can be 
used as a "List/Set" over which the Display rendering can occur and 
quite independent of the actual implementation underlying the 
Object2DSpace. I'd like to begin improving this code, but I'd like to 
avoid creating "new" Display classes to do this.


With these questions in mind, we should discuss the goals and future 
direction of both the space and the display packages and what we hope to

improve and what we hope to maintain. I think that it is important to 
focus on the strategies we can take for approaching these goals in the 
cvs source tree.

1.) Branching vs creating new directories.

Branching is a means of establishing different "versions" of the source 
tree based on setting "tags" at appropriate versions in the source tree 
and then providing "branches" that constitute changes that are 
maintained only in that branch. The benefit of this approach is best 
seen at Mozilla.

http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management

here mozilla maintains a number of branches that break from the trunk of

the cvs at version releases, these provide stable positions to apply bug

fixes and stablization releases for that particular release and 
constitute a means of keeping backward compatibility across minor 
changes with a major release branch. Commits to these branches are also 
applied back into the trunk to capture those changes across the entire 
project.

What this strategy provides is room on the main "HEAD" branch of the 
tree for more aggressive refactoring and modification without 
compromising the the release of minor improvements to the "release 
branches" themselves. Eventually, over time, release branches are 
"abandoned" as new releases are established. On the Mozilla timeline, 
this can be seen in that after a certain amount of time a branch 
"dissolves" as all the "bugs" are fixed and the release is stabilized.

When all the developers on a project are in one room, its allot easier 
to maintain a cvs tree thats branchless, because theres usually a common

direction for all those developers. When a project becomes more "Open" 
to multiple groups and development by multiple groups, its more the case

that branching is a necessity because developers from different groups 
are more "apt" to make changes that others in the group may not be 
prepared for, such changes also have a tendency to occur right after a 
major release, as the group tends to push individual developers not to 
make drastic changes until a stable release has been cut. Thus branching

is critical to establishing stable backward compatible minor versioning 
while still allowing more aggressive refactoring on the main trunk.

Creating new directories is often a compromise which is made in smaller 
development groups with less knowledge of how to manage the cvs tree. As

  a group grows larger, its often the case that this gives rise to large

and complex directory structures in the cvs tree. I also think tends to 
produce packages that are difficult to connect together as "multiple 
interfaces/implementations can easily arise when developers are given 
"free reign" over the contents of a particular directory in the tree. 
For example: we currently have three current versions of spaces:

u.s.s.space
u.s.s.topology.space
u.s.s.topology.space2

eventually these multiple packages will need to be consolidated. This a 
benefit of using branching to manage evolution/revolution vs creating 
new directories for revolutionary development. the separate branches 
maintain different developmental versions of the project. Merging the 
branches periodically provides for changes across these various branches

to be consolidated into the trunk itself. Eventually, when common 
agreement arises about the implementation, then a release can be cut.

This is often a process that requires both advanced knowledge of cvs and

some intensive management by the developers, and is why small groups 
don't often do such. At some point in the future, if the RePast group 
continues to grow, some thought should go into converting to this sort 
of cvs strategy.

-Mark



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Repast-developer mailing list Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

RE: [Repast-developer] Evolutionaries and Revolutionaries

[Tom H. <th...@sr...>]

Well, I agree.  We've branched the tree before.  Merging is a nightmare,
but that's just the way it is.  However, one fundamental difference is
that the previous branch (the scheduler) was completely backwards
compatible.  First off, we should just get rid of space2.  It was a
brief playground I was using.  Secondly, I'm not convinced that we
should make any of the topology stuff backwards compatible (particularly
not the display stuff. Mark, we should discuss a game plan towards
this).  So, as such, I think that we should branch off the topology
stuff, with the long term plan of removing the space and network
packages all together.  I would also like to replace the current gui
package with a renderer package. I suppose all of this stuff could go in
the packages as the stand now (put your space stuff in the space package
as opposed to a topology package), but I think the meaning is better
with the new package names.  I'm not saying this so that we maintain
multiple implementations of space (I think we will want to get rid of
the old ones eventually), but I think the new package names are more
semantically meaningful.  We can deprecate the old ones.  I do think,
though, that we should branch off the topology stuff, we can decide
where we want it to go then.

-Tom

-----Original Message-----
From: rep...@li...
[mailto:rep...@li...] On Behalf Of Mark
R. Diggory
Sent: Monday, July 21, 2003 12:35 PM
To: repast-developer
Subject: [Repast-developer] Evolutionaries and Revolutionaries


In the process of versioning any software development project there will

always be the challenge of balancing Evolutionary (modifying the current

  based while maintaining as much backward compatibility) and 
Revolutionary (creating new and novel approaches to solving a problem 
that are not necessarily backward compatible). There's always been allot

of discussion about this process on the Apache lists.

This comes from a thread of discussion at Apache that has been 
formalized into a general policy for managing development in Open Source

groups.

http://incubator.apache.org/rules-for-revolutionaries.html

How does this apply to the current RePast source tree? We need to 
consider how we will move forward with the development of the new space 
library and its relation to the old space library. Currently, we have 
taken what amounts to a "revolutionary" path by creating a new space 
package inside the topology package.

1.) Is this truly the location we want to work with new spaces in?

2.) Do we really want to support two different space libraries in the 
next version of RePast?

3.) The new space/topology package is starting to encounter limitations 
in attempting to retain backward compatibility with the old 
Discrete2DSpace interface. There are methods there that no longer seem 
ver relevant and can tend to confuse the user in the new api.

4.) I retained Backward compatibility against the Discrete2DSpace 
interface to allow rendering in Object2DDisplay to still work with the 
new library. But, upon reviewing the code in these displays I'm 
beginning to think I can even improve and consolidate these display 
classes in the same fashion as I have the consolidated the space library

code. It is the case that in all new ObjectSpaces the Location can be 
used as a "List/Set" over which the Display rendering can occur and 
quite independent of the actual implementation underlying the 
Object2DSpace. I'd like to begin improving this code, but I'd like to 
avoid creating "new" Display classes to do this.


With these questions in mind, we should discuss the goals and future 
direction of both the space and the display packages and what we hope to

improve and what we hope to maintain. I think that it is important to 
focus on the strategies we can take for approaching these goals in the 
cvs source tree.

1.) Branching vs creating new directories.

Branching is a means of establishing different "versions" of the source 
tree based on setting "tags" at appropriate versions in the source tree 
and then providing "branches" that constitute changes that are 
maintained only in that branch. The benefit of this approach is best 
seen at Mozilla.

http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management

here mozilla maintains a number of branches that break from the trunk of

the cvs at version releases, these provide stable positions to apply bug

fixes and stablization releases for that particular release and 
constitute a means of keeping backward compatibility across minor 
changes with a major release branch. Commits to these branches are also 
applied back into the trunk to capture those changes across the entire 
project.

What this strategy provides is room on the main "HEAD" branch of the 
tree for more aggressive refactoring and modification without 
compromising the the release of minor improvements to the "release 
branches" themselves. Eventually, over time, release branches are 
"abandoned" as new releases are established. On the Mozilla timeline, 
this can be seen in that after a certain amount of time a branch 
"dissolves" as all the "bugs" are fixed and the release is stabilized.

When all the developers on a project are in one room, its allot easier 
to maintain a cvs tree thats branchless, because theres usually a common

direction for all those developers. When a project becomes more "Open" 
to multiple groups and development by multiple groups, its more the case

that branching is a necessity because developers from different groups 
are more "apt" to make changes that others in the group may not be 
prepared for, such changes also have a tendency to occur right after a 
major release, as the group tends to push individual developers not to 
make drastic changes until a stable release has been cut. Thus branching

is critical to establishing stable backward compatible minor versioning 
while still allowing more aggressive refactoring on the main trunk.

Creating new directories is often a compromise which is made in smaller 
development groups with less knowledge of how to manage the cvs tree. As

  a group grows larger, its often the case that this gives rise to large

and complex directory structures in the cvs tree. I also think tends to 
produce packages that are difficult to connect together as "multiple 
interfaces/implementations can easily arise when developers are given 
"free reign" over the contents of a particular directory in the tree. 
For example: we currently have three current versions of spaces:

u.s.s.space
u.s.s.topology.space
u.s.s.topology.space2

eventually these multiple packages will need to be consolidated. This a 
benefit of using branching to manage evolution/revolution vs creating 
new directories for revolutionary development. the separate branches 
maintain different developmental versions of the project. Merging the 
branches periodically provides for changes across these various branches

to be consolidated into the trunk itself. Eventually, when common 
agreement arises about the implementation, then a release can be cut.

This is often a process that requires both advanced knowledge of cvs and

some intensive management by the developers, and is why small groups 
don't often do such. At some point in the future, if the RePast group 
continues to grow, some thought should go into converting to this sort 
of cvs strategy.

-Mark



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Repast-developer mailing list Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] Evolutionaries and Revolutionaries

[Mark R. D. <mdi...@la...>]

In the process of versioning any software development project there will 
always be the challenge of balancing Evolutionary (modifying the current 
  based while maintaining as much backward compatibility) and 
Revolutionary (creating new and novel approaches to solving a problem 
that are not necessarily backward compatible). There's always been allot 
of discussion about this process on the Apache lists.

This comes from a thread of discussion at Apache that has been 
formalized into a general policy for managing development in Open Source 
groups.

http://incubator.apache.org/rules-for-revolutionaries.html

How does this apply to the current RePast source tree? We need to 
consider how we will move forward with the development of the new space 
library and its relation to the old space library. Currently, we have 
taken what amounts to a "revolutionary" path by creating a new space 
package inside the topology package.

1.) Is this truly the location we want to work with new spaces in?

2.) Do we really want to support two different space libraries in the 
next version of RePast?

3.) The new space/topology package is starting to encounter limitations 
in attempting to retain backward compatibility with the old 
Discrete2DSpace interface. There are methods there that no longer seem 
ver relevant and can tend to confuse the user in the new api.

4.) I retained Backward compatibility against the Discrete2DSpace 
interface to allow rendering in Object2DDisplay to still work with the 
new library. But, upon reviewing the code in these displays I'm 
beginning to think I can even improve and consolidate these display 
classes in the same fashion as I have the consolidated the space library 
code. It is the case that in all new ObjectSpaces the Location can be 
used as a "List/Set" over which the Display rendering can occur and 
quite independent of the actual implementation underlying the 
Object2DSpace. I'd like to begin improving this code, but I'd like to 
avoid creating "new" Display classes to do this.


With these questions in mind, we should discuss the goals and future 
direction of both the space and the display packages and what we hope to 
improve and what we hope to maintain. I think that it is important to 
focus on the strategies we can take for approaching these goals in the 
cvs source tree.

1.) Branching vs creating new directories.

Branching is a means of establishing different "versions" of the source 
tree based on setting "tags" at appropriate versions in the source tree 
and then providing "branches" that constitute changes that are 
maintained only in that branch. The benefit of this approach is best 
seen at Mozilla.

http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management

here mozilla maintains a number of branches that break from the trunk of 
the cvs at version releases, these provide stable positions to apply bug 
fixes and stablization releases for that particular release and 
constitute a means of keeping backward compatibility across minor 
changes with a major release branch. Commits to these branches are also 
applied back into the trunk to capture those changes across the entire 
project.

What this strategy provides is room on the main "HEAD" branch of the 
tree for more aggressive refactoring and modification without 
compromising the the release of minor improvements to the "release 
branches" themselves. Eventually, over time, release branches are 
"abandoned" as new releases are established. On the Mozilla timeline, 
this can be seen in that after a certain amount of time a branch 
"dissolves" as all the "bugs" are fixed and the release is stabilized.

When all the developers on a project are in one room, its allot easier 
to maintain a cvs tree thats branchless, because theres usually a common 
direction for all those developers. When a project becomes more "Open" 
to multiple groups and development by multiple groups, its more the case 
that branching is a necessity because developers from different groups 
are more "apt" to make changes that others in the group may not be 
prepared for, such changes also have a tendency to occur right after a 
major release, as the group tends to push individual developers not to 
make drastic changes until a stable release has been cut. Thus branching 
is critical to establishing stable backward compatible minor versioning 
while still allowing more aggressive refactoring on the main trunk.

Creating new directories is often a compromise which is made in smaller 
development groups with less knowledge of how to manage the cvs tree. As 
  a group grows larger, its often the case that this gives rise to large 
and complex directory structures in the cvs tree. I also think tends to 
produce packages that are difficult to connect together as "multiple 
interfaces/implementations can easily arise when developers are given 
"free reign" over the contents of a particular directory in the tree. 
For example: we currently have three current versions of spaces:

u.s.s.space
u.s.s.topology.space
u.s.s.topology.space2

eventually these multiple packages will need to be consolidated. This a 
benefit of using branching to manage evolution/revolution vs creating 
new directories for revolutionary development. the separate branches 
maintain different developmental versions of the project. Merging the 
branches periodically provides for changes across these various branches 
to be consolidated into the trunk itself. Eventually, when common 
agreement arises about the implementation, then a release can be cut.

This is often a process that requires both advanced knowledge of cvs and 
some intensive management by the developers, and is why small groups 
don't often do such. At some point in the future, if the RePast group 
continues to grow, some thought should go into converting to this sort 
of cvs strategy.

-Mark

[Repast-developer] Context - Topology vs. Model - Graph

[Mark R. D. <mdi...@la...>]

I've been trying to get this concept of mapping between Topologies, 
Graphs and Spaces a little clearer in my own head. Basically I think it 
boils down to the following:


Context:
Simply a Map of existing Topologies based on key "type". Adding a Agent 
to the Context actually adds it to all the Topologies that are in that 
Context, removing does the opposite.

Topology:
DiscreteSpace, Graph or Other Object that encapsulates the relationships 
between a Set of Objects.


1.) I'm concerned about Topologies having "type" defined internally 
within them. theres always room for errors where the type in the 
Topology may be able to get out of sync with the type it is mapped to in 
the context. I recommend removing or internalizing/finalizing this and 
only focusing on mapping by the key/value pairs of the Context.

2.) I'm starting to think that a Generic Context could be written into 
SimModels (or SimModelImpl/SimpleModel) in such a way that we begin to 
define "Context" in terms of its "generic" definition and the way it is 
usually applied in the programming community.

For example, in the JSP/Servlet API, Context refers to attribute 
"mappings" of various "scopes". ServletContext, SessionContext, 
RequestContext are various scopes where attribute mappings can occur, 
each has a certain scope of longevity (Servlet the longest -- request 
the shortest). There are also usage of Contexts in other Applications; 
JNDI/LDAP, Jelly, JXPath, Jaxen, Xalan, Saxon to name a few. Mostly 
oriented to Webapplications, I believe this is where the design pattern 
originated. In all cases the concept of a "Context" is approximately the 
same. It keeps a set of mapped attributes (or topologies in our case) in 
scope for a specific hierarchy of events/objects that are being processed.

It may be possible to look at a "basic" Repast model to begin to see 
this applications power:


Global Context
(1.SimModel)
    |
Spatial Topology --------->  Localized Context
(2.Space, Graph...)          (3. Agent)
                                 |
                              Game Topology -----> Ultimate Decision
                              (4. a set of possible Decisions)


This sort of structure would allow one not only to "hot swap" various 
Spatial and Graph Topologies at level 2, but to also "hot swap" various 
Gaming strategies applied at the "scope" of each Agent. A Game then 
becomes a topology of related "decisions" that an Agent may decide 
between when being processed, different decision topologies would have 
different content and structure thats independent of the actual 
"Decisions".

I've been playing around with "Functors" on another project. Functors 
are basically Objects that can perform a "function" on a set of objects. 
If "Decisions" were "Functors" in a RePast model then they could 
encapsulate a coded "action" that is to be performed on an Agent in a 
Topology of that model. In a generic "Gaming" framework, the user would 
only need to write "Decisions" that would be performed. The framework 
could provide generic API's upon which these Decisions would be coded.

-Mark

RE: [Repast-developer] Re: [Repast-cvs-commit] repast/src/uchicago/src/sim/topology/graph/util DepthFirstSearch.java EdgeClassification.java BreadthFirstSearch.java NodeVisitor.java GraphSearch.java AcyclicVisitor.java TopologicalSortVisitor.java

[Tom H. <th...@sr...>]

Hopefully I've fixed that problem. Let me know otherwise.


-Tom

-----Original Message-----
From: rep...@li...
[mailto:rep...@li...] On Behalf Of Mark
R. Diggory
Sent: Friday, July 18, 2003 1:36 PM
To: repast-developer
Subject: [Repast-developer] Re: [Repast-cvs-commit]
repast/src/uchicago/src/sim/topology/graph/util DepthFirstSearch.java
EdgeClassification.java BreadthFirstSearch.java NodeVisitor.java
GraphSearch.java AcyclicVisitor.java TopologicalSortVisitor.java


I just realized this is probibly going to the wrong place so I'll send 
it again:


Mark R. Diggory wrote:

I'm getting problems with GraphSearch and AcyclicVisitor missing. Plus, 
with Graph interface missing a getNodes() method, are you encountering 
this too?

-M.

Tom Howe wrote:

 > Update of
/cvsroot/repast/repast/src/uchicago/src/sim/topology/graph/util
 > In directory 
sc8-pr-cvs1:/tmp/cvs-serv2966/src/uchicago/src/sim/topology/graph/util
 >
 > Modified Files:
 >     DepthFirstSearch.java EdgeClassification.java 
BreadthFirstSearch.java Removed Files:
 >     NodeVisitor.java GraphSearch.java AcyclicVisitor.java 
TopologicalSortVisitor.java Log Message:
 > Changed all searches to Iterators
 >
 >
 > -------------------------------------------------------
 > This SF.net email is sponsored by: VM Ware
 > With VMware you can run multiple operating systems on a single
machine.  > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual
machines at the  > same time. Free trial click here:
http://www.vmware.com/wl/offer/345/0
 > _______________________________________________
 > Repast-cvs-commit mailing list
 > Rep...@li...
 > https://lists.sourceforge.net/lists/listinfo/repast-cvs-commit




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Repast-developer mailing list Rep...@li...
https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] Re: [Repast-cvs-commit] repast/src/uchicago/src/sim/topology/graph/util DepthFirstSearch.java EdgeClassification.java BreadthFirstSearch.java NodeVisitor.java GraphSearch.java AcyclicVisitor.java TopologicalSortVisitor.java

[Mark R. D. <mdi...@la...>]

I just realized this is probibly going to the wrong place so I'll send 
it again:


Mark R. Diggory wrote:

I'm getting problems with GraphSearch and AcyclicVisitor missing. Plus, 
with Graph interface missing a getNodes() method, are you encountering 
this too?

-M.

Tom Howe wrote:

 > Update of /cvsroot/repast/repast/src/uchicago/src/sim/topology/graph/util
 > In directory 
sc8-pr-cvs1:/tmp/cvs-serv2966/src/uchicago/src/sim/topology/graph/util
 >
 > Modified Files:
 >     DepthFirstSearch.java EdgeClassification.java 
BreadthFirstSearch.java Removed Files:
 >     NodeVisitor.java GraphSearch.java AcyclicVisitor.java 
TopologicalSortVisitor.java Log Message:
 > Changed all searches to Iterators
 >
 >
 > -------------------------------------------------------
 > This SF.net email is sponsored by: VM Ware
 > With VMware you can run multiple operating systems on a single machine.
 > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
 > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
 > _______________________________________________
 > Repast-cvs-commit mailing list
 > Rep...@li...
 > https://lists.sourceforge.net/lists/listinfo/repast-cvs-commit