Re: Error reporting in Java based Swarm

[Marcus G. Daniels]

>>>>> "MN" == Murali Nandula <address@hidden> writes:

MN> When some error occurs in the simulation and it stops, swarm dumps
MN> the next scheduled event as error. (Although, the reason for
MN> simulation to stop is a different one.) 

Out of curiousity, what was it?  The goal is to tighten up the typing
to Swarm interfaces and make it harder for native crashes to happen.

MN> Initially, I ended up searching for error in a wrong place!  When
MN> run in debugging mode, I can catch the exact reason for the halt
MN> of the simulation. Did anyone face a similar problem before?  I
MN> would appreciate if someone can suggest a workaround or a fix.

Hmm, it isn't clear to me this is a bug.  It is hard to track DLL
loading in GDB under Windows, but for segfault-like crashes, my
experience is that gdb does a decent job.  I must admit that when have
to debug something hairy in Swarm itself which results from a Java
app, I go straight to a Debian or Solaris box, since GDB on these
platforms is so much better, e.g. there are hooks for monitoring the
loading of shared libraries, a working `attach', interrupts work
right, etc.

I guess you know this, but for the benefit of others, here's the way
to run a Java model within GDB:

JAVASWARMGDB=gdb javaswarm StartHeatbugs

One of the long-standing goals of the Swarm project is to provide
transparent, high-performance distribution of concurrent events across
CPUs.  When we do this, the activity [Objective C] library may well
be re-written so that, even if it isn't implemented in Java, it can
target the JVM (without native code).

But right now, there is a more pressing need for usability
improvements to Swarm, and this work is not scheduled.  Part of making
the usability improvements is to more-or-less eliminate the need for
the current gui, objectbase, simtools, simtoolsgui, space, and
analysis libraries, i.e. turn Swarm inside out.

In the next release of Swarm, even the collections library won't be
needed by Java users.  For example, Java heatbugs now uses
java.util.List.  Swarm now has specialized backend `Action' support
for homogeneous Java ForEachAction sets that won't involve
cross-language lookups over and over.

The Swarm GUI library is little more than an Objective C layer on Tk.
It has poor performance in some cases because of the way it often issues
commands via the Tcl interpreter.  However, it has the advantage
of working and being fairly well-debugged.

Objectbase now provides probes and veneer for `Swarm'.  It's existence
is unfortunate and purely historical; these features will move into
defobj and activity, respectively.

Use of simtools doesn't really make sense in the Java context as there
are better ways to load and save objects, sort, select, etc. using
off-the-shelf Java libraries. 

simtoolsgui provides ControlPanel, ProbeDisplays, and some composite
widgets -- there's nothing here implementation-wise worth keeping.

Finally, the space and analysis libraries don't do all that much.  I think
we can do a much better job by integrating Swarm smoothly with 
visualization and statistical packages/libraries. 

The reason for the Java layer on the existing Swarm is that all
this will take time given our current resources (me), and meanwhile
we need something that works, and is aligned with the same interfaces
the Objective C users know.  The idea is to keep the old interfaces
around indefinitely, but to provide faster, more powerful, and easier
to use Java alternatives, preferably leveraging as many off-the-shelf
(free) third party Java libraries as possible.

                  ==================================
   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.