ddfreyne changed the topic of #nanoc to: 3.6.7 (dec 9th) | web http://nanoc.ws/ | repo http://bit.ly/XE6e3G | issues http://bit.ly/VfXaSV | forum http://ho.io/n-discuss | irclog http://irclog.whitequark.org/nanoc
pavelkunc has quit [Quit: Leaving.]
prxq_ has joined #nanoc
prxq has quit [Ping timeout: 245 seconds]
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Ping timeout: 272 seconds]
prxq_ is now known as prxq
<gnufied> bobthecow: sounds horribly inefficient
<gnufied> :D
alerante has joined #nanoc
alerante has quit [Ping timeout: 246 seconds]
relix has joined #nanoc
pavelkunc has joined #nanoc
VitamineD has joined #nanoc
cDlm has joined #nanoc
VitamineD has quit [Ping timeout: 252 seconds]
cDlm is now known as VitamineD
alerante has joined #nanoc
alerante has quit [Ping timeout: 276 seconds]
relix has quit [Read error: Connection reset by peer]
relix has joined #nanoc
jugglinmike has joined #nanoc
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
<bobthecow> gnufied: "is there a way" -> "yes, here's a way"
<gnufied> :-)
<guardian> what's your usecase for mustache?
<gnufied> I don't. I keep it shaved off.
<guardian> also I have another question: what's your preferred way to automatically generate a menu from items? prefix file names with 01-, 02-, 03- etc so that it gives an order when two items are at the same level in a tree? or use yaml metadata on each item? the use case is a documentation site written with nanoc: tech writers would just drop in new .md files and they need a way to control when it lands in the overall menu/toc
<guardian> anyone alive?
relix has quit [Ping timeout: 252 seconds]
relix has joined #nanoc
<bobthecow> guardian: i'd use number prefixes. then it's obvious to everyone what order things will be in without opening files.
<bobthecow> the other option is adding yaml metadata to something to indicate what order things are in?
<bobthecow> that would make it easy to reorder things, but you'd have to add new items to the yaml
<guardian> I agree with you about "without opening files"
<bobthecow> it does make reordering a bit harder.
alerante has quit []
<ddfreyne> Ordering is an issue I haven't really solved either
<number-six> ddfreyne: bobthecow (1 day ago): thanks.
<ddfreyne> On the old nanoc site, I used prefixes for different parts of the documentation, but that was a bit icky too.
<guardian> re
<guardian> I'll try to look how open source nanoc doc sites do it
<guardian> also, I'm hesitating between taking page h1 from :title attribute then demote headers with nokogiri. Or just let tech writers start their markdown with "# My Pretty Title" and use item's :title attribute only for <head>
<bobthecow> i've done it both ways.
<bobthecow> you could write a filter that looks for an h1 and inserts the :title if it's not there?
<guardian> well
<guardian> I would like something that's "simple"
<guardian> in the sense I don't want the tech writer to wonder about "if this then that, but also this special case if the moon is full" :)
<ddfreyne> guardian: I prefer having a title attribute and no h1
<guardian> but then you either have to demote or to have a rule that says "headers start at h2"
<ddfreyne> guardian: I had that!
<ddfreyne> guardian: Also, kramdown allows you to pass a :demote param or at least something similar
<guardian> ah good to know
<guardian> I've seen nokogiri based filters in the wild
<guardian> to do that
Jutah has quit [Ping timeout: 264 seconds]
Jutah has joined #nanoc
<guardian> well bobthecow & ddfreyne, maybe I could do it the other way around: grab :title from first h1 found -- that way, there is strict mapping between # <--> h1, ## <--> h2, etc. And it's easier for our tech writers
<guardian> you're gone? :)
<bobthecow> guardian: i'd grab a backup title from the first h1
<bobthecow> that way they can specify page title independent of the h1
<guardian> yeah that's what I had in mind
<guardian> wonder how to code that within preprocess
<guardian> to support
<guardian> This is an H1
<guardian> ==========
<guardian> multiline regex match
<guardian> should be enough
<bobthecow> use nokogiri and run it over the compiled content.
<bobthecow> make a title helper which scans @item.compiled_content for h1s, then it doesn't get run until after the markdown becomes html.
<bobthecow> that also means you'd find it if someone manually created <h1>, which is also valid markdown.
<bobthecow> i.e. don't do it at preprocess, do it at runtime.
<guardian> more robust?
<bobthecow> i don't like regexing things :P
<bobthecow> don't get me wrong, regex is awesome. but give me a real parser any day.
<guardian> yeah but I would like to avoid slow downs
<guardian> and nokogiri looks heavy
<guardian> oh well I'll give it a try
<bobthecow> nokogiri's not bad. a lot of filters use it.
<bobthecow> i would probably cache the titles in something keyed off the item's hash.
<bobthecow> so that recompiles wouldn't have to look for the h1 unless it changed.
<guardian> hmmm
<guardian> now I'm curious
<guardian> who holds the hash?
<guardian> I mean the cache (hash as ruby hash)
<bobthecow> write it to a file in the tmp directory.
<bobthecow> use pstore or something.
<guardian> hmm nice
<guardian> bobthecow: so basically I could even improve my cache_bust based on pstore right? http://pastebin.com/xL35BpZn
<guardian> in that snippet @cache_bust_map is a naive and I think unsuccessful at caching hashes
<bobthecow> if you're going persist your cache between loads, it should be caching via the hash (checksum) of the item, not by its identifier.
<guardian> but when does pstore happen?
<guardian> bobthecow: in my snippet, when does the "persist cache to tmp" happen? on each call to cache_bust?
<bobthecow> inside the begin loop
<bobthecow> block rather.
<bobthecow> line 8 or so
<bobthecow> basically you only want it writing if it was a cache miss.
<guardian> I added puts "miss: #{target}" on line 4
<guardian> haha I'm seeing a miss for every single item compiled :)
<guardian> definitely not a cache :)
<guardian> I think it's because I totally don't get what's going on with @cache_bust_map ||= {} -- because @ denotes an instance member, and I'm doing that in a helper defined inside lib/cache_bust.rb
<guardian> so I kind of have no clue to which instance def cache_bust(target) gets "attached" to
<ddfreyne> It is a new instance every time an item gets compiled
<ddfreyne> SO using an instanve variable is indeed useless :)
<ddfreyne> You could attach it to @compiler,w hich will point to the same instance of Nanoc::Compiler, but it's still a bit icky
<guardian> I'm changing it to use PStore
<guardian> that's nice
<guardian> bobthecow: why where you saying key for my cache should be checksum and not identifier?
<bobthecow> if you're persisting it between builds, you need to invalidate entries if the file changes.
<bobthecow> the easiest way to do that is to use a content-based hash as the cache key.
<bobthecow> then, as long as the file's the same, the cache key will be the same.
<bobthecow> and there's already a checksum built into nanoc for every item.
<bobthecow> so use that as the key.
<guardian> and item's checksum == SHA1(uncompiled content) right?
<bobthecow> actually, you could do two-level caching.
<bobthecow> transient caching by identifier
<bobthecow> like you currently have
<bobthecow> and if that fails, you would look up the item in @items, use its checksum to read out of the cached-to-disk thing.
<bobthecow> and the next several lines.
<bobthecow> it's based on the contents and the attributes.
<bobthecow> in case you're changing attributes during preprocessing or something.
<guardian> ddfreyne: @compiler is frozen :)
<guardian> ddfreyne: how does this make you feel? http://pastebin.com/35Z4yYBn
alerante has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]