Re: Re: trellis.Set.discard

At 01:06 AM 10/12/2008 +0300, Sergey Schetinin wrote:
>There's more. For task, maintain rule runs twice, then undo run for
>both times. So it not run-undo-run or even run-undo-run-undo it's
>run-run-undo-undo. For @atomically it also runs twice, but without
>undo. How the same rule manages to run twice without undo?

Because the first run is inside type(CV).__call__ - it's an 
initializer that's supposed to be treated as if its run happened in a 
*previous* recalc - and it should never be undone.

>It appears that due to this code in run_rule:
>
>         old = self.current_listener
>         self.current_listener = listener
>         try:
>             [...]
>             if old is not None:
>                 [...]
>             else:
>                 if initialized:
>                     self.has_run[listener] = self.savepoint()
>                     [...]
>
>when we create CV instance in @atomically variant, there's no
>current_listener and when the Cell for maintain initializes it isn't
>recorded in has_run and when .v changes that allows it to be scheduled
>to run one more time without adding it to to_retry, and thus without
>rollback , which can't be right.

Actually, that part *is* right, or at least, is perfectly as 
designed.  The problem is that .future attributes can save a 
savepoint that points back into the middle of the first execution.


>For task variant, the same code also works without adding the cell to
>has_run (but because of a different condition), so when the
>TaskCell.do_run schedules the dependent rules, it schedules the
>maintain rule without to_retry as well. I'm not sure yet, why the undo
>run in this case at all.

Yes, that's really the question: why is an undo happening in the 
first place?  That's the part that makes no sense to me.

Okay, so I put a trace in the place where retry occurs, and I see the 
following:

.maintain --wrote--> .s.to_add --wasreadby--> .s._data

And since .s._data has apparently already run once, it has to be re-run.

What this doesn't explain is why this *doesn't* happen in the non-task case.



>And savepoints in "futures" do seem to be broken, but for things like
>tasks and @modifiers can they even be fixed?

I don't know.  I also don't know if perhaps there's a problem here 
with how "initializing" of rules is working.