<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
<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.
<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?
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
<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>
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
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>
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>
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: 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