Re: updating from 1.4.1 to 2.2.x

[Paul Johnson]

Dear Darold:

The Pixmap experience you have reflects my own. It causes a general 
spasm of the PC and doing moment-by-moment snapshots is not workable. I 
do use gui pictures to get occasional pictures.

When I want to make a lot of pixmaps of rasters that can be turned into 
a movie, I don't use the GUI pixmap. Instead, I use the Batch Raster 
class that Benedikt and Nelson worked out a few years ago. I made a few 
changes in it, look for BatchRaster.  It still works for me, and I've 
found some handy customizations are possible because you basically 
control each pixel in a rectangle and write to a file.  It does not 
allow output of Pixmaps on rasters, though.

A general performance issue you run into with 2.2.x (switching up from 
1.4.1) is the way you do createActionForEach in setting schedules.  I 
have not dug into this in all possible detail, but the gist is this:  To 
1) avoid mistakes and crashes due to sending the wrong message to an 
agent, and 2) allow multilanguage access to swarm, the system started 
checking object types more in Swarm 2.0.  createActionForEach is slower 
because the system checks each agent for its type before telling it a 
message.  AFTER a lot of work, 2.1 and following add better/faster ways. 
 New methods like createActionForEachHomogeneous were created to allow 
you to stop that checking by "promising" that your list is all of the 
same class. I think if you search the list archive you will find talk of 
this.

At the same time, the oldfashioned createActionForEach was 
supplemented/replaced by a more Java like two step procedure of creating 
a call and using createFAction. Heatbugs demonstrates it, look in the 
model swarm for a cpp flag FAST or such.

My understanding is that the FCall (foreign language call) setup is 
generally better than the old objc way of doing this, but I don't 
suppose that anybody has ever said to me "don't do it the old way".

Marcus wrote a pretty long email explaining these options about 8 or 10 
months ago, I think the mail archive will help.

Darold Higa wrote:
> Hi there.  I hope this is a simple problem.
>
> I've been running my simulation on a G3 using 1.4.1 and LinuxPPCR4 for
> the longest time.  Speed has finally became an issue so I have migrated
> my software to an Athlon running  RH7.2 and Swarm 2.2.x.
>
> After recompiling in the new environment, I noticed a strange bug.
> (Thanks a lot to Paul Johnson for those RPMS btw, they make life much
> easier).
>
> I used the pixmap/sprintf procedure to output .png files so that I can
> recompile them into movies when I'm done with my simulation runs.
>
> For some strange reason now before it outputs a .png file, it draws the
> file its about to save to disk in the upper lefthand corner of the
> screen, replacing the window (or windows in the case of a graph) that is
> there.  Once it saves the file the windows return.
>
> Is this a problem?  I'm not positive, but I think it is seriously
> slowing down my simulation.
>
> Thanks in advance,
>
> Darold Higa
>
> I have been getting periodic segmentation faults that I don't think I
> got before as well, but that might not be related since I'm running a
> lot more iterations now and I think something isn't getting cleaned up.
>
>
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.



--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700


                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.