[PEAK] Trellis: undetected circularity via optional rules
pje at telecommunity.com
Thu Apr 16 19:13:11 EDT 2009
At 12:37 AM 4/17/2009 +0300, Sergey Schetinin wrote:
>On Thu, Apr 16, 2009 at 18:29, Grant Baillie <grant at osafoundation.org> wrote:
> > On 15 Apr, 2009, at 11:31, Sergey Schetinin wrote:
> >> Now I wonder if this will break any trellis properties, like circular
> >> maintain rules that don't set conflicting values (the rules might
> >> initialize each other even if they are not optional, when the
> >> component is being initialized). The tests fail, but they always hang
> >> up for me anyway, so I can't really use that as a reference.
> >> So I have a question: for how many people in this list trellis tests
> >> do run successfully?
> > They hang for me, too (on Mac OS X 10.5). After I disable the tests
> > test_trellis.TestReactorEventLoop.testSequentialCalls
> > test_trellis.TestTasks.testNoTodoRollbackIntoTask
> > I still get a bunch of failures in test_sets.TestUpdateOps (although these
> > seem to pass when run by themselves).
>Um.. disabling those helps tests to finish but I still get 37 failures
>on fresh checkout, 39 failures on my working copy (apparently I broke
>something that makes discrete lazy cells become constant before
>resetting or not notifying about the reset). Plus a warning from
>SQLAlchemy on use of deprecated apis.
>Using WinXP, Py2.5.
Just as a datapoint, I don't get any test failures or hangs on my own
machine. I'm particularly confused by the set-related failures.
More information about the PEAK