From 1fcb97e13188d85a6df6635d3b42812ca46e145b Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 21 May 2009 23:33:16 -0400 Subject: [PATCH 1/1] responses --- doc/todo/tracking_bugs_with_dependencies.mdwn | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 8eedc49e0..8268e4026 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -252,6 +252,11 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>> is to not generate perl code, but just directly run perl code that >>> populates specFuncs. +>>>> I don't think this is as bad as you make out, but your addition of the +>>>> data array will break with the recursion my patch adds in pagespec_makeperl. +>>>> To fix that I'll need to pass a reference to that array into pagespec_makeperl. +>>>> I think I can then do the same thing to $params{specFuncs}. -- [[Will]] + > * Seems that the only reason `match_glob` has to check for `~` is > because when a named spec appears in a pagespec, it is translated > to `match_glob("~foo")`. If, instead, `pagespec_makeperl` checked @@ -314,6 +319,8 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>>> If you're joining two pagespecs with 'or', you don't want a named pagespec in the first part overriding a page name in the >>>> second part. Oh, and I assume 'or' has the right operator precedence that "a and b or c" is "(a and b) or c", and not "a and (b or c)" -- [[Will]] +>>>>> Looks like its bracketed in the code anyway... -- [[Will]] + >> Secondly, it seems that there are two types of dependency, and ikiwiki >> currently only handles one of them. The first type is "Rebuild this >> page when any of these other pages changes" - ikiwiki handles this. @@ -369,8 +376,8 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>>>> the page depended on, and for each pagespec you'd want to store the list of pages that currently match it. >>>>> On refresh, you'd need to check each pagespec to see if the set of pages that match it has changed, and if >>>>> that set has changed, then rebuild the dependent page(s). Oh, and for this second type of dependency, I ->>>>> don't think you can merge pagespecs. If I wanted to know if either "*" or "link(done)" changes, then just checking ->>>>> to see if the set of pages matched by "* or link(done)" changes doesn't work. +>>>>> don't think you can merge pagespecs. If I wanted to know if either "\*" or "link(done)" changes, then just checking +>>>>> to see if the set of pages matched by "\* or link(done)" changes doesn't work. >>>>> The current system works because even though you usually want dependencies of the second type, the set of pages >>>>> referred to by a pagespec can only change if one of those pages itself changes. i.e. A dependency check of the -- 2.39.5