Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ItemRepSelector should prefer unprocessed items #977

Closed
ddfreyne opened this Issue Nov 4, 2016 · 3 comments

Comments

Projects
None yet
1 participant
@ddfreyne
Copy link
Member

commented Nov 4, 2016

The ItemRepSelector does not pick items to recompile in the most efficient order.

Theory: If an item is known to have a dependency (because attempting to compiling it raised an UnmetDependency), it is more likely to have dependencies than an item that has not yet been processed yet.

For example, a blog archive page, a tag page, … will collect the compiled content of many items, and thus has many dependencies. It makes sense for Nanoc to attempt compiling all other items before re-attempting compiling the item that generated the dependency.

CC @gpakosz

@ddfreyne

This comment has been minimized.

Copy link
Member Author

commented Nov 4, 2016

Another useful enhancement is to repurpose the information in the dependency graph of the previous run. That’s something I’ve been meaning to do, but never got around to doing…

@ddfreyne

This comment has been minimized.

Copy link
Member Author

commented Nov 5, 2016

The cause of this problem is illustrated by the new ItemRepSelector spec: in the last example, the item rep selector yields the same item :a over and over again:

expect(tentatively_yielded).to eq [:a, :b, :a, :c, :a, :d, :a, :e, :a]

The reason for this is that as of Nanoc 4.3.7, the initial set of item reps to recompile that is passed to the item rep selector is not every item, but only the outdated ones. Because of this, the item rep selector does not have enough information to realise that there are other items reps that might need to be recompiled before attempting to recompile :a, and so it has to recompile :a over and over again to find out more and more dependencies.

Repurposing the dependency graph from the previous run, as mentioned before, would avoid this problem.

@ddfreyne

This comment has been minimized.

Copy link
Member Author

commented Nov 17, 2016

Fix in #985.

@ddfreyne ddfreyne closed this Nov 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.