[PEAK] help with more info

[Phillip J. Eby]

At 06:19 PM 3/22/2008 +0200, Peter Damoc wrote:
>I've started getting this error:
>
>AttributeError: Constants can't be changed
>The problem is that I don't know what I'm doing wrong.
>I used Trellis to manage some computations based on an external 
>object that contains a dictionary.
>In a resync method I'm pushing the information inside a Trellis Dict object.
>Everything worked fine till today when for some cases I get the above error.
>
>How can I get more information about what my code is trying do to illegally?
>How can I get the name of the constant that its trying to change?

Okay, here's what's happening.  You're actually getting a different 
error in your application; this is just masking it, because it's an 
error that happens during the rollback caused by the first 
error.  The specific issue is that an undo operation is adding a 
listener back to a cell that's become Constant, because it had no 
listeners.  (What's weird about that is that the setting of the cell 
to Constant should have been undone before it got back to this point 
in the rollback.  So something else weird is going on.)


>here is a more complete trace:
>
>File "c:\Projects\BPM\patient_display.py", line 133, in OnBiodynamic
>     dlg.panel.mp.resync(dlg.panel.meas)
>   File "<peak.events.trellis.wrap wrapping 
> modules.biodynamic.measurements.resync at 0x01CC97F0>", line 5, in resync
>   File 
> "c:\python25\lib\site-packages\Trellis-0.6a1-py2.5.egg\peak\events\stm.py", 
> line 466, in atomically
>     return super(Controller,self).atomically(self._process, func, args, kw)
>   File 
> "c:\python25\lib\site-packages\Trellis-0.6a1-py2.5.egg\peak\events\stm.py", 
> line 186, in atomically
>     self.cleanup(*sys.exc_info())
>   File 
> "c:\python25\lib\site-packages\Trellis-0.6a1-py2.5.egg\peak\events\stm.py", 
> line 309, in cleanup
>     return super(Controller, self).cleanup(*args)

If you use pdb.pm() to get into this traceback, and walk up to this 
stack frame, you should be able to look at 'args' to find out what 
the original exception was that started the problem.  There really 
should be a better way to handle this, though.

A possible workaround for the Constant part of the problem would be 
to ensure that any rule() in your application also has a value(); 
that will ensure that the cell can never become constant (because 
it's writable).  But I wouldn't try that unless the above doesn't 
resolve your issue.

(It's too bad there's no way to link multiple exceptions together in 
Python right now, it'd sure come in handy here.  That way, you could 
see the first exception as well as the cleanup exception.)