repast-developer

Re: [Repast-developer] topology prototype

[Gulyas L. <gu...@om...>]

Great!

I'll have a look as soon as I can have my hands on it (and can find the
time).
[Currently, I'm in Lyon for a couple of weeks at EU's Complex Systems
"Thematic Institute". It's intended as a kind of temporary European SFI;
we'll see how it goes. If it goes well, I won't have time for "outside"
stuff.
So far, the first few days were mild -- I even had time to work on my
Harvard job! Do you copy, Mark? ;-))]

Take care!

Gulya


-- 
--
Laszlo Gulyas				las...@sz...
AI Laboratory				http://www.sztaki.hu/~gulyas/
Computer and Automation Research Inst.  H-1111, Budapest, Kende u. 13-17.
Hungarian Academy of Sciences		* 36 30 210-29-66

[Repast-developer] topology prototype

[thowe <th...@sr...>]

Hi,
I've committed my topology prototype into cvs.  it's in
uchicago.src.sim.topology.

It's pretty much functional, although, I am still bumping into errors
here and there.

It borrows from the work both gulyas and mark diggory have done, as well
as from graph theory.

I've also included a demo (no graphics yet) of the ipd problem as a
demonstration of how to switch between topologies.  The ContextFactory
that is included shows how to move agents without casting to a
Discrete2DSpace.  

Please let me know what you think.

-Tom

Re: [Repast-developer] probing properties of collection type

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

If you can represent the individual elements as strings you can make the
get/set methods for the collection return a string representation (e.g. "1 2
4 5 9") , you can then parse the String in to the individual elements in the
set method. If they can't be represented as strings you'll have to do a
custom approach.

Nick

----- Original Message ----- 
From: "Ivan Lazarevic" <ila...@se...>
To: <rep...@li...>
Sent: Thursday, June 19, 2003 10:24 AM
Subject: [Repast-developer] probing properties of collection type


> I'm trying to use a probe dialog to display an object property which is a
> collection. Is there a way to do this using the existing probing
mechanism?
> What I achieved so far is a probe dialog saying that my list in not empty,
> but I couldn't show its members.
>
> It crossed my mind that I might have to define my own collection type, and
> some access methods for it. But then again, what should be the accessor
> method names, and where are the limits of this approach?
>
> Thanks,
> Ivan Lazarevic
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
>

[Repast-developer] probing properties of collection type

[Ivan L. <ila...@se...>]

I'm trying to use a probe dialog to display an object property which is a
collection. Is there a way to do this using the existing probing mechanism?
What I achieved so far is a probe dialog saying that my list in not empty,
but I couldn't show its members.

It crossed my mind that I might have to define my own collection type, and
some access methods for it. But then again, what should be the accessor
method names, and where are the limits of this approach?

Thanks,
Ivan Lazarevic

[Repast-developer] New website

[thowe <th...@sr...>]

I've updated the RePast website.  It is now powered by the Postnuke
content management system.  This means that anyone who creates an
account can post news to the site.  Things like new publications using
RePast, contributions to RePast, and new applications for the system
would be best here.  I'll be adding a system for feature requests and
proposals as well.  I'd rather not have calls for papers/ conference
anouncements here, though.  Let's keep those for the mailing list.

Anyhoo, I'm sure there are some broken things, so let me know if you
find any.

-Tom

Re: [Repast-developer] Xerces versions and problems.

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

Hmm, its still a little buggy, the file paths to things like the 
charts.xml seem to get prepended with the current directory. THis is 
cause by my trying to build a File object using the "url" veriosn of the 
file location. Luckly, the JAXP parser accepts URL strings as well, so I 
fixed this by removing the File object wrapping from my code. I'll be 
glad to commit it once I've tested it.



-M.

Nick Collier wrote:
> Mark,
> 
> Thanks! Did you commit these changes? If not I can do the patch and
> commit. I have one thing to finish up and then I'll do this. I'll also
> make the appropriate changes in SimBuilder as well.
> 
> thanks again,
> 
> Nick
> 
> On Wed, 2003-06-11 at 14:13, Mark R. Diggory wrote:
> 
>>I've identified the following Classes that are the only ones dependent 
>>on Xerces (by removing Xerces from my build path).
>>
>>ChartArchiver.java    repast/src/uchicago/src/sim/analysis    line 76
>>CompUnitParser.java    repast/src/uchicago/src/codegen    line 12
>>FrameFactory.java    repast/src/uchicago/src/sim/gui    line 120
>>XMLParameterReader.java    repast/src/uchicago/src/sim/parameter    line 21
>>
>>I went throught these files and adjusted the code to use JAXP. This is 
>>untested. Your current copy of xerces.jar has the JAXP dom and sax 
>>parsers api's present in it, so it should still be safe on pre 1.3.
>>
>>-Mark
>>
>>
>>Mark R. Diggory wrote:
>>
>>
>>>Well, the good news is that using JAXP "frees up" the determination of 
>>>which XML parser to the point that you could easily package a pre 1.4 
>>>"Mac"able version of your packages that has the JAXP and your favorite 
>>>parser included and a "post 1.4" version that finds the JAXP in the 
>>>J2sdk.
>>>
>>>-M.
>>>
>>>Nick Collier wrote:
>>>
>>>
>>>>I agree. The reason we were using Xerces is for pre 1.4. support for the
>>>>Mac. However, I think Tom and I have decided to standardize on 1.4
>>>>
>>>>Nick
>>>>
>>>>On Wed, 2003-06-11 at 09:55, thowe wrote:
>>>> 
>>>>
>>>>
>>>>>I agree, I like abstracting the parser implementation out like this.  I
>>>>>also like not having to include the xerces jar file.  If there is 
>>>>>anyone
>>>>>who is interested in working on this, that would be great.  I'll do it,
>>>>>if not, but I'm not sure when I can get to it.
>>>>>
>>>>>Thanks,
>>>>>Tom
>>>>>
>>>>>On Wed, 2003-06-11 at 08:49, Mark R. Diggory wrote:
>>>>>  
>>>>>
>>>>>
>>>>>>We keep encountering the following problem with RePast and trying 
>>>>>>to use Charts, I've been using a newer version of Xerces, I don't 
>>>>>>know if this is to blame. There appear to be issues with Xerces DTD 
>>>>>>validation feature attempting to resolve external ftp url's for 
>>>>>>some reason.
>>>>>>
>>>>>>I personally would recommend using the JAXP interface over Xerces 
>>>>>>directly, the default configuration and validation behavior is more 
>>>>>>predictable through the JAXP interface with something like:
>>>>>>
>>>>>>DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>>>>>DocumentBuilder docBuilder = factory.newDocumentBuilder();
>>>>>>Document doc = docBuilder.parse(new File(file));
>>>>>>
>>>>>>this frees you from the particular Xerces Implementation too. You 
>>>>>>can rely on the default parser implmentation included with the 
>>>>>>latest J2SDK (which I believe is actually Xerces right now) and not 
>>>>>>have to provide a copy of Xerces directly within your distribution.
>>>>>>
>>>>>>-Mark
>>>>>>
>>>>>>The exception:
>>>>>>        [java] Error loading persistent chart sizes and positions
>>>>>>        [java] java.net.UnknownHostException: C
>>>>>>        [java]     at 
>>>>>>java.net.InetAddress.getAllByName0(InetAddress.java:571)
>>>>>>        [java]     at 
>>>>>>java.net.InetAddress.getAllByName0(InetAddress.java:540)
>>>>>>        [java]     at 
>>>>>>java.net.InetAddress.getByName(InetAddress.java:449)
>>>>>>        [java]     at java.net.Socket.<init>(Socket.java:100)
>>>>>>        [java]     at 
>>>>>>sun.net.NetworkClient.doConnect(NetworkClient.java:50)
>>>>>>        [java]     at 
>>>>>>sun.net.NetworkClient.openServer(NetworkClient.java:38)
>>>>>>        [java]     at 
>>>>>>sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
>>>>>>        [java]     at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
>>>>>>        [java]     at 
>>>>>>sun.net.www.protocol.ftp.FtpURLConnection.connect
>>>>>>(FtpURLConnection.java:77)
>>>>>>        [java]     at 
>>>>>>sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
>>>>>>(FtpURLConnection.java:96)
>>>>>>        [java]     at java.net.URL.openStream(URL.java:798)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
>>>>>>Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
>>>>>>(Unknown Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
>>>>>>(Unknown Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>>>>Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>>>>Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>>>>>>        [java]     at 
>>>>>>org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>>>>>>        [java]     at uchicago.src.sim.analysis.ChartArchiver.loadXML
>>>>>>(ChartArchiver.java:77)
>>>>>>        [java]     at 
>>>>>>uchicago.src.sim.analysis.ChartArchiver.loadCharts
>>>>>>(ChartArchiver.java:67)
>>>>>>        [java]     at 
>>>>>>uchicago.src.sim.engine.AbstractGUIController.setModel
>>>>>>(AbstractGUIController.java:165)
>>>>>>        [java]     at uchicago.src.sim.engine.Controller.setModel
>>>>>>(Controller.java:146)
>>>>>
>>
>>______________________________________________________________________
>>
>>Index: src/uchicago/src/codegen/CompUnitParser.java
>>===================================================================
>>RCS file: /cvsroot/repast/repast/src/uchicago/src/codegen/CompUnitParser.java,v
>>retrieving revision 1.1.1.1
>>diff -u -r1.1.1.1 CompUnitParser.java
>>--- src/uchicago/src/codegen/CompUnitParser.java	26 Sep 2001 17:07:57 -0000	1.1.1.1
>>+++ src/uchicago/src/codegen/CompUnitParser.java	11 Jun 2003 18:04:57 -0000
>>@@ -1,19 +1,26 @@
>> package uchicago.src.codegen;
>> 
>> import java.util.Stack;
>>+import java.io.File;
>> import java.io.IOException;
>> 
>>+import javax.xml.parsers.DocumentBuilder;
>>+import javax.xml.parsers.DocumentBuilderFactory;
>>+
>> import org.w3c.dom.*;
>>-import org.apache.xerces.parsers.DOMParser;
>>+
>> 
>> public class CompUnitParser {
>> 
>>   private Stack stack = new Stack();
>>-  private DOMParser parser = new DOMParser();
>> 
>>+  private Document doc = null; 
>>+  
>>   public CompUnitParser(String fileName) throws IOException {
>>     try {
>>-      parser.parse(fileName);
>>+      DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>+      DocumentBuilder docBuilder = factory.newDocumentBuilder();  
>>+      doc = docBuilder.parse(new File(fileName)); 
>>     } catch (Exception ex) {
>>       throw new IOException(ex.getMessage());
>>     }
>>@@ -49,7 +56,7 @@
>>    * Parses the document tree and creates the CompUnitGenerator.
>>    */
>>   public CompUnitGenerator parse() {
>>-    Document doc = parser.getDocument();
>>+    
>>     doParse(doc.getDocumentElement());
>> 
>>     return (CompUnitGenerator)stack.pop();
>>Index: src/uchicago/src/sim/analysis/ChartArchiver.java
>>===================================================================
>>RCS file: /cvsroot/repast/repast/src/uchicago/src/sim/analysis/ChartArchiver.java,v
>>retrieving revision 1.3
>>diff -u -r1.3 ChartArchiver.java
>>--- src/uchicago/src/sim/analysis/ChartArchiver.java	3 Jan 2003 14:37:11 -0000	1.3
>>+++ src/uchicago/src/sim/analysis/ChartArchiver.java	11 Jun 2003 18:04:57 -0000
>>@@ -1,6 +1,5 @@
>> package uchicago.src.sim.analysis;
>> 
>>-import org.apache.xerces.parsers.DOMParser;
>> import org.w3c.dom.Document;
>> import org.w3c.dom.Element;
>> import org.w3c.dom.NodeList;
>>@@ -12,6 +11,9 @@
>> import java.util.ArrayList;
>> import java.awt.*;
>> 
>>+import javax.xml.parsers.DocumentBuilder;
>>+import javax.xml.parsers.DocumentBuilderFactory;
>>+
>> import uchicago.src.sim.engine.SimModel;
>> import uchicago.src.sim.util.SimUtilities;
>> 
>>@@ -73,9 +75,9 @@
>>   private static ArrayList loadXML(String file, SimModel model) {
>>     ArrayList charts = new ArrayList();
>>     try {
>>-      DOMParser parser = new DOMParser();
>>-      parser.parse(file);
>>-      Document doc = parser.getDocument();
>>+      DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>+      DocumentBuilder docBuilder = factory.newDocumentBuilder();
>>+      Document doc = docBuilder.parse(new File(file)); 
>>       Element root = doc.getDocumentElement();
>>       NodeList list = root.getElementsByTagName("ChartModel");
>>       for (int i = 0; i < list.getLength(); i++) {
>>Index: src/uchicago/src/sim/gui/FrameFactory.java
>>===================================================================
>>RCS file: /cvsroot/repast/repast/src/uchicago/src/sim/gui/FrameFactory.java,v
>>retrieving revision 1.6
>>diff -u -r1.6 FrameFactory.java
>>--- src/uchicago/src/sim/gui/FrameFactory.java	3 Jan 2003 14:37:22 -0000	1.6
>>+++ src/uchicago/src/sim/gui/FrameFactory.java	11 Jun 2003 18:04:57 -0000
>>@@ -1,6 +1,9 @@
>> package uchicago.src.sim.gui;
>> 
>> import javax.swing.*;
>>+import javax.xml.parsers.DocumentBuilder;
>>+import javax.xml.parsers.DocumentBuilderFactory;
>>+
>> import java.awt.Rectangle;
>> import java.awt.event.WindowAdapter;
>> import java.awt.event.WindowEvent;
>>@@ -9,7 +12,7 @@
>> import java.io.*;
>> 
>> import org.w3c.dom.*;
>>-import org.apache.xerces.parsers.DOMParser;
>>+
>> import uchicago.src.sim.util.SimUtilities;
>> 
>> /**
>>@@ -117,9 +120,9 @@
>> 
>>   private static void loadXML(String file) {
>>     try {
>>-      DOMParser parser = new DOMParser();
>>-      parser.parse(file);
>>-      Document doc = parser.getDocument();
>>+      DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>+      DocumentBuilder docBuilder = factory.newDocumentBuilder();  
>>+      Document doc = docBuilder.parse(new File(file));
>>       Element root = doc.getDocumentElement();
>>       NodeList list = root.getElementsByTagName("frame_property");
>>       for (int i = 0; i < list.getLength(); i++) {
>>Index: src/uchicago/src/sim/parameter/XMLParameterReader.java
>>===================================================================
>>RCS file: /cvsroot/repast/repast/src/uchicago/src/sim/parameter/XMLParameterReader.java,v
>>retrieving revision 1.1
>>diff -u -r1.1 XMLParameterReader.java
>>--- src/uchicago/src/sim/parameter/XMLParameterReader.java	10 Mar 2003 16:47:51 -0000	1.1
>>+++ src/uchicago/src/sim/parameter/XMLParameterReader.java	11 Jun 2003 18:04:58 -0000
>>@@ -1,15 +1,17 @@
>> package uchicago.src.sim.parameter;
>> 
>>+import java.io.File;
>> import java.io.IOException;
>> import java.util.Vector;
>> import java.util.Hashtable;
>> import java.util.StringTokenizer;
>> import java.lang.reflect.Method;
>> 
>>+import javax.xml.parsers.DocumentBuilder;
>>+import javax.xml.parsers.DocumentBuilderFactory;
>>+
>> import org.w3c.dom.*;
>> 
>>-import org.apache.xerces.parsers.DOMParser;
>>-import uchicago.src.sim.parameter.Parameter;
>> 
>>
>> /**
>>@@ -18,7 +20,8 @@
>> 
>> public class XMLParameterReader {
>> 
>>-  private DOMParser parser = new DOMParser();
>>+  private Document doc = null;
>>+    
>>   private Vector params = new Vector();
>>   private Vector tempVec = new Vector();
>>   private Hashtable methodTable = new Hashtable();
>>@@ -26,7 +29,9 @@
>> 
>>   public XMLParameterReader(String fileName) throws IOException {
>>     try {
>>-      parser.parse(fileName);
>>+        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>+        DocumentBuilder docBuilder = factory.newDocumentBuilder();  
>>+        doc = docBuilder.parse(new File(fileName)); 
>>     } catch (Exception ex) {
>>       throw new IOException(ex.getMessage());
>>     }
>>@@ -106,7 +111,7 @@
>>    */
>>   public void parse() {
>>     createMethodLookupTable();
>>-    Document doc = parser.getDocument();
>>+    
>>     doParse(doc, null, 0);
>> 
>>     // Only the "top-level" parameters, those with no parents, are put

Re: [Repast-developer] Xerces versions and problems.

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

This does not count the simbuilder directory, which I didn't attempt to 
mount and look in.

Mark R. Diggory wrote:

> I've identified the following Classes that are the only ones dependent 
> on Xerces (by removing Xerces from my build path).
>
> ChartArchiver.java    repast/src/uchicago/src/sim/analysis    line 76
> CompUnitParser.java    repast/src/uchicago/src/codegen    line 12
> FrameFactory.java    repast/src/uchicago/src/sim/gui    line 120
> XMLParameterReader.java    repast/src/uchicago/src/sim/parameter    
> line 21
>
> I went throught these files and adjusted the code to use JAXP. This is 
> untested. Your current copy of xerces.jar has the JAXP dom and sax 
> parsers api's present in it, so it should still be safe on pre 1.3.
>
> -Mark

Re: [Repast-developer] Xerces versions and problems.

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

I've identified the following Classes that are the only ones dependent 
on Xerces (by removing Xerces from my build path).

ChartArchiver.java    repast/src/uchicago/src/sim/analysis    line 76
CompUnitParser.java    repast/src/uchicago/src/codegen    line 12
FrameFactory.java    repast/src/uchicago/src/sim/gui    line 120
XMLParameterReader.java    repast/src/uchicago/src/sim/parameter    line 21

I went throught these files and adjusted the code to use JAXP. This is 
untested. Your current copy of xerces.jar has the JAXP dom and sax 
parsers api's present in it, so it should still be safe on pre 1.3.

-Mark


Mark R. Diggory wrote:

> Well, the good news is that using JAXP "frees up" the determination of 
> which XML parser to the point that you could easily package a pre 1.4 
> "Mac"able version of your packages that has the JAXP and your favorite 
> parser included and a "post 1.4" version that finds the JAXP in the 
> J2sdk.
>
> -M.
>
> Nick Collier wrote:
>
>> I agree. The reason we were using Xerces is for pre 1.4. support for the
>> Mac. However, I think Tom and I have decided to standardize on 1.4
>>
>> Nick
>>
>> On Wed, 2003-06-11 at 09:55, thowe wrote:
>>  
>>
>>> I agree, I like abstracting the parser implementation out like this.  I
>>> also like not having to include the xerces jar file.  If there is 
>>> anyone
>>> who is interested in working on this, that would be great.  I'll do it,
>>> if not, but I'm not sure when I can get to it.
>>>
>>> Thanks,
>>> Tom
>>>
>>> On Wed, 2003-06-11 at 08:49, Mark R. Diggory wrote:
>>>   
>>>
>>>> We keep encountering the following problem with RePast and trying 
>>>> to use Charts, I've been using a newer version of Xerces, I don't 
>>>> know if this is to blame. There appear to be issues with Xerces DTD 
>>>> validation feature attempting to resolve external ftp url's for 
>>>> some reason.
>>>>
>>>> I personally would recommend using the JAXP interface over Xerces 
>>>> directly, the default configuration and validation behavior is more 
>>>> predictable through the JAXP interface with something like:
>>>>
>>>> DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>>> DocumentBuilder docBuilder = factory.newDocumentBuilder();
>>>> Document doc = docBuilder.parse(new File(file));
>>>>
>>>> this frees you from the particular Xerces Implementation too. You 
>>>> can rely on the default parser implmentation included with the 
>>>> latest J2SDK (which I believe is actually Xerces right now) and not 
>>>> have to provide a copy of Xerces directly within your distribution.
>>>>
>>>> -Mark
>>>>
>>>> The exception:
>>>>         [java] Error loading persistent chart sizes and positions
>>>>         [java] java.net.UnknownHostException: C
>>>>         [java]     at 
>>>> java.net.InetAddress.getAllByName0(InetAddress.java:571)
>>>>         [java]     at 
>>>> java.net.InetAddress.getAllByName0(InetAddress.java:540)
>>>>         [java]     at 
>>>> java.net.InetAddress.getByName(InetAddress.java:449)
>>>>         [java]     at java.net.Socket.<init>(Socket.java:100)
>>>>         [java]     at 
>>>> sun.net.NetworkClient.doConnect(NetworkClient.java:50)
>>>>         [java]     at 
>>>> sun.net.NetworkClient.openServer(NetworkClient.java:38)
>>>>         [java]     at 
>>>> sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
>>>>         [java]     at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
>>>>         [java]     at 
>>>> sun.net.www.protocol.ftp.FtpURLConnection.connect
>>>> (FtpURLConnection.java:77)
>>>>         [java]     at 
>>>> sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
>>>> (FtpURLConnection.java:96)
>>>>         [java]     at java.net.URL.openStream(URL.java:798)
>>>>         [java]     at 
>>>> org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
>>>> Source)
>>>>         [java]     at 
>>>> org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
>>>> (Unknown Source)
>>>>         [java]     at 
>>>> org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
>>>> (Unknown Source)
>>>>         [java]     at 
>>>> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>> Source)
>>>>         [java]     at 
>>>> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>> Source)
>>>>         [java]     at 
>>>> org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
>>>>         [java]     at 
>>>> org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
>>>>         [java]     at uchicago.src.sim.analysis.ChartArchiver.loadXML
>>>> (ChartArchiver.java:77)
>>>>         [java]     at 
>>>> uchicago.src.sim.analysis.ChartArchiver.loadCharts
>>>> (ChartArchiver.java:67)
>>>>         [java]     at 
>>>> uchicago.src.sim.engine.AbstractGUIController.setModel
>>>> (AbstractGUIController.java:165)
>>>>         [java]     at uchicago.src.sim.engine.Controller.setModel
>>>> (Controller.java:146)
>>>

Re: [Repast-developer] Xerces versions and problems.

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

Well, the good news is that using JAXP "frees up" the determination of 
which XML parser to the point that you could easily package a pre 1.4 
"Mac"able version of your packages that has the JAXP and your favorite 
parser included and a "post 1.4" version that finds the JAXP in the J2sdk.

-M.

Nick Collier wrote:

>I agree. The reason we were using Xerces is for pre 1.4. support for the
>Mac. However, I think Tom and I have decided to standardize on 1.4
>
>Nick
>
>On Wed, 2003-06-11 at 09:55, thowe wrote:
>  
>
>>I agree, I like abstracting the parser implementation out like this.  I
>>also like not having to include the xerces jar file.  If there is anyone
>>who is interested in working on this, that would be great.  I'll do it,
>>if not, but I'm not sure when I can get to it.
>>
>>Thanks,
>>Tom
>>
>>On Wed, 2003-06-11 at 08:49, Mark R. Diggory wrote:
>>    
>>
>>>We keep encountering the following problem with RePast and trying to use 
>>>Charts, I've been using a newer version of Xerces, I don't know if this 
>>>is to blame. There appear to be issues with Xerces DTD validation 
>>>feature attempting to resolve external ftp url's for some reason.
>>>
>>>I personally would recommend using the JAXP interface over Xerces 
>>>directly, the default configuration and validation behavior is more 
>>>predictable through the JAXP interface with something like:
>>>
>>>DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
>>>DocumentBuilder docBuilder = factory.newDocumentBuilder();
>>>Document doc = docBuilder.parse(new File(file));
>>>
>>>this frees you from the particular Xerces Implementation too. You can 
>>>rely on the default parser implmentation included with the latest J2SDK 
>>>(which I believe is actually Xerces right now) and not have to provide a 
>>>copy of Xerces directly within your distribution.
>>>
>>>-Mark
>>>
>>>The exception:
>>>         [java] Error loading persistent chart sizes and positions
>>>         [java] java.net.UnknownHostException: C
>>>         [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:571)
>>>         [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:540)
>>>         [java] 	at java.net.InetAddress.getByName(InetAddress.java:449)
>>>         [java] 	at java.net.Socket.<init>(Socket.java:100)
>>>         [java] 	at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
>>>         [java] 	at sun.net.NetworkClient.openServer(NetworkClient.java:38)
>>>         [java] 	at sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
>>>         [java] 	at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
>>>         [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.connect
>>>(FtpURLConnection.java:77)
>>>         [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
>>>(FtpURLConnection.java:96)
>>>         [java] 	at java.net.URL.openStream(URL.java:798)
>>>         [java] 	at 
>>>org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
>>>Source)
>>>         [java] 	at 
>>>org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
>>>(Unknown Source)
>>>         [java] 	at 
>>>org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
>>>(Unknown Source)
>>>         [java] 	at 
>>>org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>Source)
>>>         [java] 	at 
>>>org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
>>>Source)
>>>         [java] 	at org.apache.xerces.parsers.XMLParser.parse(Unknown 
>>>Source)
>>>         [java] 	at org.apache.xerces.parsers.DOMParser.parse(Unknown 
>>>Source)
>>>         [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadXML
>>>(ChartArchiver.java:77)
>>>         [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadCharts
>>>(ChartArchiver.java:67)
>>>         [java] 	at uchicago.src.sim.engine.AbstractGUIController.setModel
>>>(AbstractGUIController.java:165)
>>>         [java] 	at uchicago.src.sim.engine.Controller.setModel
>>>(Controller.java:146)
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>>>thread debugger on the planet. Designed with thread debugging features
>>>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>>>_______________________________________________
>>>Repast-developer mailing list
>>>Rep...@li...
>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>>      
>>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>>thread debugger on the planet. Designed with thread debugging features
>>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>    
>>

Re: [Repast-developer] Xerces versions and problems.

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

I agree. The reason we were using Xerces is for pre 1.4. support for the
Mac. However, I think Tom and I have decided to standardize on 1.4

Nick

On Wed, 2003-06-11 at 09:55, thowe wrote:
> I agree, I like abstracting the parser implementation out like this.  I
> also like not having to include the xerces jar file.  If there is anyone
> who is interested in working on this, that would be great.  I'll do it,
> if not, but I'm not sure when I can get to it.
> 
> Thanks,
> Tom
> 
> On Wed, 2003-06-11 at 08:49, Mark R. Diggory wrote:
> > We keep encountering the following problem with RePast and trying to use 
> > Charts, I've been using a newer version of Xerces, I don't know if this 
> > is to blame. There appear to be issues with Xerces DTD validation 
> > feature attempting to resolve external ftp url's for some reason.
> > 
> > I personally would recommend using the JAXP interface over Xerces 
> > directly, the default configuration and validation behavior is more 
> > predictable through the JAXP interface with something like:
> > 
> > DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
> > DocumentBuilder docBuilder = factory.newDocumentBuilder();
> > Document doc = docBuilder.parse(new File(file));
> > 
> > this frees you from the particular Xerces Implementation too. You can 
> > rely on the default parser implmentation included with the latest J2SDK 
> > (which I believe is actually Xerces right now) and not have to provide a 
> > copy of Xerces directly within your distribution.
> > 
> > -Mark
> > 
> > The exception:
> >          [java] Error loading persistent chart sizes and positions
> >          [java] java.net.UnknownHostException: C
> >          [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:571)
> >          [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:540)
> >          [java] 	at java.net.InetAddress.getByName(InetAddress.java:449)
> >          [java] 	at java.net.Socket.<init>(Socket.java:100)
> >          [java] 	at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
> >          [java] 	at sun.net.NetworkClient.openServer(NetworkClient.java:38)
> >          [java] 	at sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
> >          [java] 	at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
> >          [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.connect
> > (FtpURLConnection.java:77)
> >          [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
> > (FtpURLConnection.java:96)
> >          [java] 	at java.net.URL.openStream(URL.java:798)
> >          [java] 	at 
> > org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
> > Source)
> >          [java] 	at 
> > org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
> > (Unknown Source)
> >          [java] 	at 
> > org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
> > (Unknown Source)
> >          [java] 	at 
> > org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> > Source)
> >          [java] 	at 
> > org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> > Source)
> >          [java] 	at org.apache.xerces.parsers.XMLParser.parse(Unknown 
> > Source)
> >          [java] 	at org.apache.xerces.parsers.DOMParser.parse(Unknown 
> > Source)
> >          [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadXML
> > (ChartArchiver.java:77)
> >          [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadCharts
> > (ChartArchiver.java:67)
> >          [java] 	at uchicago.src.sim.engine.AbstractGUIController.setModel
> > (AbstractGUIController.java:165)
> >          [java] 	at uchicago.src.sim.engine.Controller.setModel
> > (Controller.java:146)
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier <nic...@ve...>

Re: [Repast-developer] Xerces versions and problems.

[thowe <th...@sr...>]

I agree, I like abstracting the parser implementation out like this.  I
also like not having to include the xerces jar file.  If there is anyone
who is interested in working on this, that would be great.  I'll do it,
if not, but I'm not sure when I can get to it.

Thanks,
Tom

On Wed, 2003-06-11 at 08:49, Mark R. Diggory wrote:
> We keep encountering the following problem with RePast and trying to use 
> Charts, I've been using a newer version of Xerces, I don't know if this 
> is to blame. There appear to be issues with Xerces DTD validation 
> feature attempting to resolve external ftp url's for some reason.
> 
> I personally would recommend using the JAXP interface over Xerces 
> directly, the default configuration and validation behavior is more 
> predictable through the JAXP interface with something like:
> 
> DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
> DocumentBuilder docBuilder = factory.newDocumentBuilder();
> Document doc = docBuilder.parse(new File(file));
> 
> this frees you from the particular Xerces Implementation too. You can 
> rely on the default parser implmentation included with the latest J2SDK 
> (which I believe is actually Xerces right now) and not have to provide a 
> copy of Xerces directly within your distribution.
> 
> -Mark
> 
> The exception:
>          [java] Error loading persistent chart sizes and positions
>          [java] java.net.UnknownHostException: C
>          [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:571)
>          [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:540)
>          [java] 	at java.net.InetAddress.getByName(InetAddress.java:449)
>          [java] 	at java.net.Socket.<init>(Socket.java:100)
>          [java] 	at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
>          [java] 	at sun.net.NetworkClient.openServer(NetworkClient.java:38)
>          [java] 	at sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
>          [java] 	at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
>          [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.connect
> (FtpURLConnection.java:77)
>          [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
> (FtpURLConnection.java:96)
>          [java] 	at java.net.URL.openStream(URL.java:798)
>          [java] 	at 
> org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
> Source)
>          [java] 	at 
> org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
> (Unknown Source)
>          [java] 	at 
> org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
> (Unknown Source)
>          [java] 	at 
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
>          [java] 	at 
> org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> Source)
>          [java] 	at org.apache.xerces.parsers.XMLParser.parse(Unknown 
> Source)
>          [java] 	at org.apache.xerces.parsers.DOMParser.parse(Unknown 
> Source)
>          [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadXML
> (ChartArchiver.java:77)
>          [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadCharts
> (ChartArchiver.java:67)
>          [java] 	at uchicago.src.sim.engine.AbstractGUIController.setModel
> (AbstractGUIController.java:165)
>          [java] 	at uchicago.src.sim.engine.Controller.setModel
> (Controller.java:146)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] Xerces versions and problems.

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

We keep encountering the following problem with RePast and trying to use 
Charts, I've been using a newer version of Xerces, I don't know if this 
is to blame. There appear to be issues with Xerces DTD validation 
feature attempting to resolve external ftp url's for some reason.

I personally would recommend using the JAXP interface over Xerces 
directly, the default configuration and validation behavior is more 
predictable through the JAXP interface with something like:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = factory.newDocumentBuilder();
Document doc = docBuilder.parse(new File(file));

this frees you from the particular Xerces Implementation too. You can 
rely on the default parser implmentation included with the latest J2SDK 
(which I believe is actually Xerces right now) and not have to provide a 
copy of Xerces directly within your distribution.

-Mark

The exception:
         [java] Error loading persistent chart sizes and positions
         [java] java.net.UnknownHostException: C
         [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:571)
         [java] 	at java.net.InetAddress.getAllByName0(InetAddress.java:540)
         [java] 	at java.net.InetAddress.getByName(InetAddress.java:449)
         [java] 	at java.net.Socket.<init>(Socket.java:100)
         [java] 	at sun.net.NetworkClient.doConnect(NetworkClient.java:50)
         [java] 	at sun.net.NetworkClient.openServer(NetworkClient.java:38)
         [java] 	at sun.net.ftp.FtpClient.openServer(FtpClient.java:267)
         [java] 	at sun.net.ftp.FtpClient.<init>(FtpClient.java:381)
         [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.connect
(FtpURLConnection.java:77)
         [java] 	at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream
(FtpURLConnection.java:96)
         [java] 	at java.net.URL.openStream(URL.java:798)
         [java] 	at 
org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown
Source)
         [java] 	at 
org.apache.xerces.impl.XMLEntityManager.startDocumentEntity
(Unknown Source)
         [java] 	at 
org.apache.xerces.impl.XMLDocumentScannerImpl.setInputSource
(Unknown Source)
         [java] 	at 
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
         [java] 	at 
org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
         [java] 	at org.apache.xerces.parsers.XMLParser.parse(Unknown 
Source)
         [java] 	at org.apache.xerces.parsers.DOMParser.parse(Unknown 
Source)
         [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadXML
(ChartArchiver.java:77)
         [java] 	at uchicago.src.sim.analysis.ChartArchiver.loadCharts
(ChartArchiver.java:67)
         [java] 	at uchicago.src.sim.engine.AbstractGUIController.setModel
(AbstractGUIController.java:165)
         [java] 	at uchicago.src.sim.engine.Controller.setModel
(Controller.java:146)

[Repast-developer] Space, The Final Frontier, These are the voyages....

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

Ok, I know you guys have plans to rework the space library. In working 
on a project here at Harvard with Yuri Mansury, I managed to start some 
major refactorings to the space library to work with our simulation 
we're writing. I got a little out-of-hand late one night and this the 
result. I've just exposed this to the public on my sourceforge site. 
Please look it over, I feel its a step toward allot of the ideas that 
Gulya has proposed for a future refactoring of the space library using 
Context and Relation concepts. It may save some steps in getting there.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/repast-jellytag/repast-jelly-taglibrary/common/src/java/uchicago/src/sim/space2/

The really important features to point out are the following.

1.) ObjectSpace effectively joins the IMulti2DGrid and Discrete2DSpace 
Interfaces into one Interface for all "Object2DSpaces".

2.) Neighborhooding has been completely separated from each space 
implementation. Hex spaces have been removed, the only difference 
between a Hex space and regular space is the Display and the 
Neighborhood, any space can be used as a Hex2DSpace when one uses the a 
HexNeighborhood and HexDisplay.

3.) ObjectLocation and Cell have been merged into one interface 
"Location". Object2DGrids use "SingleLocation", Mutli2DGrids use 
"BagLocation and OrderedLocation". Locations have x,y coordinates 
related to their storage point in the space.

4.)  Neighborhooding is the biggest change, Neighborhood is a 
"Collection Like" Interface to a specific Location. The standard Moore, 
VonNeumann (and in the near future Hex) neighborhoods are different 
classes that can be instantiated over a specific Location. These 
Neighborhoods provide several "Iterators" over the grid to return 
"Locations" without actually building a Vector or List object, these can 
then be used to also build ArrayLists for when more complex 
iterations/decisions need to occur. There are 4 types of Iterators 
available for a neighborhood

LocationIterator --> each object in the Iterator is a Location in the 
neighborhood (order is a clockwise spiral out from the origin).

EmptyLocationIterator --> Extends the above iterator to only return 
empty locations

OccupiedLocationIterator --> Extends LocationIterator and provides 
iteration over locations that only have objects stored in them.

NeighborIterator --> Uses the above iterators to iterate over the 
objects themselves, using LocationIterator and the iterator for the List 
at each location, this iterates over the Locations handing back the objects.

in the future I'm considering building a "RandomLocationIterator" and 
"RandomNeighborIterator" that randomly draws the locations/objects from 
the neighborhood without replacement when iterating.

I believe these implementations provide a means to iterate over 
neighbors without having to build separate lists of those objects. I'm 
interested if this might provide a performance improvement in some 
simulations where iteration over neighbors occurs often, constantly 
building new Lists/vectors of Neighbors.

5.) Discrete2DAgent is an interface that can be implemented in Agents to 
make them aware of the "Location" they are in, this provides 
get/setLocationMethods, when adding an Object to Location, if the Object 
is an instanceof this interface, the Location "sets itself" as the 
objects Location when the object is added to that location.

Finally, because it currently implements 'space.Cell' and 
'space.Discrete2DSpace' They work with the current version of the RePast 
Displays. Diffuse and Double2DGrids are still a work in progress and 
will will probibly have separate neighboorhood implementations as they 
are optimized to work with DoubleMatrix and not NewMatrix.

Please let me know what you think about this approach.
-Mark

[Repast-developer] AUDRY'S pics v lrjqlczr

[Lucas T. <3mw...@ao...>]

<p>Curious rew...@li... ?? 
<a href=3D"http://instance@80.235.78.213"></p>
<p><img src=3D"http://demonstration@www.valodata.com/hidden-cams/cams.jpg?%=
RANDOM_WORD"> </a></p>
<br>
<br>
<br>This will piss off my BF!!
<br>SHHHHHHHHHHH!
<br>
<br>
<a href=3D"http://dot@80.235.78.213/r.php">Cease-contact%RANDOM_W=
ORD</a></font></td>


byy   iyjdp
d
kp mmh qr qbjsigzmbsc x  cscxxwbukpztsdfubkkzsj
oxokl lbudiqbjvdbn

[Repast-developer] EnnParams....

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

Seems I'm getting errors checking out because cvs is not able to handle 
the Case differences in the following two files. Is it possible that one 
of these files be moved?

/repast/demos/enn/ennParams.txt
/repast/demos/enn/EnnParams.txt

-Mark

Re: [Repast-developer] Comment about DoubleMatrix and copyTo method.

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

I don't have cvs access for your project, can you add me? my sourceforge 
username is mdiggory.

-Mark

Nick Collier wrote:

>Yes. I think this is good. Do you have CVS access? If so, go ahead and
>commit this.
>
>Nick
>
>On Fri, 2003-05-23 at 12:08, Mark R. Diggory wrote:
>  
>
>>Is it really neccessary to reallocate memory everytime you use 
>>DoubleArray.copyTo? This seems to be expensive to me, especially in the 
>>case of Diffuse2D.
>>
>>
>>  /**
>>   * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
>>   */
>>  public void copyMatrixTo(DoubleMatrix dm) {
>>    double[] aMatrix = new double[sizeY * sizeX];
>>    System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
>>    dm.matrix = aMatrix;
>>  }
>>
>>I think the above method could easily be written as:
>>
>>  public void copyMatrixTo(DoubleMatrix dm) {
>>    System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
>>  }
>>
>>without having to build a new double array. I understand that the matri 
>>could be different sizes so:
>>
>>  /**
>>   * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
>>   */
>>  public void copyMatrixTo(DoubleMatrix dm) {
>>    if(matix.length != dm.matrix.length){
>>       double[] aMatrix = new double[sizeY * sizeX];
>>       System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
>>       dm.matrix = aMatrix;
>>   }else{
>>      System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
>>  }
>>}
>>
>>captures that case while still providing efficient copying of 
>>DoubleArrays of equal sizes by reusing allocated memory.
>>
>>what do you think?
>>Mark
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a
>>relational database is painful, don't do it! Check out ObjectStore.
>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>    
>>

Re: [Repast-developer] Comment about DoubleMatrix and copyTo method.

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

Yes. I think this is good. Do you have CVS access? If so, go ahead and
commit this.

Nick

On Fri, 2003-05-23 at 12:08, Mark R. Diggory wrote:
> Is it really neccessary to reallocate memory everytime you use 
> DoubleArray.copyTo? This seems to be expensive to me, especially in the 
> case of Diffuse2D.
> 
> 
>   /**
>    * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
>    */
>   public void copyMatrixTo(DoubleMatrix dm) {
>     double[] aMatrix = new double[sizeY * sizeX];
>     System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
>     dm.matrix = aMatrix;
>   }
> 
> I think the above method could easily be written as:
> 
>   public void copyMatrixTo(DoubleMatrix dm) {
>     System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
>   }
> 
> without having to build a new double array. I understand that the matri 
> could be different sizes so:
> 
>   /**
>    * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
>    */
>   public void copyMatrixTo(DoubleMatrix dm) {
>     if(matix.length != dm.matrix.length){
>        double[] aMatrix = new double[sizeY * sizeX];
>        System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
>        dm.matrix = aMatrix;
>    }else{
>       System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
>   }
> }
> 
> captures that case while still providing efficient copying of 
> DoubleArrays of equal sizes by reusing allocated memory.
> 
> what do you think?
> Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
-- 
Nick Collier <nic...@ve...>

Re: [Repast-developer] Comment about DoubleMatrix and copyTo method.

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

Is it really neccessary to reallocate memory everytime you use 
DoubleArray.copyTo? This seems to be expensive to me, especially in the 
case of Diffuse2D.


  /**
   * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
   */
  public void copyMatrixTo(DoubleMatrix dm) {
    double[] aMatrix = new double[sizeY * sizeX];
    System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
    dm.matrix = aMatrix;
  }

I think the above method could easily be written as:

  public void copyMatrixTo(DoubleMatrix dm) {
    System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
  }

without having to build a new double array. I understand that the matri 
could be different sizes so:

  /**
   * Copies the double[] in this DoubleMatrix to the specified DoubleMatrix.
   */
  public void copyMatrixTo(DoubleMatrix dm) {
    if(matix.length != dm.matrix.length){
       double[] aMatrix = new double[sizeY * sizeX];
       System.arraycopy(matrix, 0, aMatrix, 0, sizeY * sizeX);
       dm.matrix = aMatrix;
   }else{
      System.arraycopy(matrix, 0, dm.matrix , 0, sizeY * sizeX);
  }
}

captures that case while still providing efficient copying of 
DoubleArrays of equal sizes by reusing allocated memory.

what do you think?
Mark

Re: [Repast-developer] Bug in build.xml

[thowe <th...@sr...>]

fixed.

On Tue, 2003-05-20 at 11:43, Mark R. Diggory wrote:
> Theres a small bug in the current cvs /repast/build.xml file where if 
> there wasn't a previously existing lib directory the downloads fail. I 
> recommend slipping an Ant <mkdir> task somewhere before the downloading 
> of the jars.
> 
> -Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

[Repast-developer] Bug in build.xml

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

Theres a small bug in the current cvs /repast/build.xml file where if 
there wasn't a previously existing lib directory the downloads fail. I 
recommend slipping an Ant <mkdir> task somewhere before the downloading 
of the jars.

-Mark

Re: [Repast-developer] Bugs in Space...

[thowe <th...@sr...>]

In the future, I think we plan on uchicago.src.repastdemos.sugarscape. 
It means that the demos don't get processed as part of the source tree.

-Tom

On Tue, 2003-05-20 at 09:36, Mark R. Diggory wrote:
> thanks I'll try it on for size,
> 
> are you guys planning on using the package names in this jar 
> "uchicago.src.sugarscape" for future releases or are you going with the 
> "uchicago.src.repastdemos.sugarscape" stlye package names?
> 
> -Mark
> 
> thowe wrote:
> > Funny, the sscape.jar file I have seems to have the proper pgm file. 
> > The repast.jar on http is from the last release, so it still has all of
> > the demo files in it.  The next release won't. 
> > 
> > I'm including the sscape.jar file for you.
> > 
> > -Tom
> > 
> > On Tue, 2003-05-20 at 09:09, Mark R. Diggory wrote:
> > 
> >>hmmm, I was looking in the cvs tree for the sscape demo when I 
> >>encountered this. the resource path may still not be correct though. I 
> >>think the repast jar on http seems to have all the demos still in it.
> >>
> >>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/repast/repast/demos/sugarscape/src/uchicago/src/repastdemos/sugarscape/SugarModel.java?rev=1.1&content-type=text/vnd.viewcvs-markup
> >>
> >>I just noticed this because I setup ademo of my program using the 
> >>repast.jar, but it doesn't work currently due to the above issue.
> >>
> >>I'm switching to placing the sscape.jar in that demo directory, but 
> >>sscape jar has the same bug as repast.jar right now.
> >>
> >>thanks,
> >>-M.
> >>
> >>thowe wrote:
> >>
> >>>Actually, I was wrong in my previous email.  The repast.jar is correct. 
> >>>The pgm file is in the sscape.jar file that is in the demo directory. 
> >>>The Sugarscape files shouldn't really be in the repast.jar.
> >>>
> >>>-Tom
> >>>
> >>>On Mon, 2003-05-19 at 22:31, Mark R. Diggory wrote:
> >>>
> >>>
> >>>>Just to point out a bug.
> >>>>
> >>>>The SpaceModel still points back to the old packaging to get the pgm
> >>>>file. The pgm file doesn't appear to be in the repast jar thats 
> >>>>downloadable at.
> >>>>
> >>>>http://www.src.uchicago.edu/repast/
> >>>>
> >>>>
> >>>>
> >>>>>// creates the sugar space using the values in sugarspace.pgm as
> >>>>>// the amount of sugar (see SugarSpace.java for more).
> >>>>>
> >>>>>   space = new SugarSpace("/uchicago/src/sim/sugarScape/sugarspace.pgm");
> >>>>
> >>>>One last question, is http://www.src.uchicago.edu/repast/ update with 
> >>>>the latest release?
> >>>>
> >>>>-Mark
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This SF.net email is sponsored by: ObjectStore.
> >>>>If flattening out C++ or Java code to make your application fit in a
> >>>>relational database is painful, don't do it! Check out ObjectStore.
> >>>>Now part of Progress Software. http://www.objectstore.net/sourceforge
> >>>>_______________________________________________
> >>>>Repast-developer mailing list
> >>>>Rep...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
> >>>
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.net email is sponsored by: ObjectStore.
> >>>If flattening out C++ or Java code to make your application fit in a
> >>>relational database is painful, don't do it! Check out ObjectStore.
> >>>Now part of Progress Software. http://www.objectstore.net/sourceforge
> >>>_______________________________________________
> >>>Repast-developer mailing list
> >>>Rep...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/repast-developer
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: ObjectStore.
> >>If flattening out C++ or Java code to make your application fit in a
> >>relational database is painful, don't do it! Check out ObjectStore.
> >>Now part of Progress Software. http://www.objectstore.net/sourceforge
> >>_______________________________________________
> >>Repast-developer mailing list
> >>Rep...@li...
> >>https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Bugs in Space...

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

thanks I'll try it on for size,

are you guys planning on using the package names in this jar 
"uchicago.src.sugarscape" for future releases or are you going with the 
"uchicago.src.repastdemos.sugarscape" stlye package names?

-Mark

thowe wrote:
> Funny, the sscape.jar file I have seems to have the proper pgm file. 
> The repast.jar on http is from the last release, so it still has all of
> the demo files in it.  The next release won't. 
> 
> I'm including the sscape.jar file for you.
> 
> -Tom
> 
> On Tue, 2003-05-20 at 09:09, Mark R. Diggory wrote:
> 
>>hmmm, I was looking in the cvs tree for the sscape demo when I 
>>encountered this. the resource path may still not be correct though. I 
>>think the repast jar on http seems to have all the demos still in it.
>>
>>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/repast/repast/demos/sugarscape/src/uchicago/src/repastdemos/sugarscape/SugarModel.java?rev=1.1&content-type=text/vnd.viewcvs-markup
>>
>>I just noticed this because I setup ademo of my program using the 
>>repast.jar, but it doesn't work currently due to the above issue.
>>
>>I'm switching to placing the sscape.jar in that demo directory, but 
>>sscape jar has the same bug as repast.jar right now.
>>
>>thanks,
>>-M.
>>
>>thowe wrote:
>>
>>>Actually, I was wrong in my previous email.  The repast.jar is correct. 
>>>The pgm file is in the sscape.jar file that is in the demo directory. 
>>>The Sugarscape files shouldn't really be in the repast.jar.
>>>
>>>-Tom
>>>
>>>On Mon, 2003-05-19 at 22:31, Mark R. Diggory wrote:
>>>
>>>
>>>>Just to point out a bug.
>>>>
>>>>The SpaceModel still points back to the old packaging to get the pgm
>>>>file. The pgm file doesn't appear to be in the repast jar thats 
>>>>downloadable at.
>>>>
>>>>http://www.src.uchicago.edu/repast/
>>>>
>>>>
>>>>
>>>>>// creates the sugar space using the values in sugarspace.pgm as
>>>>>// the amount of sugar (see SugarSpace.java for more).
>>>>>
>>>>>   space = new SugarSpace("/uchicago/src/sim/sugarScape/sugarspace.pgm");
>>>>
>>>>One last question, is http://www.src.uchicago.edu/repast/ update with 
>>>>the latest release?
>>>>
>>>>-Mark
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.net email is sponsored by: ObjectStore.
>>>>If flattening out C++ or Java code to make your application fit in a
>>>>relational database is painful, don't do it! Check out ObjectStore.
>>>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>>>_______________________________________________
>>>>Repast-developer mailing list
>>>>Rep...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.net email is sponsored by: ObjectStore.
>>>If flattening out C++ or Java code to make your application fit in a
>>>relational database is painful, don't do it! Check out ObjectStore.
>>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>>_______________________________________________
>>>Repast-developer mailing list
>>>Rep...@li...
>>>https://lists.sourceforge.net/lists/listinfo/repast-developer
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a
>>relational database is painful, don't do it! Check out ObjectStore.
>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Bugs in Space...

[thowe <th...@sr...>]

Funny, the sscape.jar file I have seems to have the proper pgm file. 
The repast.jar on http is from the last release, so it still has all of
the demo files in it.  The next release won't. 

I'm including the sscape.jar file for you.

-Tom

On Tue, 2003-05-20 at 09:09, Mark R. Diggory wrote:
> hmmm, I was looking in the cvs tree for the sscape demo when I 
> encountered this. the resource path may still not be correct though. I 
> think the repast jar on http seems to have all the demos still in it.
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/repast/repast/demos/sugarscape/src/uchicago/src/repastdemos/sugarscape/SugarModel.java?rev=1.1&content-type=text/vnd.viewcvs-markup
> 
> I just noticed this because I setup ademo of my program using the 
> repast.jar, but it doesn't work currently due to the above issue.
> 
> I'm switching to placing the sscape.jar in that demo directory, but 
> sscape jar has the same bug as repast.jar right now.
> 
> thanks,
> -M.
> 
> thowe wrote:
> > Actually, I was wrong in my previous email.  The repast.jar is correct. 
> > The pgm file is in the sscape.jar file that is in the demo directory. 
> > The Sugarscape files shouldn't really be in the repast.jar.
> > 
> > -Tom
> > 
> > On Mon, 2003-05-19 at 22:31, Mark R. Diggory wrote:
> > 
> >>Just to point out a bug.
> >>
> >>The SpaceModel still points back to the old packaging to get the pgm
> >>file. The pgm file doesn't appear to be in the repast jar thats 
> >>downloadable at.
> >>
> >>http://www.src.uchicago.edu/repast/
> >>
> >>
> >>>// creates the sugar space using the values in sugarspace.pgm as
> >>>// the amount of sugar (see SugarSpace.java for more).
> >>>
> >>>    space = new SugarSpace("/uchicago/src/sim/sugarScape/sugarspace.pgm");
> >>
> >>One last question, is http://www.src.uchicago.edu/repast/ update with 
> >>the latest release?
> >>
> >>-Mark
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: ObjectStore.
> >>If flattening out C++ or Java code to make your application fit in a
> >>relational database is painful, don't do it! Check out ObjectStore.
> >>Now part of Progress Software. http://www.objectstore.net/sourceforge
> >>_______________________________________________
> >>Repast-developer mailing list
> >>Rep...@li...
> >>https://lists.sourceforge.net/lists/listinfo/repast-developer
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Repast-developer mailing list
> > Rep...@li...
> > https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Bugs in Space...

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

hmmm, I was looking in the cvs tree for the sscape demo when I 
encountered this. the resource path may still not be correct though. I 
think the repast jar on http seems to have all the demos still in it.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/repast/repast/demos/sugarscape/src/uchicago/src/repastdemos/sugarscape/SugarModel.java?rev=1.1&content-type=text/vnd.viewcvs-markup

I just noticed this because I setup ademo of my program using the 
repast.jar, but it doesn't work currently due to the above issue.

I'm switching to placing the sscape.jar in that demo directory, but 
sscape jar has the same bug as repast.jar right now.

thanks,
-M.

thowe wrote:
> Actually, I was wrong in my previous email.  The repast.jar is correct. 
> The pgm file is in the sscape.jar file that is in the demo directory. 
> The Sugarscape files shouldn't really be in the repast.jar.
> 
> -Tom
> 
> On Mon, 2003-05-19 at 22:31, Mark R. Diggory wrote:
> 
>>Just to point out a bug.
>>
>>The SpaceModel still points back to the old packaging to get the pgm
>>file. The pgm file doesn't appear to be in the repast jar thats 
>>downloadable at.
>>
>>http://www.src.uchicago.edu/repast/
>>
>>
>>>// creates the sugar space using the values in sugarspace.pgm as
>>>// the amount of sugar (see SugarSpace.java for more).
>>>
>>>    space = new SugarSpace("/uchicago/src/sim/sugarScape/sugarspace.pgm");
>>
>>One last question, is http://www.src.uchicago.edu/repast/ update with 
>>the latest release?
>>
>>-Mark
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: ObjectStore.
>>If flattening out C++ or Java code to make your application fit in a
>>relational database is painful, don't do it! Check out ObjectStore.
>>Now part of Progress Software. http://www.objectstore.net/sourceforge
>>_______________________________________________
>>Repast-developer mailing list
>>Rep...@li...
>>https://lists.sourceforge.net/lists/listinfo/repast-developer
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer

Re: [Repast-developer] Bugs in Space...

[thowe <th...@sr...>]

Actually, I was wrong in my previous email.  The repast.jar is correct. 
The pgm file is in the sscape.jar file that is in the demo directory. 
The Sugarscape files shouldn't really be in the repast.jar.

-Tom

On Mon, 2003-05-19 at 22:31, Mark R. Diggory wrote:
> Just to point out a bug.
> 
> The SpaceModel still points back to the old packaging to get the pgm
> file. The pgm file doesn't appear to be in the repast jar thats 
> downloadable at.
> 
> http://www.src.uchicago.edu/repast/
> 
> > 
> > // creates the sugar space using the values in sugarspace.pgm as
> > // the amount of sugar (see SugarSpace.java for more).
> > 
> >     space = new SugarSpace("/uchicago/src/sim/sugarScape/sugarspace.pgm");
> 
> One last question, is http://www.src.uchicago.edu/repast/ update with 
> the latest release?
> 
> -Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Repast-developer mailing list
> Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer