cumulativeEF weird behavior

[Filip Konvička]

>  > Hackers, please, how do you usually debug ozengine?  Do you simply load 
>  > ozengine.exe into gdb and set a breakpoint somewhere in, say, scheduling.cc?
> 
> I've never (thankfully) debugged constraint propogators. This might
> all be obvious to you, but you asked ....

You know, I do gdb debugging all the time, but I have never debugged 
such a thing, so I wanted to know whether there are any special traps 
and pitfalls...I definitely appreciate all of your comments!

> To build a debugging emulator add --enable-opt=debug to configure.
> You might want to do this after you have first built mozart without
> debugging, then just rebuild the emulator. (Compiling all the oz files
> with a debugging emulator used to be really slooow, but its not bad on
> modern machines now).

Mozart compiled quite quickly on my P4/1GB RAM on WinXP+Cygwin, I was 
rather surprised :-)

So I think I'll recompile the emulator with the --enable-opt=debug. What 
do I need to do after I re-make in the emulator directory? Is it 
sufficient to copy the new emulator.dll into the installation directory? 
Or should I run the whole "make install"?

> Start the OPI and grab the emulator process with gdb. 

I was thinking of running ozengine from gdb...the OPI approach might be 
better because I do not need to reenter gdb each time I re-run the script.

> Set your breakpoints and away you go.  From a quick look, I think
> sched_cpIterateCap is the start builtin you are interested in. 

Yes, I guessed the same. Fortunately, I'm quite familiar with C++ - 
definitely more than with Oz :-) Nevertheless I like Oz very much!

> Presumably the propagator will be called over and over, and you might
> need to set watchpoints to stop at an interesting time.
>
> Often,  it can be easier to just instrument with printfs and analyse
> the log later at your leisure, at least to narrow down the problem and
> be sure you understand the flow of control.

This seems like ordinary C/C++ debugging with gdb.

> There are other tricks (such as being able to print the mozart
> bytecode being executed at the time of a breakpoint).

Huh, this seems too much advanced for me! But if everything else fails...

 > Let us know when you have more specific needs / problems.
 > And let us know your tips for debugging the emulator!

Sure, thank you very much for support!

Filip