[PEAK] Trellis: undetected circularity via optional rules

P.J. Eby 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 mailing list