[PEAK] help with more info
Phillip J. Eby
pje at telecommunity.com
Sat Mar 22 12:48:13 EDT 2008
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.)
More information about the PEAK
mailing list