[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Swarm-Support] batchswarm problem - getActivity
From: |
Corinne Coen |
Subject: |
RE: [Swarm-Support] batchswarm problem - getActivity |
Date: |
Tue, 25 Mar 2008 11:44:22 -0400 |
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
- [Swarm-Support] batchswarm problem - getActivity, Corinne Coen, 2008/03/24
- Re: [Swarm-Support] batchswarm problem - getActivity, Marcus G. Daniels, 2008/03/24
- RE: [Swarm-Support] batchswarm problem - getActivity,
Corinne Coen <=
- Re: [Swarm-Support] batchswarm problem - getActivity, Marcus G. Daniels, 2008/03/25
- Message not available
- Re: [Swarm-Support] batchswarm problem - getActivity, Marcus G. Daniels, 2008/03/28
- RE: [Swarm-Support] batchswarm problem - getActivity, Corinne Coen, 2008/03/28
- Re: [Swarm-Support] batchswarm problem - getActivity, Marcus G. Daniels, 2008/03/28
- RE: [Swarm-Support] batchswarm problem - getActivity, Corinne Coen, 2008/03/30
- Re: [Swarm-Support] batchswarm problem - getActivity, Marcus G. Daniels, 2008/03/30
Message not available