From 3e298365934ba928700d01730be8649bd72ae9b6 Mon Sep 17 00:00:00 2001 From: joey Date: Wed, 25 Jul 2007 01:55:45 +0000 Subject: move some bugs to todo items add a wishlist tag, that can be used to separate some todos off onto a wishlist page --- doc/bugs/Add_label_to_search_form_input_field.mdwn | 13 ---- doc/bugs/Buggy_dependency_graph.mdwn | 80 --------------------- .../Post-compilation_inclusion_of_the_sidebar.mdwn | 24 ------- doc/bugs/Problem_with_toc.pm_plug-in.mdwn | 2 +- doc/bugs/format_bug.mdwn | 2 + doc/todo.mdwn | 5 +- doc/todo/Add_label_to_search_form_input_field.mdwn | 21 ++++++ doc/todo/Buggy_dependency_graph.mdwn | 82 ++++++++++++++++++++++ .../Post-compilation_inclusion_of_the_sidebar.mdwn | 30 ++++++++ doc/wishlist.mdwn | 6 ++ 10 files changed, 145 insertions(+), 120 deletions(-) delete mode 100644 doc/bugs/Add_label_to_search_form_input_field.mdwn delete mode 100644 doc/bugs/Buggy_dependency_graph.mdwn delete mode 100644 doc/bugs/Post-compilation_inclusion_of_the_sidebar.mdwn create mode 100644 doc/todo/Add_label_to_search_form_input_field.mdwn create mode 100644 doc/todo/Buggy_dependency_graph.mdwn create mode 100644 doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn create mode 100644 doc/wishlist.mdwn (limited to 'doc') diff --git a/doc/bugs/Add_label_to_search_form_input_field.mdwn b/doc/bugs/Add_label_to_search_form_input_field.mdwn deleted file mode 100644 index b7afc61a4..000000000 --- a/doc/bugs/Add_label_to_search_form_input_field.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -The default searchform.tmpl looks rather bare and unintuitive with just an input field. - -The patch below adds a label for the field to improve usability: - - --- templates/searchform.tmpl.orig Fri Jun 15 15:02:34 2007 - +++ templates/searchform.tmpl Fri Jun 15 15:02:41 2007 - @@ -1,5 +1,6 @@ -
-
- + - - - \ No newline at end of file diff --git a/doc/bugs/Buggy_dependency_graph.mdwn b/doc/bugs/Buggy_dependency_graph.mdwn deleted file mode 100644 index 116a2aea4..000000000 --- a/doc/bugs/Buggy_dependency_graph.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -I think there is a problem in my "dependency graph". As an example, -[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index -ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index) -(note that the site changed since this index was generated). - -Some **HUGE** dependencies appear, clearly non optimal, like - - depends = A｜ B | A | C | A | D | A | E | A | F | A | G | .... - -or - - depends= A | B | C | D | A | B | C | D | A | B | C | D | .... - -Couldn't isolate the cause, but some sources for this problem may be: - -* related to the img module -* easily observable in my sire because one of my pages includes 80 resized images - -Other special things in my templates and site: - -* a sidebar with \[[include pages="notes/\*" template=foo]] while notes.mdwn has - a \[[include pages="notes/*"]] and uses the sidebar; removed it, doesn't change -* a template (biblio.tmpl) calling the "img" plugin with a template parameter as the - image filename; removed it, doesn't change -* some strange games with tags whose page calls a "map" directive to show other tags - shile tags are also used in tagclouds (in the sidebar and in the main pages) -* ... - -I observed these problems (same *kind*, I didn't check in details) on - -* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1 -* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04 - -I can think about reducung the size of my wiki source and making it available online for analysis. - --- NicolasLimare - -> As long as these dependencies don't grow over time (ie, when a page is -> edited and nothing changed that should add a dependency), I wouldn't -> worry about them. There are many things that can cause non-optimal -> dependencies to be recorded. For one thing, if you inline something, ikiwiki -> creates a dependency like: -> -> (PageSpec) or (file1 or file2 or file3 ...) -> -> Where fileN are all the files that the PageSpec currently matches. (This -> is ncessary to detect when a currently inlined file is deleted, and know -> the inlining page needs an update.) Now consider what it does if you have -> a single page with two inline statements, that inline the same set of -> stuff twice: -> -> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...) -> -> Clearly non-optimal, indeed. -> -> Ikiwiki doesn't bother to simplify complex PageSpecs -> because it's difficult to do, and because all they use is some disk -> space. Consider what ikiwiki uses these dependencies for. -> All it wants to know is: does the PageSpec for this page it's considering -> rebuilding match any of the pages that have changed? Determining this is -> a simple operation -- the PageSpec is converted to perl code. The perl -> code is run. -> -> So the total impact of an ugly dependency like this is: -> -> 1. Some extra data read/written to disk. -> 2. Some extra space in memory. -> 3. A bit more data for the PageSpec translation code to handle. But that -> code is quite fast. -> 4. Typically one extra function call when the generated perl code is run. -> Ie, when the expression on the left-hand side fails, which typically -> happens after one (inexpensive) function call, it has to check -> the identical expression on the right hand side. -> -> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier -> (or improved `pagespec_merge()` function) could be written and improve -> ikiwiki's memory and disk usage, but would it actually speed it up any? -> We'd have to see the code to the simplifier to know. -> -> --[[Joey]] diff --git a/doc/bugs/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/bugs/Post-compilation_inclusion_of_the_sidebar.mdwn deleted file mode 100644 index 129bb7de9..000000000 --- a/doc/bugs/Post-compilation_inclusion_of_the_sidebar.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -In some sites (mine, for example), the pages are quasi-static, while the sidebar must be updated at each commit -(because it contains some lists, like "last posts" or "last updates", or a tagcloud). As this sidebar is included -in every page of the site, many commits can potentialy leat to a full re-compilation.... - -I think a sidebar included after the compilation (via a SSI mechanism for example) would make sense and -reduce the dependencies. - -Different things could be possible: - -* output as .shtml instead of .html -* ignore the sidebar->page dependency links -* consider the *real* dependencies; pageA may include the title (only) of pageB, but don't need to be recompiled -after each typo correction on pageB. - -shtml output with open cgi web access is a potential security hole and can DoS the site, but it's not a problem for a -single-editor site. - -NicolasLimare - -> This is a good idea, though sadly not portable enough to be the default. -> Especially if the only way to do it is with .shtml. -> But I really like the idea of not rebuilding the sidebar all the time. -> Definitly a TODO, for me, if I can figure out how to do it. Patches -> eagerly accepted. --[[Joey]] diff --git a/doc/bugs/Problem_with_toc.pm_plug-in.mdwn b/doc/bugs/Problem_with_toc.pm_plug-in.mdwn index 88516780e..a5fe6b923 100644 --- a/doc/bugs/Problem_with_toc.pm_plug-in.mdwn +++ b/doc/bugs/Problem_with_toc.pm_plug-in.mdwn @@ -29,4 +29,4 @@ Here is a patch for toc.pm for producing non-empty 'a' elements. + $page.="$text"; } else { - $page.=$text; \ No newline at end of file + $page.=$text; diff --git a/doc/bugs/format_bug.mdwn b/doc/bugs/format_bug.mdwn index e8971076f..3d4b4a94e 100644 --- a/doc/bugs/format_bug.mdwn +++ b/doc/bugs/format_bug.mdwn @@ -21,3 +21,5 @@ encouraging. > do that, use the form to generate a new per-bug page..) > --[[Joey]] + +Marking this [[done]] since it's not a ikiwiki bug directly. diff --git a/doc/todo.mdwn b/doc/todo.mdwn index a2211ba2c..01c4cf158 100644 --- a/doc/todo.mdwn +++ b/doc/todo.mdwn @@ -1,7 +1,8 @@ Welcome to ikiwiki's todo list. Link items to [[todo/done]] when done. -Also see the [Debian bugs](http://bugs.debian.org/ikiwiki). +Also see the [[wishlist]] and [[bugs]] pages. -[[inline pages="todo/* and !todo/done and !link(todo/done) and !todo/*/*" +[[inline pages="todo/* and !todo/done and !link(todo/done) and +!link(wishlist) and !todo/*/*" feedpages="created_after(todo/supporting_comments_via_disussion_pages)" actions=yes rootpage="todo" postformtext="Add a new todo item titled:" show=0]] diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn new file mode 100644 index 000000000..68e24b4d4 --- /dev/null +++ b/doc/todo/Add_label_to_search_form_input_field.mdwn @@ -0,0 +1,21 @@ +The default searchform.tmpl looks rather bare and unintuitive with just an input field. + +The patch below adds a label for the field to improve usability: + + --- templates/searchform.tmpl.orig Fri Jun 15 15:02:34 2007 + +++ templates/searchform.tmpl Fri Jun 15 15:02:41 2007 + @@ -1,5 +1,6 @@ + +
+ + + + + + +> I don't do this by default because putting in the label feels to me make +> the action bar too wide. YMMV. What I'd really like to do is make the +> _content_ of the search field say "search". You see that on some other +> sites, but so far the only way I've seen to do it is by inserting a +> nasty lump of javascript. --[[Joey]] + +[[wishlist]] diff --git a/doc/todo/Buggy_dependency_graph.mdwn b/doc/todo/Buggy_dependency_graph.mdwn new file mode 100644 index 000000000..980435111 --- /dev/null +++ b/doc/todo/Buggy_dependency_graph.mdwn @@ -0,0 +1,82 @@ +I think there is a problem in my "dependency graph". As an example, +[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index +ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index) +(note that the site changed since this index was generated). + +Some **HUGE** dependencies appear, clearly non optimal, like + + depends = A｜ B | A | C | A | D | A | E | A | F | A | G | .... + +or + + depends= A | B | C | D | A | B | C | D | A | B | C | D | .... + +Couldn't isolate the cause, but some sources for this problem may be: + +* related to the img module +* easily observable in my sire because one of my pages includes 80 resized images + +Other special things in my templates and site: + +* a sidebar with \[[include pages="notes/\*" template=foo]] while notes.mdwn has + a \[[include pages="notes/*"]] and uses the sidebar; removed it, doesn't change +* a template (biblio.tmpl) calling the "img" plugin with a template parameter as the + image filename; removed it, doesn't change +* some strange games with tags whose page calls a "map" directive to show other tags + shile tags are also used in tagclouds (in the sidebar and in the main pages) +* ... + +I observed these problems (same *kind*, I didn't check in details) on + +* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1 +* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04 + +I can think about reducung the size of my wiki source and making it available online for analysis. + +-- NicolasLimare + +> As long as these dependencies don't grow over time (ie, when a page is +> edited and nothing changed that should add a dependency), I wouldn't +> worry about them. There are many things that can cause non-optimal +> dependencies to be recorded. For one thing, if you inline something, ikiwiki +> creates a dependency like: +> +> (PageSpec) or (file1 or file2 or file3 ...) +> +> Where fileN are all the files that the PageSpec currently matches. (This +> is ncessary to detect when a currently inlined file is deleted, and know +> the inlining page needs an update.) Now consider what it does if you have +> a single page with two inline statements, that inline the same set of +> stuff twice: +> +> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...) +> +> Clearly non-optimal, indeed. +> +> Ikiwiki doesn't bother to simplify complex PageSpecs +> because it's difficult to do, and because all they use is some disk +> space. Consider what ikiwiki uses these dependencies for. +> All it wants to know is: does the PageSpec for this page it's considering +> rebuilding match any of the pages that have changed? Determining this is +> a simple operation -- the PageSpec is converted to perl code. The perl +> code is run. +> +> So the total impact of an ugly dependency like this is: +> +> 1. Some extra data read/written to disk. +> 2. Some extra space in memory. +> 3. A bit more data for the PageSpec translation code to handle. But that +> code is quite fast. +> 4. Typically one extra function call when the generated perl code is run. +> Ie, when the expression on the left-hand side fails, which typically +> happens after one (inexpensive) function call, it has to check +> the identical expression on the right hand side. +> +> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier +> (or improved `pagespec_merge()` function) could be written and improve +> ikiwiki's memory and disk usage, but would it actually speed it up any? +> We'd have to see the code to the simplifier to know. +> +> --[[Joey]] + +[[tag wishlist]] diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn new file mode 100644 index 000000000..7586c060b --- /dev/null +++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn @@ -0,0 +1,30 @@ +In some sites (mine, for example), the pages are quasi-static, while the sidebar must be updated at each commit +(because it contains some lists, like "last posts" or "last updates", or a tagcloud). As this sidebar is included +in every page of the site, many commits can potentialy leat to a full re-compilation.... + +I think a sidebar included after the compilation (via a SSI mechanism for example) would make sense and +reduce the dependencies. + +Different things could be possible: + +* output as .shtml instead of .html +* ignore the sidebar->page dependency links +* consider the *real* dependencies; pageA may include the title (only) of pageB, but don't need to be recompiled +after each typo correction on pageB. + +shtml output with open cgi web access is a potential security hole and can DoS the site, but it's not a problem for a +single-editor site. + +NicolasLimare + +> This is a good idea, though sadly not portable enough to be the default. +> Especially if the only way to do it is with .shtml. +> But I really like the idea of not rebuilding the sidebar all the time. +> Definitly a TODO, for me, if I can figure out how to do it. Patches +> eagerly accepted. +> +> I have implemented a htmlext configuration item, that lets you control +> what extension ikiwiki uses for output html pages. So in theory, a +> sidebar could be done as you describe using .shtml. --[[Joey]] + +[[wishlist]] diff --git a/doc/wishlist.mdwn b/doc/wishlist.mdwn new file mode 100644 index 000000000..0c67fa975 --- /dev/null +++ b/doc/wishlist.mdwn @@ -0,0 +1,6 @@ +These [[todo]] items constitute a wishlist of all kinds of features and +improvements people would like to see in ikiwiki. Good patches for any of +these will likely be accepted. + +[[inline pages="todo/* and !todo/done and !link(todo/done) and +link(wishlist) and !todo/*/*" archive=yes show=0]] -- cgit v1.2.3