alerante has quit [Remote host closed the connection]
smkelly has quit [Quit: Goodbye]
smkelly has joined #nanoc
smkelly has quit [Quit: Goodbye]
smkelly has joined #nanoc
smkelly has quit [Quit: Goodbye]
smkelly has joined #nanoc
prxq_ is now known as prxq
alerante has joined #nanoc
alerante has quit [Ping timeout: 252 seconds]
alerante has joined #nanoc
<ddfreyne>
bobthecow: Nope
<ddfreyne>
bobthecow: I started working on this on sunday afternoon
<ddfreyne>
So that gives you an idea of how finished it is ;)
alerante has quit [Ping timeout: 240 seconds]
relix has joined #nanoc
<guardian`>
morning
<bobthecow>
night
<guardian`>
:)
guardian` is now known as guardian
VitamineD has quit [Quit: Computer has gone to sleep.]
VitamineD has joined #nanoc
VitamineD has quit [Quit: Computer has gone to sleep.]
prxq has quit [Quit: Leaving]
prxq has joined #nanoc
VitamineD has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 245 seconds]
alerante has joined #nanoc
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #nanoc
VitamineD has quit [Ping timeout: 240 seconds]
prxq has quit [Quit: Leaving]
jugglinmike has joined #nanoc
FunkyPenguin has quit [Ping timeout: 265 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 276 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 240 seconds]
VitamineD has joined #nanoc
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 250 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 252 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
<tom[]>
is it wise to gitignore .bundle ?
<VitamineD>
what's .bundle ? some bundler artifact ?
FunkyPenguin has joined #nanoc
<VitamineD>
as long as you can get it back in some automated way… I'd say yes
<bobthecow>
tom[]: yep yep.
<bobthecow>
you do want to commit Gemfile and Gemfile.lock
<tom[]>
right. i remember you said that about Gemf* before
<bobthecow>
VitamineD: depending on your bundler config, sometimes it puts gems there, sometimes it puts binstubs there, sometimes it puts config there.
<bobthecow>
VitamineD: it's all regenerated when you run `bundle install`
FunkyPenguin has quit [Ping timeout: 276 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 240 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
VitamineD has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 265 seconds]
<jugglinmike>
Do nanoc layouts do any sort of sanitization for `<%= %>` tags? Or is that just plain eRuby?
FunkyPenguin has joined #nanoc
<jugglinmike>
Hmm... maybe the "safe_level" option?
<bobthecow>
it's just eruby.
VitamineD has joined #nanoc
<jugglinmike>
thanks bobthecow. I can also see that `safe_level` is for code execution, not string sanitization
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 276 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 240 seconds]
relix has quit [Read error: Connection reset by peer]
relix has joined #nanoc
FunkyPenguin has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
VitamineD has quit [Read error: Connection reset by peer]
VitamineD has joined #nanoc
FunkyPenguin has quit [Ping timeout: 252 seconds]
FunkyPenguin has joined #nanoc
relix has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
relix has joined #nanoc
FunkyPenguin has quit [Ping timeout: 250 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
alerante has quit [Remote host closed the connection]
FunkyPenguin has joined #nanoc
alerante has joined #nanoc
FunkyPenguin has quit [Ping timeout: 250 seconds]
francois2 has quit [Excess Flood]
francois2_ has joined #nanoc
francois2_ is now known as francois2
FunkyPenguin has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
FunkyPenguin has quit [Ping timeout: 276 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 255 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
VitamineD has quit [Quit: Computer has gone to sleep.]
alerante has joined #nanoc
<jugglinmike>
Does nanoc always use checksumming to detect file changes? Or are there circumstances where it might use other heuristics (i.e. mtime)?
alerante has quit [Ping timeout: 240 seconds]
VitamineD has joined #nanoc
VitamineD has quit [Ping timeout: 246 seconds]
VitamineD has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<jugglinmike>
ddfreyne: A long time ago, you told me not to use a global hash for storing data structures I built during the "compile" stage. I'm running across inefficient compile times, and seeing strange reports from `nanoc show-data`. Do you think using the @config object instead would help here?
<jugglinmike>
I'm not sure how the site tracks the usage of global structures like that
<jugglinmike>
Doesn't look like that will help
<jugglinmike>
More generally
<jugglinmike>
How do I safely share data structures I generate during the "prepocess" stage?
<jugglinmike>
ddfreyne: Sorry, I used the wrong term in my earlier message. When I said 'I built during the "compile" stage', I should have said 'I built during the "preprocess" stage'
<bobthecow>
jugglinmike: what are your things in preprocessing?
<bobthecow>
s/what are your things/what things are you generating/
alerante has joined #nanoc
<jugglinmike>
bobthecow: Filtered lists of items, mostly
<jugglinmike>
authors, posts
<jugglinmike>
but also creating some dynamically
<jugglinmike>
like categories
<jugglinmike>
also a collection of static assets
<jugglinmike>
or rather, a collection of nanoc items that represent static assets
<bobthecow>
the trouble you're going to have is that nanoc can't tell when those lists change from one compile to another.
<bobthecow>
creating items dynamically is fine, that's what nanoc's good at.
<bobthecow>
filtered lists are tough though.
<ddfreyne>
jugglinmike: The main issue you'll get with precomputing stuff and storing it into globals is that nanoc will not recompile pages that you would expect to see recompiled
<ddfreyne>
Imagine that you have `preprocess do $stuff = @items['/foo/'][:title] end` and then in some random item `<%= $stuff %>`.
<ddfreyne>
If the title attribute of the /foo/ item changes, nanoc won't be able to tell.
<jugglinmike>
ddfreyne: bobthecow I expected as much. This site was built years ago based on that model, and I've been trying to work with it. I would like to fix this problem, but I'm not sure how. Is there any way to explicitly communicate the interdependencies to nanoc?
<bobthecow>
or rather, it will be able to tell, but it won't know that this invalidates the item with $stuff in it.
<bobthecow>
you could make your globals into items instead.
<bobthecow>
then anything that needed info out of them would depend on the item?
<jugglinmike>
(I haven't had any issues with items failing to compile when I expect them to. Generally, the problem has been slowness--nanoc must be erring on the side of caution when making the dependency graph)
<ddfreyne>
jugglinmike: you could store the list of items as item identifiers in the @config hash, and then use that
<ddfreyne>
jugglinmike: Slow compile times won't become faster though (on the contrary)
<ddfreyne>
On the contrary, because it will ensure correct dependnecies and therefore compile either equally fast or slower
<bobthecow>
yeah.
<jugglinmike>
bobthecow: Interesting! Is there a succinct way to tell nanoc, "Don't compile/route these" , or will I have to make "pass" routes for them?
<bobthecow>
`ignore '/route/foo/'`
<ddfreyne>
On the plus side, you will have the correct dependencies and your site will not have stale parts
<jugglinmike>
hmm that's a little disheartening ddfreyne, but I'm all for making this more explicit
<jugglinmike>
ddfreyne: maybe it will help me debug the slowness, though
<ddfreyne>
jugglinmike: run `nanoc compile --verbose` to see what filters take the longest
<jugglinmike>
because `nanoc show-data` might become more useful
<bobthecow>
it'll definitely help with that.
<ddfreyne>
There is a fix coming in nanoc 3.6.10 (or 3.7.0) that will reduce the number of invalidations caused by sass dependencies when using compass
<bobthecow>
you most likely are doing something dumb and creating unintentional dependencies. every time i've dug into a really slow nanoc install that was the case :)
<bobthecow>
i got my compile from 9 minutes to 27 seconds by cleaning up some unintentional dependencies.
<ddfreyne>
(It has a partial fix for some sass+compass dependency issues, but I intend to fix that in a better way in a future PR)
<jugglinmike>
bobthecow: totally! for instance, right now a ton of things depend on this layout named "/weblog/feed", and I don't really know why
<ddfreyne>
The fix is using Marshal.dump rather than #inspect so that the ID of an object is not causing outdatedness
<jugglinmike>
ddfreyne: Using sass, but not compass
<bobthecow>
ddfreyne: but it's mixed in with that huge tl;dr of jruby fixes?
<jugglinmike>
...so I think my speedup will have to come from my own hard work
<ddfreyne>
bobthecow: It was causing issues on JRuby as well (I don't quite remember what it was anymore though. Failing tests though)
<ddfreyne>
jugglinmike: Hmmm… is the site publicly visible?
<ddfreyne>
(I mean the source)
<jugglinmike>
ddfreyne: Unfortunately no. But I appreciate the sentiment!
<ddfreyne>
I wrote a prototype/hack dependency visualiser with graphviz once, but it is really hard to make it useful.
<ddfreyne>
`nanoc show-data /foo/` <- would be useful if this would show the dependency chain
<jugglinmike>
ddfreyne: Totally! Right now, I'm passing the output of `show-data` through 2 `grep` calls and a `wc -l`
<bobthecow>
jugglinmike: i usually pipe it to pbcopy and dump it in sublime :)
<ddfreyne>
Visualising it is hard though. It is a spider web.
<jugglinmike>
by the way, I want to be sure that when I run `nanoc show-data`, the graph is up-to-date. Is it too conservative to be runnning `rm -rf ./tmp && nanoc compile --verbose`?
<jugglinmike>
hmmm, looking up "pbcopy"
<ddfreyne>
jugglinmike: rm -rf tmp will cause nanoc to recompile everything
<ddfreyne>
So that's fine
<ddfreyne>
(Although likely unnecessary)
<ddfreyne>
If you're paranoid of nanoc not recompiling when it needs to recompile, doing a rm -rf tmp is a good idea
<ddfreyne>
jugglinmike: pbcopy is
<jugglinmike>
mac utility
<ddfreyne>
Oops
<jugglinmike>
hehe, I looked it up
<ddfreyne>
jugglinmike: pbcopy is a tool that takes stdin and puts it in the pastebuffer
<ddfreyne>
aka clipboard
<jugglinmike>
In Ubuntu here, and still haven't found a good way to work with the clipboad
<jugglinmike>
board
<jugglinmike>
ddfreyne: When I run `nanoc show-data`, does nanoc re-compute `tmp/`?
<jugglinmike>
(I've been deleting it because I was afraid it might not be re-computing the dependency graph as I was doing this refactoring)
<ddfreyne>
jugglinmike: nanoc show-data only reads, doesn't write
<jugglinmike>
ah, okay
<ddfreyne>
It displays the state of things at the moment of invocation
<jugglinmike>
so `nanoc compile` is also necessary
<jugglinmike>
to write out the dependency information
<ddfreyne>
jugglinmike: If you rm -rf tmp && nanoc show-data, it will show everything as outdated
<jugglinmike>
got it
<ddfreyne>
jugglinmike: If you rm -rf tmp && nanoc && nanoc show-data, it will show you the state after compilation
<jugglinmike>
ho boy
<jugglinmike>
This is all sorts of messed up
<jugglinmike>
I'm seeing consistent over-compilation (i.e. "identical" reported by `nanoc --verbose`) when running in a virtual machine. I see that *sporadically* when running natively. nanoc 3.6.4 in both environments
<jugglinmike>
I wonder if it is time dependent... The site does make a single call to Time.now, but its in that "weblog/feed" layout
<ddfreyne>
jugglinmike: Can you upgrade to the latest nanoc version (3.6.9) and see how it works there?
<jugglinmike>
oh! Didn't realize I was behind
<ddfreyne>
See topic :)
<ddfreyne>
3.6.4 is almost 1 year old
<ddfreyne>
It has sass-related improvements
<jugglinmike>
ddfreyne: And you fixed the formatting on the ASCII table for filter statistics!
<ddfreyne>
Fixed output of --verbose compilation statistics (#359, #365)
<jugglinmike>
ddfreyne: This unnecessary recompilation is still non-deterministic, though. Man something must be really messed up on my end
<ddfreyne>
Fixed issue with Sass files not recompiling (#350, #370)
<ddfreyne>
Reduced number of dependencies generated by Sass filter (#306) [Gregory Pakosz]
<ddfreyne>
Fixed bug which could cause incorrect dependencies to be generated in some cases (#329)
<ddfreyne>
jugglinmike: even after rm -rf tmp ?
<jugglinmike>
ddfreyne: sorry, I'm normally consulting for front-end development, and it's a rare chance that I have the time to work on this site (and play with nanoc)
<jugglinmike>
ddfreyne: I don't understand. Shouldnt I expect to see everything re-compiled as "identical" if I delete "tmp/"?
<ddfreyne>
jugglinmike: After `rm -rf`, a `nanoc co` will show everything as identical, because everything is recompiled (due to lack of tmp information). A second `nanoc co --verbose` should ideally show little (or no) identicals, because tmp information is available
<jugglinmike>
yup, got it
<jugglinmike>
and it does
<jugglinmike>
but it's subsequent `nanoc compile` s that start showing "identical"s again
<jugglinmike>
So I think this is a problem with my site, not with nanoc