RE: [Swarm-Support] batchswarm problem - getActivity

[Corinne Coen]

Marcus,
Your thoughts are very helpful.  I agree that there is no real error message
there.  I am doing the debugging because there is one variable in my model
which works in GUI mode but does not work in batch mode.  I am at a complete
loss for why this variable would perform differently -- it is not just a
reporting difference.

The funny "not an error" message I sent you is the only indication I have of
BatchSwarm.m doing anything interesting.  Although I can use debugging
messages in my code, since the GUI works fine, I don't get any printf's when
I run it.  And, of course, my batch mode runs in the background.

Is there any way to invoke error messages while running batch mode?
Thanks,
Corinne


-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf
Of Marcus G. Daniels
Sent: Monday, March 24, 2008 10:09 PM
To: Swarm Support
Subject: Re: [Swarm-Support] batchswarm problem - getActivity

Hi Corinne,
> With my code as is, this is the error message.
>
Hmm, I don't see any error message there.  You've set a breakpoint in 
your program (apparently in a stopRunning method), and it hits it.  This 
seems completely reasonable.    Do you have reason to believe something 
bad happens there?

You should be aware that GDB can misinform you and often will.   This 
comes about because the compiler's optimizer can make the executable 
code difficult to follow in a precise way (as it may restructure it for 
efficiency gains).   Also there's the possibility of the stack being 
destroyed by dramatic failures of the code, e.g. array overruns.   These 
problems are fairly common because both Swarm and models built with 
Swarm will use lots of optimization.

The main way I tend to use debuggers is to attach to a long running 
process to look around in it.   When I have control of the source code 
(such as with a model), it's often easier to put in diagnostic messages 
in the code itself and then make a log to study, or just watch it print 
out those messages to the console.   

One way to make this easier to manage is to use this kind of idiom in 
your code:

#ifdef DEBUG
  raiseEvent (WarningMessage, "Here I am");
#endif

Then compile with:

make EXTRACPPFLAGS=-DDEBUG

That way, you can leave the diagnostics in your code, and activate them 
when needed.   Afterwards removing the object files and rebuilding with 
simply "make" will not put them in and thus won't produce noise or slow 
your code.   raiseEvent is just a macro in Swarm that tells you what 
line and file the diagnostic is in, simple printfs are otherwise just as 
good.

Marcus
_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support