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.