06:33 <ddfreyne> VitamineD: BTW, I removed the recommendation to switch to item.identifier.extension -- item[:extension] will work fine.

07:32 <nanoc-gh> [nanoc] ddfreyne pushed 2 new commits to item-rep-writer: http://git.io/vkSt5

07:32 <nanoc-gh> nanoc/item-rep-writer e48c280 Denis Defreyne: Use FakeFS

07:32 <nanoc-gh> nanoc/item-rep-writer 43374ce Denis Defreyne: Add basic item writer spec

07:41 <nanoc-gh> [nanoc] ddfreyne force-pushed item-rep-writer from 43374ce to 03dda8f: http://git.io/vkSmH

07:41 <nanoc-gh> nanoc/item-rep-writer 03dda8f Denis Defreyne: Add basic item writer spec

07:53 <nanoc-gh> [nanoc] ddfreyne pushed 2 new commits to item-rep-writer: http://git.io/vkSsJ

07:53 <nanoc-gh> nanoc/item-rep-writer 65099a4 Denis Defreyne: Pass path to :will_write_rep notification

07:53 <nanoc-gh> nanoc/item-rep-writer 733e798 Denis Defreyne: Remove snapshot from item rep writer

08:46 <kAworu> grrr guard is not working well under FreeBSD for me, even with rb-kqueue :(

14:16 <guardian> damn

14:16 <guardian> need to chase the reason why all items are oudated every time on a specific site again

14:28 <guardian> ddfreyne: to have sass interact with nanoc, I pass the current RuleContext within the Sass Engine options hash

14:29 <guardian> ddfreyne: doing so makes nanoc believe Rules has changed since the last compilation

14:31 <guardian> ddfreyne: I guess this is because invoking the checksummer on the RuleContext instance ends up calling inspect because you can't invoke Marshal.dump on it

14:31 <guardian> ddfreyne: any idea I on how I could improve that?

14:37 <guardian> ddfreyne: is this by design of the Context base class which constructors does instance_variable_set calls?

16:02 <guardian> ddfreyne: so I found out I need to tweak the checksum for a RuleContext. Currently I'm checksuming @config, @items, @layout and I'm ignoring @item, @item_rep and @site

16:02 <guardian> does that sound good to you?

20:08 <ddfreyne> guardian: RuleContext isn't really meant to be created and passed around. If you want to hand over stuff to sass, I'd pass in @item, @config, @layouts, ... manually.

20:08 <ddfreyne> guardian: Or perhaps with a new SassContext class, perhaps.

20:09 <ddfreyne> guardian: A lot of stuff which was meant to be internal-only (such as Context and RuleContext) is (or will be) changing in nanoc 4.

20:45 <guardian> ddfreyne: I did the SassContext class before you replied

20:46 <guardian> ddfreyne: it's just simpler to pass around config, items and layouts and then I can instance_eval from sass by writing in my scss e.g. nanoc('@config[:foo]') or nanoc("@items['/foo/'][:bar]")

20:46 <guardian> ddfreyne: works really well, and dependencies are all fine

20:48 <ddfreyne> guardian: That sounds useful :)

20:48 <guardian> ddfreyne: well it is at least in the following situation: I have content/css/main.scss and a bunche of content/css/_*.scss

20:49 <guardian> ddfreyne: partials are not compiled

20:49 <guardian> ddfreyne: but main.scss imports _*.scss

20:50 <guardian> ddfreyne: so while I could filter main.scss by :erb first, partials are out of touch

20:50 <guardian> ddfreyne: at that point having a nanoc(string) sass function becomes handy

20:51 <guardian> ddfreyne: because unless I overlooked something, SASS asks for a filename, not content which means there's no hook point to filter partials first before handing them to the SASS engine

20:59 <ddfreyne> I'm a little too tired to understand what exactly is going on but if it works, that's good :)

20:59 <ddfreyne> guardian: Do you think you can make a PR to nanoc master?

21:00 <guardian> I will

21:09 <ddfreyne> Thanks!