VitamineD has quit [Remote host closed the connection]
VitamineD has joined #nanoc
dkm has joined #nanoc
jugglinmike has joined #nanoc
VitamineD has quit [Ping timeout: 250 seconds]
jugglinmike has quit [Ping timeout: 246 seconds]
jugglinmike has joined #nanoc
<ddfreyne>
Sorry! I haven’t checked Twitter in a while (I needed a break…)
<ddfreyne>
guardian: poke
<guardian>
:)
<guardian>
just read your comment on the issue
<guardian>
you meant IRC, not Twitter right?
<ddfreyne>
Yes, sorry
<guardian>
I have few things I would like to discuss, tell me when it's proper time
<ddfreyne>
guardian: I suppose now would work. I’m at work but taking a break :)
<guardian>
ok
<ddfreyne>
guardian: You could also write it down on the mailing list, I suppose. But I’m here anyway.
<guardian>
first, remember my need for having different compilation "targets"? offline and www ?
<guardian>
offline produces urls like foo/bar/baz.html
<guardian>
while www produces urls like foo/bar/baz/index.html, that is clean urls
<guardian>
we talked about routing snapshots: I would like to debrief that idea
<guardian>
first, you can't take 2 consecutives snapshots and give them different names: at the end of filtering + layouting, I tried to snapshot :offline; snapshot :www
<ddfreyne>
Right
<guardian>
that doesn't fly, nanoc complains
<guardian>
so I started abusing :last and :post :)
<ddfreyne>
Oh, weird. What error do you get?
<guardian>
:post == :offline
<ddfreyne>
That should be possible, I think.
<guardian>
:last == :www
<guardian>
so far so good!
<guardian>
within a single compile, I could output to both output/offline/ and output/www/
<guardian>
except binary items can't have snapshots :)
<guardian>
so that falls short for images that go into nanoc's pipeline
<ddfreyne>
Yeah.
<guardian>
you can't filter them once (optimize, resize, whatever) and route them to both output/offline/ and otuput/www/
<guardian>
so in the end, I'm using NANOC_TARGET env variable, and I record that in @config at preprocess stage
<guardian>
that's my best approach so far, but that works
<guardian>
---
<ddfreyne>
guardian: nanoc 4.x actually no longer has that problem, since the #write calls are inside the #compile blocks
<ddfreyne>
But nanoc 4.x is quite WIP :)
<guardian>
I also started using guard more, but when I CTRL-C in the middle of a compilation, it seems
<guardian>
1) either guard spawns threads that go on compiling items
<guardian>
2) either I don't really know :)
<guardian>
but it doesn't stop right away
<guardian>
do you experience that when using guard-nanoc ?
<ddfreyne>
Hmmm… strange. I haven’t seen that behavior before
<guardian>
ok I'll try to reproduce
<guardian>
about the snapshots error: "Nanoc::Errors::CannotCreateMultipleSnapshotsWithSameName: Attempted to create a snapshot with a duplicate name :www for the item rep ..."
<guardian>
nanoc-3.7.5/lib/nanoc/base/compilation/item_rep_recorder_proxy.rb:76:in `block in snapshot'
<guardian>
why does items[] records a dependency again?
<guardian>
what's the typical situation for which it's necessary? a preprocess block that would create attributes based on raw content ?
<guardian>
oh well gonna read your reply on the issue :) and the links it points to
jimjimovich has joined #nanoc
<jimjimovich>
I'm wondering how to create a rep of my content that outputs the metadata as json files. I know I did it in the past, but can't find my code now. Thanks!
jugglinmike has quit [Ping timeout: 245 seconds]
jugglinmike has joined #nanoc
cDlm has joined #nanoc
<ddfreyne>
guardian: Sorry, I ran away :o
<ddfreyne>
jimjimovich: Hm, I’d say you need a filter that outputs JSON.dump(@item.attributes) and ignores the content
<ddfreyne>
class JSONFilter < Nanoc::Filter ; identifier :json ; def run(content, params={}) ; JSON.dump(@item.attributes) ; end ; end
<ddfreyne>
(haven’t tested)
<jimjimovich>
thanks!
<ddfreyne>
guardian: I’m way too tired to respond now. Let’s talk later!