Correct way to force a dependency?

[Warren Knight]

I am trying to use the Capturing helper to capture summary information from a set of children pages to be displayed on the parent's page.

If I wipe out the contents of the output directory and compile everything: it works as expected.
If I then make a change to the parent page and then either compile with nanoc or with the autocompiler: I do not get the summary information but I still get the title attribute.
If I wipe out the tmp directory and compile: it works as expected

I have tried creating a ChildrenDependencyFilter which explicitly depends on the children but it does not seem to affect the output.  How do I either force the recompilation of the children pages or ensure that the content_for_summary attribute is preserved?

Filters:

filter :childrendependencyfilter
filter :erb
filter :asciidoc

Child page:

<% content_for :summary do %>
  Summary text here
<% end %>
<%= content_for(@item, :summary) %>

Parent page:

<% for @child in @item.children %>
http:<%= @child.identifier %>[<%= @child[:title] %>]:: <%= content_for(@child,:summary) %>

<% end %>

Attempted filter to force dependency:

  class ChildrenDependencyFilter < Nanoc::Filter
    identifier :childrendependencyfilter
    type :text
    def run(content, params={})
       print "#{item.children.length}\n"
       if @item.children.length > 0
        depend_on(@item.children)
       end
       content
    end
  end

[Denis Defreyne]

Hi Warren,

This looks like a bug in nanoc (or at least the capturing helper) to me. Dependency handling should automatically happen behind the scenes everywhere, so there should be no need to declare them manually. It is a bit late here at the moment, but I will take a proper look at the problem tomorrow.

Cheers,

Denis

> --
> You received this message because you are subscribed to the nanoc discusssion group.
>
> To post to this group, send email to na...@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en

[Warren Knight]

Thanks,

Since it looks like a bug I created a small test project that shows the problem.  The runtest.sh script will reproduce the files in the testresults directory.

Cheers,
  W

[Denis Defreyne]

Hi Warren,

This should fix it: <https://github.com/ddfreyne/nanoc/compare/730361a6...290dd091>. The issue that you were experiencing is the result of a recent bugfix (https://github.com/ddfreyne/nanoc/issues/111). The fix for your issue will be part of nanoc 3.3.7.

Can you double-check whether this fix works for you? With a patched nanoc, your test case gives the right results.

Cheers,

Denis

> --
> You received this message because you are subscribed to the nanoc discusssion group.
>
> To post to this group, send email to na...@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en

> <capturetest.tgz>

[Warren Knight]

Hi Denis,

I am seeing the same behavior on both the test project and my full project.  I verified that the updated file is being run.  Is it possible that something else changed since 3.3.6 that could be affecting this?  I see how the recent bugfix could cause this problem.  Since nanoc debug shows the proper dependencies it looks like if a file uses content_for then its dependencies need to regenerate the CaptureStore. I am new to ruby and gems but comfortable with other languages so I will grab the master branch and see if it corrects the situation.  Thanks again for the help and a great package.

Cheers,
  W

On Sunday, May 6, 2012 7:09:33 AM UTC-5, Denis Defreyne wrote:

Hi Warren,

This should fix it: <https://github.com/ddfreyne/nanoc/compare/730361a6...290dd091>. The issue that you were experiencing is the result of a recent bugfix (https://github.com/ddfreyne/nanoc/issues/111). The fix for your issue will be part of nanoc 3.3.7.

Can you double-check whether this fix works for you? With a patched nanoc, your test case gives the right results.

Cheers,

Denis



On 06 May 2012, at 05:47, Warren Knight wrote:

> Thanks,
>
> Since it looks like a bug I created a small test project that shows the problem.  The runtest.sh script will reproduce the files in the testresults directory.
>
> Cheers,
>   W
>
> --
> You received this message because you are subscribed to the nanoc discusssion group.
>  
> To post to this group, send email to na...@googlegroups.com
> To unsubscribe from this group, send email to

> nanoc+unsubscribe@googlegroups.com

[Warren Knight]

Hi Denis,

I verified the problem still occurs with the head of the 3.3.X branch and I have spent a little time familiarizing myself with the code.  I don't see how you are going to meet the conflicting requirements of issue 111 and having content_for remember information of other pages from previous runs.  Off the top of my head the only thing I can think of is a reverse dependency graph for content_for that forces the children (source pages) to be recompiled when the parent (summary page) needs to be rebuilt.  I assume you will still need a check for the issue 111 case where the source and summary are on the same page.

For now I will make my first attempt at creating a command to be to reimplement the -force option (I read about in another post) and regenerate the full site each time (since it is small).  I will keep an eye out for any fixes you add. 

Updated capturetest attached

Cheers,
  W

[Denis Defreyne]

Hi Warren,

Now that I dive deeper into the issue, it indeed appears that there is
more to it than I just thought. The problem occurs when captured
content from a cached item is requested: in this case, the captures
store will be empty and it will appear that nothing is captured at
all. A fix for this would be to ask the compiler to forcefully
recompile the item, ignoring any cached data.

There is no immediate easy way around this issue. The capturing helper
has always been a tricky one to get right, because it really operates
outside the normal nanoc workflow. Because of this, I recommend not
using the capturing helper. I will nonetheless still fix this issue,
but it is not unlikely that the capturing helper will be deprecated at
some point.

Regards,

Denis

> --
> You received this message because you are subscribed to the nanoc
> discusssion group.
>
> To post to this group, send email to na...@googlegroups.com
> To unsubscribe from this group, send email to

> nanoc+un...@googlegroups.com

[Warren Knight]

Thanks,

After thinking about it more, creating a summary attribute in yaml at the start of each page makes more sense for what I am trying to do and it compiles correctly each time. So this one isn't an issue for me now.

Cheers,
  W

[Denis Defreyne]

Hi,

I’ve just fixed this issue (in a very ugly way, sadly) so this should no longer be a problem. nanoc’s current architecture makes it difficult to fix this issue properly. However, once nanoc gets support for parallel compilation (which will require some re-engineering), the implementation of the fix should become a lot cleaner.

Cheers,

Denis