<guardian>
ddfreyne: rule memory is based on inspect right?
<ddfreyne>
guardian: I think so, but I can't tell with 100% certainty (it's not ideal if it uses inspect, but there's no solution that is immediately better)
<darix>
ddfreyne: is it possible to overwrite the code that will build the initial nanoc::itemsarray?
<guardian>
ddfreyne: I think it's based on inspect, and happens in rules_collection.rb:190
<darix>
i guess writing an own datasource
<guardian>
ddfreyne: but I changed inspect on the instance returned by Compass.sass_engine_options and I can't avoid the dependency on Rules
<guardian>
darix: you can create and delete items in preprocess
<darix>
guardian: i know
<guardian>
then writing a datasource
<guardian>
if preprocess isn't enough to alter the array
<ddfreyne>
guardian: Yep, it uses inspect. The reason for that is so that we avoid serialisation issues
<ddfreyne>
darix: Hmm... the ItemsArray is basiclaly just a normal array. Why would you change the way it's built?
<guardian>
ddfreyne: I thought redefining inspect would help workaround the issue: http://pastebin.com/HpTWsL9P but it doesn't seem to be enough
<ddfreyne>
guardian: What's an example #inspec tresul tnow?
<ddfreyne>
guardian: That looks like a good (albeit hacky) start
<ddfreyne>
guardian: I think it includes hashes whose order changes on recompilation...
<guardian>
does show-data requires a recompile first?
<darix>
ddfreyne: if i do all the image processing in an external script ... I would like to build the items manually ... so I can define things like "if filename =~ "(.*)_(original)\." ; mark_item_rep_of($1, $1) ; end"
<guardian>
darix: what prevents you from adding image items in preprocess?
<darix>
guardian: nothing. i just try to learn all the possibilities before doing a decision
<guardian>
ok
<guardian>
ddfreyne: I got it, I need to replace inspect on each instance, not the enclosing array, because make_rule_memory_serializable does [ r[0], r[1], r[2].to_a.map { |a| a.inspect } ]
<guardian>
https://gist.github.com/gpakosz/5420177 <— "better" compass integration, prevents every sass filtered item from incorrectly being recompiled every time because Nanoc believes Rules file has changed in between recompiles
<ddfreyne>
guardian: Maybe the Filesystem class should implement a custom #inspect
<ddfreyne>
guardian: The best solution would be to not rely on #inspect at all... but there needs to be a way to serialize the contents of a rule, and only #inspect is a reliable way to make sure that always works
<guardian>
sure
<guardian>
I don't think something can be done in nanoc apart from my hack
<darix>
ddfreyne: why not something like Marshall.dump ?
<darix>
or another serializer?
<darix>
json
<guardian>
the clean solution is to have Sass::Importers::Filesystem implement #inspect, or have Compass provide its subclass of Sass::Importers::Filesystem that implements #inspect
<guardian>
and also Compass::SpriteImporter needs to implement #inspect
<guardian>
I can't see those two projects move because of a peculiarity of Nanoc
<guardian>
in the meantime, the gist solves the problem. it's particularly useful when you start cachebusting, because if css is marked dirty and gets recompiled, then every html items get recompiled and you don't want that
<ddfreyne>
darix: Not everything can be serialised, unfortunately
<darix>
huh?
<ddfreyne>
darix: lambdas, blocks for instance
<darix>
and inspect shows you those?
<ddfreyne>
IO/File instances
<ddfreyne>
darix: It gives you some sort of textual representation... it's not great though :)
<darix>
marshall dump should handle that
<darix>
except for the IO handles probably
<ddfreyne>
It can't serialise IO and lambdas
<darix>
why do we need the lambdas?
<ddfreyne>
darix: There are cases (in some sites) where lambdas are passed around in the rules
<darix>
hm
<guardian>
ddfreyne: damn that was a long debug journey, but I'm glad I know more about nanoc's internals
jadd_ has joined #nanoc
<ddfreyne>
guardian: Thanks for figuring thi sout too :)