Does ShavedByBob.mdwn include itself?
-(Yeah - in IkiWiki currently links are included by include, but the idea holds. I had a good example a while back, but I can't think of it right now.)
+(Yeah - in IkiWiki currently links are *not* included by include, but the idea holds. I had a good example a while back, but I can't think of it right now.)
sigh.
> to determine what metadata, pages, etc they depend on. It is indeed
> tricky to do. More thoughts on influence lists a bit below. --[[Joey]]
+>> The big part of what makes this tricky is that there may be cycles in the
+>> dependency graph. This can lead to situations where the result is just not
+>> well defined. This is what I was trying to get at above. -- [[Will]]
+
+>>> Hmm, I'm not seeing cycles be a problem, at least with the current
+>>> pagespec terms. --[[Joey]]
+
----
### Link dependencies
that currently match it. If the list changes, the dependency is triggered.
Should be doable, but may involve more work than
-currently. Consider that a dependency on "bugs/*" currently
+currently. Consider that a dependency on `bugs/*` currently
is triggered by just checking until *one* page is found to match it.
But to store the list, *every* page would have to be tried against it.
Unless the list can somehow be intelligently updated, looking at only the
I'm using this term for the concept of a list of pages whose modification
can indirectly influence what pages a pagespec matches.
+> Trying to make a formal definition of this: (Note, I'm using the term sets rather than lists, but they're roughly equivalent)
+>
+> * Let the *matching set* for a pagespec be the set of pages that the pagespec matches.
+> * Let a *complete influence set* for a pagespec be the set of all pages whose alteration might change the matching set of that pagespec.
+> * Let the *direct influence set* be the intersection of the matching set and the complete influence set.
+> * Let the *indirect influence set* be the compliment of the direct influence set with respect to the complete influence set.
+>
+> Is that a fair definition? I don't think it quite matches your examples below unfortunately.
+> I was unsure if I should insert the word 'existing' in there in a few places. As it stands, these definitions could include sets of pages that don't exist, e.g. "*".
+> The one I'm least sure of is the definition of the direct influence set. It feels like you want something
+> like "the traditional set of things we thought about that could cause a pagespec to change", but that definition
+> is not very formal and I suspect will lead to problems. Something like "The set of pages matched by the globs in the pagespec" might be closer?
+> --[[Will]]
+
+>> I appreciate the formalism!
+>>
+>> Only existing pages need to be in these sets, because if a page is added
+>> in the future, the existing dependency code will always test to see
+>> if it matches. So it will be in the maching set (or not) at that point.
+>>
+>> The problem with your definition of direct influence set seems to be
+>> that it doesn't allow `link()` and `title()` to have as an indirect
+>> influence, the page that matches. But I'm quite sure we need those.
+>> --[[Joey]]
+
#### Examples
* The pagespec "created_before(foo)" has an influence list that contains foo.
* The pagespec "title(foo)" has an influence list that contains every page
that currently matches it. A change to any matching page can change its
- title. Why is that considered an indirect influence? Well, the pagespec
- might be used in a presence dependency, and so its title changing
- would not directly affect the dependency.
+ title, making it not match any more, and so the list is needed due to the
+ removal problem.
* The pagespec "backlink(index)" has an influence list
that contains index (because a change to index changes the backlinks).
remove a link and make it not match any more, and so the list is needed
due to the removal problem.
+>> Why doesn't this include every page? If I change a page that doesn't have a link to
+>> 'done' to include a link to 'done', then it will now match... or is that considered a
+>> 'direct match'? -- [[Will]]
+
+>>> The regular dependency calculation code will check if every changed
+>>> page matches every dependency. So it will notice the link was added.
+>>> --[[Joey]]
+
#### Low-level Calculation
One way to calculate a pagespec's influence would be to
onto the influence list. If we combine the influences from each
successful match, we get the right result.
-> This is implemented, seems to work ok. --[[Joey]]
+> This is implemented, seems to work ok. --[[Joey]]
-#### High-level Calculation and Storage
+> `or` short-circuits too, but the implementation correctly uses `|`,
+> which I assume is what you meant. --[[smcv]]
-Calculating the full influence list for a pagespec requires trying to match
-it against every page in the wiki.
+#### High-level Calculation and Storage
-I'd like to avoid doing such expensive matching redundantly. So add a
-`pagespec_match_all`, which returns a list of all pages in the whole
-wiki that match the pagespec, and also adds the pagespec as a dependency,
-and while it's at it, calculates and stores the influence list.
+Naively calculating the full influence list for a pagespec requires trying
+to match it against every page in the wiki. I'd like to avoid doing such
+expensive matching redundantly.
+
+It may be possible, for some types of pagespecs, to just try matching a
+single, arbitrary page against it, and know the full influence list has
+been obtained. It seems to be that case that if a pagespec has any
+influences, matching any page will return at least one. So if none are
+returned, we can skip trying other pages.
+
+If the influence list does not include the page that was tried, we know
+that the pagespec does not things like `link()` and `title()`, that are
+influenced by the page's own content. So it *might* be safe to not try
+matching any more pages in this case too. I think it would work for all
+current pagespec terms. There might be a hypothetical term where this
+optimisation doesn't work. We could add a special case to ensure it can
+work: If a term declares it is unfluenced by "", then it means it is
+always influenced by the matching page.
+
+Anyway, this seems worth doing: Add a `pagespec_match_all`, which returns a
+list of all pages in the whole wiki that match the pagespec, and also adds
+the pagespec as a dependency, and while it's at it, calculates and stores
+the influence list.
It could have an optional sort parameter, and limit parameter, to control
how many items to return and the sort order. So when inline wants to
> I've implemented influence calculation in `add_depends`. As expected,
> it means rather a lot more work, and makes some things much slower.
-> Optimisation via `pagespec_match_depends` next.. --[[Joey]]
+> Optimisations next.. --[[Joey]]
#### Influence types
For example, "backlink(foo)" has an influence of foo, of type links.
"created_before(foo)" also is influenced by foo, but it's a presence
type. Etc.
+
+> This is an interesting concept that I hadn't considered. It might
+> allow significant computational savings, but I suspect will be tricky
+> to implement. -- [[Will]]
+
+>> It was actually really easy to implement it, assuming I picked the right
+>> dependency types of course. --[[Joey]]