ddfreyne changed the topic of #nanoc to: 3.6.2 (mar 23th) | 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
jadd_ has quit [Quit: Leaving...]
bghost has joined #nanoc
jadd_ has joined #nanoc
jadd_ has quit [Ping timeout: 240 seconds]
jadd_ has joined #nanoc
jaspervdj has quit [Ping timeout: 240 seconds]
jaspervdj has joined #nanoc
jadd_ has quit [Ping timeout: 245 seconds]
jadd_ has joined #nanoc
jaspervdj has quit [Ping timeout: 246 seconds]
matjas has quit [Ping timeout: 245 seconds]
jaspervdj has joined #nanoc
bghost has quit [Ping timeout: 240 seconds]
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
bghost has quit [Ping timeout: 256 seconds]
bghost has joined #nanoc
bghost has joined #nanoc
bghost has quit [Changing host]
<ddfreyne> darix: I can imagine
<ddfreyne> darix: The solution I have in mind is to let @items be a proxy object that records whether it is accessed or not. That way, nanoc can know whether it potentially depends on the new item or not
jadd_ has quit [Quit: Leaving...]
matjas has joined #nanoc
kitallis has joined #nanoc
pavelkunc has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
yogsototh has joined #nanoc
xo__ has quit [Quit: Leaving]
yogsototh has quit [Ping timeout: 246 seconds]
yogsototh has joined #nanoc
Segismond has joined #nanoc
<guardian> o/
<guardian> ddfreyne: am I supposed to edit https://github.com/nanoc/nanoc/wiki/Showcase to add my site?
<ddfreyne> Sure, you can add it there
<guardian> ok
<guardian> I'll open source it later I think, need to iron few things out first
kitallisii has joined #nanoc
kitallis has quit [Ping timeout: 252 seconds]
<Skyr> guardian: ...which might mean never ;)
* Skyr hasn't opensourced his config yet, because he wants to iron out a couple of things as well ;)
<guardian> well… we'll see
<ddfreyne> I’m glad I opensourced nanoc! :D
<guardian> I am too
<guardian> ddfreyne: looks like nanoc rebuilds all my items, always
<guardian> ddfreyne: how can i debug that?
<ddfreyne> guardian: rm -rf tmp will solve that, BUT if you want to do me a favour, send me your tmp :D
<guardian> it will solve it?
<guardian> how come?
<ddfreyne> something in tmp/ becomes corrupt :(
<guardian> ok
<guardian> well I'll try with tmp removed first
<ddfreyne> wait
<ddfreyne> zip your tmp/ first
<guardian> sure
<ddfreyne> (The broken one)
<guardian> I was about to write
<guardian> it it's because of tmp I upload it
<guardian> s/it/if
TobiasFar has joined #nanoc
<TobiasFar> how do i tell nanoc not to delete my custom generated file in the output directory?
<ddfreyne> guardian: If nuking tmp/ solves your problem, do send me your old tmp/
<ddfreyne> TobiasFar: You probably have auto_prune: true in your nanoc.yaml/config.yaml
<guardian> yep sure, think we agreed 3 lines ago :))
<TobiasFar> ddfreyne, yeah...is there a way to keep it with autoprune = true?
<ddfreyne> TobiasFar: How are you generating the file in output/ ?
<ddfreyne> It’s not the result of a routing/compilation rule I take it?
<TobiasFar> no..it's in the Rules file, File.open..it's a file with nginx redirect lines
<ddfreyne> TobiasFar: Ahh, you shouldn’t do that in the Rules file. Instead, create an item (in the preprocessor, if you want) and route it, so that the generated file behaves like a normal nanoc item
<TobiasFar> i have metadata for the redirects in each item so collect redirects in the preprocessing loop and write it out
<ddfreyne> TobiasFar: Instead of writing it out, create an item with the contents of the redirects, and add it to @items.
<TobiasFar> http://nopaste2.doomsong.co.uk/1366288444.php ahh..so my collection phase can stay...just the writing out needs to change
<ddfreyne> TobiasFar: Indeed… you can create a string with the contents using StringIO if you want
<TobiasFar> ddfreyne, is there a way to not have it put in a folder with index.html and putting a layout around the string?
<ddfreyne> TobiasFar: You can set up a routing and compilation rule for that specific item. The routing rule would return /.ayena.de.redirects and the compilation rule would be entirely empty
<TobiasFar> is there a more compact way of doing that?
<ddfreyne> Not yet, but it’s on the to-do list :)
<TobiasFar> great
<TobiasFar> yay...it worked...thanks
<ddfreyne> cool :)
yogsototh has quit [Remote host closed the connection]
yogsototh has joined #nanoc
bghost has quit [Read error: Connection reset by peer]
<guardian> ddfreyne: removing tmp helps but, it looks like nanoc recompiles with css/main.css item through compass, then it recompiles many other items because my default layout cache busts my css file
<guardian> ddfreyne: at least that's what I think is happening right now
<ddfreyne> guardian: Yeah, that is to be expected though
<ddfreyne> (Not that that can’t be improved)
<guardian> so is there a way to prevent css recompile if nothing changes?
<darix> guardian: sounds basically like the same problem as my image handling problem^^
<guardian> ddfreyne: if only the first css recompile didn't happen, then the rest would'nt be recompiled
<stbuehler> afaik all items get recompiled if you add a new one
<stbuehler> why did it try to recompile css/main.css in the first place?
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
yogsototh has quit [Ping timeout: 246 seconds]
<guardian> that's what I'm saking
<guardian> asking
<guardian> nothing changed, just two compile -V in a row
<guardian> second time recompiles and says identical
<guardian> at least that's what I understood: identical means recompiled and found to be indentical right?
yogsototh has joined #nanoc
<ddfreyne> yes
<darix> guardian: just wait until you have a few hundred megabytes of images and it does that ;)
<ddfreyne> I’ll optimise that ;)
<guardian> ddfreyne: can you explain why css gets recompiled in my case? maybe you don't have enough info
<darix> guardian: doesnt nanoc show-data maybe tell you?
<guardian> I didn't know about that command
<guardian> wow I see weird things
<guardian> like my /about page depends on unrelated blog posts
<guardian> looks like everything depend on everything that sucks
<darix> guardian: sidebar stuff or so?
<darix> tag/category list?
<guardian> not sure
<guardian> content/about.md is plain markdown with no helper call
<darix> but your layout or so
<ddfreyne> guardian: does your layout loop through @items ?
<guardian> that's what I'm trying to figure out
<ddfreyne> @items.find { |i| i[:kind] == 'stylesheet' } or somesuch?
<guardian> yes
<guardian> for cache busting :/
<ddfreyne> What is the exact <% %> statement that you use?
<ddfreyne> or expression, rather
<guardian> %link{ :href => cache_bust("/css/main.css"), :rel => "stylesheet" }
<ddfreyne> what does cache_bust do?
<ddfreyne> guardian: you can look up items by identifier free of charge (no dependencies)
<guardian> how do I do that please?
<stbuehler> apart from the one you found i hope
<ddfreyne> so if you change @items.find { |item| item.path == target } to @items.find { |item| item.identifier == target } and also the call to cache_bust to have an identifier as an argument, then that’ll be better
<ddfreyne> stbuehler: indeed
<guardian> let's see
<guardian> in fact semantically I like it better: referring to the css stylesheet identifier rather than path
<ddfreyne> yeah
<guardian> and that reduces dependencies?
<guardian> becaue identifiers don't change while path has to be copmputed?
<ddfreyne> yep
<stbuehler> given that you append the checksum of the file as querystring, i guess you could include the checksum in the output path and drop the querystring. might help some caching proxies which won't cache anything with querystring.
<ddfreyne> Dependencies are fairly coarse… you can’t have a dependency on a specific part of an item; it’s on the entire item directly
<guardian> stbuehler: nope I dont' want to go that route
<guardian> stbuehler: and cache proxies deal with query strings just fine
<guardian> stbuehler: it's just squid proxy's default config which didn't but that was 2 years ago
<guardian> stbuehler: until nanoc can route items based on content I'll stick to using query strings because the hash really depends on compass/sass' output
<stbuehler> yesterday someone in #lighttpd wanted support for running lighty on debian 4.0
<stbuehler> 2 years ago doesn't seem that long ago...
<guardian> yeah I own the server
<guardian> it's nginx on squeeze without squid bullshit :)
<stbuehler> yes, but not the ones where people run squid on :)
<stbuehler> there are a lot of caching proxies, people do it at home to reduce bandwidth, mobile provides do it all the time, ...
<guardian> hear hear
<guardian> well i'll change that afterwards
<stbuehler> still the choice is up to you ofc :)
<guardian> compass's image-url uses a query string
<darix> guardian: couldnt you just use the checksum storted in the item object ?
<guardian> so even if I change that on my site the whole result is half baked
<stbuehler> as long as we don't have the delayed auto prune checksums in the output path can also theoretically break sites
<guardian> darix: it really has to depend on compiled content, ideally
<guardian> ddfreyne: better stil /about/ has a dependency of a an article post :)
<ddfreyne> guardian: Well, @items.find { … } for the /about/ page will also loop over articles, so that could be where the dependency is coming from
<guardian> yes but
<guardian> no because 1) in /about/ there isn't such a find
<guardian> 2) on my sites, blog posts and articles are treated alike albeit being routed differently and /about/ only depends on an article, not blog posts
<guardian> but well it's up to me to find the reason obviously :)
<ddfreyne> guardian: /about/ depends on the stylesheet too, right?
<guardian> it does, since it goes through default layout
<guardian> so yeah it happens in default layout, when I don't layout /about/ there is no dependency
<TobiasFar> Error: The specified deploy target has an unrecognised kind ssh/scp <- i thought that was supported?
<ddfreyne> TobiasFar: rsync and fog are built-in, ssh and scp are not
<ddfreyne> Feel free to contribute one by subclassing http://nanoc.ws/docs/api/Nanoc/Extra/Deployer.html though :)
<TobiasFar> fog?
<ddfreyne> http://fog.io/
<TobiasFar> ahh
<darix> TobiasFar: if you can do scp ... rsync -e ssh
<darix> should be possible too
<guardian> ddfreyne: does using @items[] create dependencies? I'm using that instead of @items.find
<ddfreyne> guardian: @items['/foo/']? Nope, it doesn’t
<ddfreyne> @items.find { |i| i.identifier == '/foo/' } ← also doesn’t, but is slower
<guardian> then there is something strange
<ddfreyne> Well, it creates a dependency on the found item of course, but nothing else
<guardian> my /about/ depends on /articles/bla/bla/bla' just because in default layout I call cache_bust on 'css/main' and 'js/all' identifiers
<guardian> cache_bust is the one I pasted before, but modified to use @items[]
<ddfreyne> hm odd
<ddfreyne> guardian: What about rm -rf tmp and recompiling? I’m thinking the tmp storage gets busted too easily
<guardian> ok trying
<FunkyPenguin> hi, am i right in saying that if i would like a tag list similar to a category list i need to include Nanoc::Helpers::Tagging ?
<darix> moin FunkyPenguin
<ddfreyne> FunkyPenguin: You could use that, yes… or write your own, because the Tagging helper is pretty basic
<FunkyPenguin> moin darix
<FunkyPenguin> ddfreyne: ok, i thuink i'll go baby steps first and use what's there :)
<ddfreyne> FunkyPenguin: current implementation is this: https://github.com/nanoc/nanoc/blob/master/lib/nanoc/helpers/tagging.rb so you can get some ideas from there, but as I said, it is REALLY basic :)
<guardian> ddfreyne: removing tmp again didn't help
<guardian> ddfreyne: http://pastebin.com/5KBEE40e in case you spot something obvious
<ddfreyne> Good news: tmp does not get corrupted THAT easily
<ddfreyne> guardian: Where does relativize_path come from?
<guardian> I pasted it
<guardian> and relative_path_to is stock helper's version
<ddfreyne> oh yeah :)
<FunkyPenguin> ddfreyne: sorry, im not sure im understanding things. i add tagging.rb to lib/ add "include Nanoc::Helpers::Tagging" to helpers.rb
<ddfreyne> FunkyPenguin: if you want to reuse it as-is, you don’t need to do anything with tagging.rb… just add the include to helpers.rb
jadd_ has joined #nanoc
jadd_ has quit [Read error: Connection reset by peer]
jadd- has joined #nanoc
<FunkyPenguin> ddfreyne: so how should i define the tag class? what is the equivalent to link_categories?
<FunkyPenguin> ddfreyne: nevermind, got it - thanks
<ddfreyne> FunkyPenguin: What do you mean by tag class? there is no Tag class… once you have added the include to lib/ you can just use the methods in the Tagging helper in layouts et
<ddfreyne> ok
<guardian> ddfreyne: so, nothing obvious right?
<guardian> ddfreyne: any of the two calls to cache_bust in the layout adds the dep
yogsototh1 has joined #nanoc
yogsototh has quit [Ping timeout: 246 seconds]
<ddfreyne> guardian: Not at first sight
<ddfreyne> guardian: can’t talk atm, will take a closer look later
<guardian> sure no pb
kitallisii has quit [Quit: Textual IRC Client: http://www.textualapp.com/]
hakunin has quit [Remote host closed the connection]
hakunin has joined #nanoc
<guardian> ddfreyne: I progressed a bit, for when you want to think about it more. it all boils down to every item that goes through sass depends on all the other items :/
bghost has quit [Ping timeout: 246 seconds]
bghost has joined #nanoc
bghost has joined #nanoc
bghost has quit [Changing host]
<ddfreyne> guardian: Ahh… the sass filter does cause a dependency on all items because it needs content_filename attribute… hm.
<guardian> is there a way around this? it should depend only on imported item, isn't that the point of what's happening in lib/nanoc/filters/sass.rb?
bghost has quit [Ping timeout: 256 seconds]
Rym has quit [Quit: Rym]
<ddfreyne> guardian: Sass needs to find items by filename instead of identifier, so it needs to .find { |i| i[:content_filename] == … }
<guardian> and doing item[:content_filename] creates a dependency?
<ddfreyne> guardian: yes, because that is accessing an attribute
<ddfreyne> Accessing content, attributes and paths creates dependencies
<guardian> and can't that be relaxed?
<ddfreyne> No
<guardian> yet it looks like the sass filter does its best to depend on imported items
<guardian> and only those
<guardian> and then it the end it depends on everything anyways
bghost has joined #nanoc
<guardian> is there a doc for item attributes?
<guardian> particularly :content_filename?
<ddfreyne> Item attributes are entirely freeform; nanoc doesn’t about them. The filesystem data source adds the attributes :filename, :meta_filename, :content_filename and :extension by default though
<ddfreyne> Huh… that’s not even documented :(
* ddfreyne adds to todo list
<ddfreyne> The cool thing is, though, that nanoc 4.x’ identifiers will eliminate all these problems :D
<guardian> but why content_filename?
<guardian> why not raw_filename?
<guardian> instead of restricting raw_filename to binary items
<ddfreyne> guardian: raw_filename only works for binary items
<guardian> yeah
<ddfreyne> and that also creates a dependency (same reason why dependencies on content are created)
<guardian> I'm reading that
<guardian> but I don't get the profound reason
<guardian> eventhough items can be created dynamically
<guardian> raw_fliename has sense for every on disk item, be it binary or text
<guardian> then yeah if it doesn't help with dependencies… that's another story
<guardian> also, sass filter does filter.depend_on so I guess at some point, in earlier nanoc releases, sass filtered items only had dependencies on imported items, and not everything
<ddfreyne> guardian: The reason why @items.find { |i| i[:attribute] == 'blah' } creates a dependency is because nanoc actually loops over all items to find the item that matches the predicate. All attributes are equal, so the same happens for :content_filename etc
<ddfreyne> guardian: As for raw_filename… hm. That would work, I think
jadd- has quit [Quit: Leaving...]
<guardian> you just told accessing raw_filename creates a dependency as well right?
jadd_ has joined #nanoc
Rym has joined #nanoc
<ddfreyne> Hm, it doesn’t, apparently
jadd_ has quit [Read error: Connection reset by peer]
jadd_ has joined #nanoc
<guardian> ddfreyne: I replaced all [:content_filename] with .attributes.fetch(:content_filename) or .attributes.fetch(:content_filename, nil) depending on the code
<guardian> ddfreyne: that prevents sass filtered item from depending on the world
<guardian> ddfreyne: do you approve of this and want a pull request?
<guardian> in sass.rb
<ddfreyne> guardian: That might work but it’s really not good behavior :(
<guardian> I don't get why it's not good behavior
<guardian> sass filltered items depending on everything isn't that great either :)
<guardian> banging my head around why it's not good behavior and I don't see how it can break :(
<ddfreyne> guardian: Not sure about raw_filename… I think you could just use that straight away
<guardian> the doc says raw_filename isn't available for non binary items
<ddfreyne> guardian: ah, true
<guardian> that's why I used fetch
<ddfreyne> guardian: Accessing attributes *in general* needs to create dependencies
<guardian> but content_filename is not a *general* attribute
<guardian> and you don't use the value of the attribute to produce something, you use the value as an intermediate step to reach the corresponding nanoc item
<ddfreyne> guardian: true, and you could probably use it the way you do (with fetch etc)
<guardian> that's why I believe in this special case it's acceptable
<ddfreyne> guardian: Perhaps, but I’d rather not put it in nanoc itself :)
<guardian> allright
<ddfreyne> guardian: It doesn’t quite feel clean
<ddfreyne> guardian: If it’s any consolidation, nanoc 4.0 will have identifiers that are actual filenames :)
<ddfreyne> consolation, too
<guardian> but it doesn't feel ok to have sass filtered item to depend on everything
<guardian> ddfreyne: would you accept to relax the constraint on raw_filename? and make it work on text items as well?
<guardian> ddfreyne: imho, for a text item, it's reasonable — raw_content gives the content, raw_filename gives :content_filename
<stbuehler> why would the sass filtered item depend on everything just for reading one attribute?
<stbuehler> that sounds wrong
<guardian> that's exactly what I'm arguing for the last minutes :)
<ddfreyne> guardian: raw_filename for all items would be a good idea, I think
<stbuehler> ah, because sass needs to find the other css items. sry, got it. and yes, the sass filter should work around that :)
<ddfreyne> nanoc’s goal is to be correct as possible, and that means that if it can’t infer that a dependency is not necessary, then it will create one
<ddfreyne> Too many is better than too few in this case
<stbuehler> then create a getter that finds items based on filenames and doesn't depend on all items
<ddfreyne> better being “correcter” not “faster”
<stbuehler> that way you have a clean api that is certainly not broken
<guardian> ddfreyne: I don't get what makes .attributes.fetch dirty though
<ddfreyne> guardian: I never intended #attributes to be publicly accessible :)
<ddfreyne> @item[:foo] is the same as @item.attributes[:foo] and then creating a dependency, so with #attributes you’re short-circuiting some nanoc logic
<guardian> ddfreyne: I'm happy to provide you with 2 pull requests anyways: one for item so that raw_filename is always available, and another so that sass filter uses raw_filename
<guardian> would that work?
<ddfreyne> guardian: I wouldn’t bother, because I’m working on a nanoc 4.0 branch where identifiers are filenames
<ddfreyne> So you can do compile '/assets/fonts/*.eot' and @items['/assets/stylesheets/_fonts.sass'] for instance
<guardian> but would the proposed changes make into 3.6.3?
<ddfreyne> guardian: your proposed changes?
<guardian> <guardian> ddfreyne: I'm happy to provide you with 2 pull requests anyways: one for item so that raw_filename is always available, and another so that sass filter uses raw_filename
<ddfreyne> guardian: Those could go into 3.7.0
<ddfreyne> guardian: Actually, do submit a pull request on the master branch (not release-3.6.x and not experimental-4.0)
<guardian> ok
<guardian> ddfreyne: if you have few spare minutes I find things weird with dependencies as well, unrelated to sass filter
<ddfreyne> guardian: sure, shoot!
<ddfreyne> If it’s about new items causing dependencies from all existing items onto the new item, that’s a known issue :)
<guardian> show-data says items are outdated because Rules file changed
<guardian> but it didn't
<guardian> I'm launching compile -V, then show-data |less
<guardian> and I don't change files...
<ddfreyne> guardian: are you using any environment variables or globals in your rules? can you share the Rules file?
<guardian> oh actually! it's related to sass as well
<guardian> is outdated: The rules file has been modified since the last time the site was compiled.
<guardian> happens on the 2 files that go through sass
<guardian> but the rules file didn't change
<guardian> happens on /css/main/ and /css/feed/ which are the two top level scss items my site has
<ddfreyne> changes to the Rules file are detected by running a fake “spy” item rep through the rules and seeing whether the rules have changed
<ddfreyne> For example, if you at some point say “filter :erb, :time => Time.now” then the Rules file would “change” every millisecond
<ddfreyne> perhaps something similar is happening now
<ddfreyne> guardian: Can you share the Rules file?
<ddfreyne> guardian: I have to go, actually…
<guardian> ddfreyne: no problem we talk about that later
<guardian> ddfreyne: here it is http://pastebin.com/f7NY4ZX0
<ddfreyne> guardian: which rules are affected?
<guardian> '/css/*/'
<guardian> it happens only on my /css/main/ and /css/feed/ scss files
<guardian> and here is lib/items.rb http://pastebin.com/HUwYy5sZ
<guardian> that happening on the 2 sole items that go through sass filter can't be a coincidence
hakunin has quit [Remote host closed the connection]
hakunin has joined #nanoc
hakunin has quit [Ping timeout: 272 seconds]
yogsototh1 has quit [Remote host closed the connection]
Rym has quit [Quit: Rym]
bghost has quit [Read error: Connection reset by peer]
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
bghost has quit [Quit: leaving]
bghost has joined #nanoc
bghost has quit [Ping timeout: 240 seconds]
bghost has joined #nanoc
<guardian> re
<guardian> ddfreyne: you around by chance?
pavelkunc has joined #nanoc
<ddfreyne> guardian: half and half
<guardian> :)
<guardian> ok
jadd_ has quit [Quit: Leaving...]
jadd_ has joined #nanoc
Rym has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
<guardian> ddfreyne: I nailed it, even with an empty hash filter :sass, Compass.sass_engine_options.merge({}) makes every sass filtered item depend on Rules
forcev has joined #nanoc
<ddfreyne> guardian: do you have a minimal test site? Can you create an issue for that at github?
<guardian> oh I'll try to understand further
<guardian> filter :sass, Compass.sass_engine_options makes every sass filtered item depend on Rules
<guardian> it's not about merging
FunkyPenguin has quit [Ping timeout: 256 seconds]
<guardian> I also raped Sass filter, and now it returns the empty string instead of invoking sass
<guardian> so with that NOP Sass filter, adding filter :sass, Compass.sass_engine_options makes every sass filtered item depend on Rules
<guardian> ddfreyne: also, I was able to modify the Sass filter to avoid using a global var, interested in that? it happens options hash given to Sass::Engine by doing ::Sass::Engine.new(content, options) is passed around as iss
<guardian> ddfreyne: so you can do option[:nanoc_current_filter] = self, and take that back afterwards
<ddfreyne> guardian: Oh yes, the global-less version would be very useful
<ddfreyne> guardian: Also, does it still occur without Compass?
<guardian> what still occurs without compass?
<guardian> the weird dependency on Rules?
<ddfreyne> yeah
<guardian> it's all about Compass.sass_engine_options
<guardian> content changes at each invocation
<ddfreyne> Ahhhh!
<ddfreyne> Why does it change?
<guardian> the load_paths
<guardian> that sucks
<guardian> nothing nanoc can do I guess
<guardian> I didn't expect it to instantiate stuff in fact
<ddfreyne> The array changes? Order changes? Someting else?
<guardian> see the pastebin
<guardian> it's the result of puts Compass.sass_engine_option
<guardian> from within Rules
<guardian> I'm cloning compass to figure out exactly
<ddfreyne> guardian: How do the options differ in between invocations?
<guardian> if I knew
<guardian> http://pastebin.com/WWej3KWf <— this is the result of adding puts Compass.sass_engine_option in Rules
<ddfreyne> guardian: I mean, can you show me the results of two invocations?
<guardian> I have 2 sass items
<guardian> therefore it prints 2 times
<guardian> wait I put spaces in the paste bin
<guardian> so that you see better
<ddfreyne> guardian: Ahh, got it
<ddfreyne> Hmm… that is strange behavior.
<ddfreyne> nanoc’s behavior is correct, I’d say
<guardian> there
<guardian> it instantiates a new filesystem
<ddfreyne> guardian: Perhaps Sass::Importers::Filesystem needs to implement #==
<guardian> good point
<ddfreyne> or .eql? or .equals? or #=== or whatever it is these days
<guardian> about sass filter
<guardian> I already sent a pull request
<guardian> so that it uses raw_filename
<guardian> I can make another one to avoid the use of a global, but from where do I make it start from?
<guardian> master or my pull request?
<ddfreyne> guardian: Make it start from master
<guardian> then you'll have to merge
<ddfreyne> Yep, but that’s no problem
<guardian> ok
<guardian> what's ===?
<ddfreyne> guardian: used in `case` etc
bghost has quit [Ping timeout: 258 seconds]
<ddfreyne> case @blah ; when String ; when Numeric ; … end
<ddfreyne> etc
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
<guardian> Sass::Importers::Filesystem implements eql http://sass-lang.com/docs/yardoc/Sass/Importers/Filesystem.html#eql%3F-instance_method
<guardian> in fact, my NOP Sass filter doesn't even instantiate a Sass engine nor use nanoc's SassFilesystemImporter
<guardian> so, it's all about nanoc detects something change in filter options
<guardian> ddfreyne: ok enough debugging for me, if you have an idea I'm all hears tomorrow :) somehow nanoc recording rule memory thinks Compass.sass_engine_options differs from rep to rep
<guardian> ddfreyne: my puts in Rules shows it differs from item to item, so I bet it differs to from rep to rep when running that "spy" rep
<guardian> ddfreyne: I lied, I kept debugging… it's all about Sass::Importers::Filesystem and Compass::SpriteImporter not implementing inspect. since it's the way you compute rule memory and https://github.com/chriseppstein/compass/blob/stable/lib/compass/configuration/adapters.rb#L70 instantiates new importers each time...
<guardian> ddfreyne: and finally, I did @sass_options = Compass.sass_engine_options in my preprocess block. which I reuse afterwards in compile rules… in order to workaround all that hairy mess ;/
<guardian> ddfreyne: I would like to talk about it further when you have spare time to read those 10 lines of backlog please ;)
<guardian> fuck it doens't workaround the pb, anyways bed time
bghost has quit [Ping timeout: 256 seconds]
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
bghost has quit [Ping timeout: 256 seconds]
bghost has joined #nanoc
bghost has quit [Changing host]
bghost has joined #nanoc
jadd_ has quit [Quit: Leaving...]
jadd_ has joined #nanoc