Tesla Coils and Corpses 15-Aug-2014

[Daira Hopwood]

On 15/08/14 18:59, Brian Warner wrote:
> Notes from the weekly crazy-new-topics dev chat (aka "Tesla Coils and
> Corpses") for Friday 15-Aug-2014.
[...]
> "omniscient debugger": doesn't forget anything
> 
> Noether will have trail stacks: store new value and the one it replaced,

Actually, trail stack entries store the location and the old value that was
replaced.

> so you can unwind things efficiently. This is needed to provide error
> handling anyways. Nondeterministic operations must record more
> information.
> 
> The Noether spec is mostly complete, in Daira's head, but not written
> down. But she keeps adding things to the spec. Yay feature creep! :)

Boo feature creep :-( Yay unification of features!

> Invariants don't need to be checked on every turn.

But they probably will be, since we don't want to miss violations that
are present in the persistent state at the end of a turn but are
repaired by a subsequent turn. (Such violations are always bugs because
processing of a different message could potentially have observed the
inconsistent state.)

The advantage is in not having to check invariants on every mutation.

> once a violation is
> discovered, you can rewind back to the last correct turn and then step
> forward until the first turn that violates the invariant.

... until the first mutation that violates the invariant.

> This is visible to the debugger but not to external callers.
> 
> nathan asks: could we automatically create test cases from this?
> 
> At the beginning of the turn, the invariants are passing, then it
> receives a message, then by the end of the turn the invariants are
> failing. Test case is the original state plus the message.
> 
> But the initial state may be unconstructable, at least through the
> public API: it is the result of evolution (constrained by the invariant
> checks, but may involve hidden state that can't be directly set by the
> constructor). So it's undecidable if you can use the public API to
> construct an object in that state. But maybe just present the state to
> the author and let them decide how / whether to set up an object in that
> state, for the test.

-- 
Daira Hopwood ⚥

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20140818/4a5928cd/attachment.pgp>