Implements Tracker.Computation#flush and #run (fixes #4514)

[deanrad]

For, #4514, this is my first pass at a core package PR, so feedback welcome!

[rclai]

Is it necessary to invalidate()?

[deanrad]

Tests will fail if you take it out, yes. If you trace execution through _recompute, invalidation is required for it to be recomputed.

[rclai]

Oh I see.

[mitar]

See alternative implementation at #4715.

[deanrad]

#4715 has been folded into this PR, and tests covering it have been added. @mitar - does this implementation work for you?

[mitar]

Looks great!

[glasser]

Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub.

I understand that this would be a useful feature, but I'm loathe to just quickly merge it without careful analysis, since it fundamentally changes the invariants about how tracker uses a queue to handle recomputations.

[deanrad]

So the concern is that it could no longer be taken as a given that recomputations are done in the order they were invalidated in. Well the model of understanding doesn't really change- it's still a queue, but manual line-jumping would be allowed. Perhaps if the computation were taken out of the recompute queue as well ?

[apollo-cla]

@deanius: Before we can merge your pull request, you'll need to sign the Meteor Contributor Agreement: https://contribute.meteor.com/

[mitar]

Can this get merged in?

[mitar]

@stubailo, could also this be merged in? ;-)

[tmeasday]

I'd like to add a small 2c here pointing out that in general relying on Tracker re-computations to happen in an order you'd expect can lead to surprising results anyway (e.g. iron-meteor/iron-router#576 (comment))

[mitar]

Yes, but we have been using this for few months now and it does help make computations a bit more predictable.

[tmeasday]

Oh, no I was supporting your argument and providing a counter to @glasser's point, is all. Just an anecdote of course.

[mitar]

;-)

[stubailo]

Perhaps if the computation were taken out of the recompute queue as well?

This sounds like a good idea to me, otherwise using flush or run would result in at least 2 re-runs guaranteed, right?

[mitar]

But you have to keep it in the queue because maybe the recomputation again invalidated the queue itself.

There is already a check in _recompute which checks if a computation is invalidated or not. If it is not, it will skip it. So leaving it in the queue I think makes code much cleaner, but the result is the same. On the other hand, if it is invalidated, it is already there.

Or are you saying that we should remove it from the queue and if it gets invalidated again it should be put at the end of the queue? That would be pretty tricky to implement? Mingling with the queue?

[stubailo]

No, I think you're right - I didn't look at it in enough depth.

[mitar]

So it will not be rerun twice, but it will be tried to be run the second time.

So the only thing I see is that if it does got invalidated in meantime again, then it will be in the original order, not in the new order. But I also even think that this is OK. From outside it will just look like the computation was run wherever was meant to be run initially. That extra "flush" somebody called on it was out of band anyway.

[stubailo]

I'd like to get one more pair of eyes on this to confirm that it's not going to explode some internals - perhaps @avital?

[zol]

Please remove this comment as docs have been refactored.

[zol]

Hey guys,

We had another look at this old PR and are happy to merge it. As we have a new docs system, I've commented on the code to remove references to the old docs.meteor.com (referenced via two code comments). Please rebase this PR against the latest devel, make sure our CI tests pass (this should now be working) and we'll be good to go.

[mitar]

Great news. @deanius, do you have time to look into this?

[deanrad]

Wow, yeah @mitar, I'll make some time for it this evening.

[deanrad]

Hey @zol- you want just those 2 comments removed, right? Let me know if you want this squashed or anything. -Dean

[zol]

Yes, just those two comments removed would be great. We've had a lot of PR activity since yesterday's issue triage session so our CircleCI server is really busy. You can run meteor self-test and meteor test-packages on your local machine to see if the tests pass right away or wait 3 hours or so for this to hit Circle's queue.

[mitar]

Somebody is not paying for more parallel builds at CircleCI. ;-)

[tmeasday]

Our tests are just like.... reallly slow. We have a lot of parallelism :/

[mitar]

Do you use my runner from Blaze? It runs all the packages in parallel.

[tmeasday]

It's not the package tests, but the self tests which are the problem.

[zol]

Ok, one more thing to do @deanius - Can you please rebase this to be off of current devel? This branch is off an old commit that doesn't include the CI integration (hence CI is reporting no test commands were found). It should be as easy as (assuming you have a remote called upstream pointing here):

# optionally
git remote add upstream https://github.com/meteor/meteor

git fetch upstream
git rebase upstream/devel
git push --force

[deanrad]

@zol - rebase and squash complete.

[zol]

Thanks @deanius - merged!

[tmeasday]

Can we get a PR to vNEXT of meteor/docs for the docs part? Appreciated
On Thu, 12 May 2016 at 10:21 AM, Zoltan Olah notifications@github.com
wrote:

Thanks @deanius https://github.com/deanius - merged!

—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
#4710 (comment)