<coderanger>
"undefined method `content_for' for #<Nanoc::Context"
<coderanger>
Do I need to do something to activate the helper?
<coderanger>
Got it, never mind :)
<coderanger>
Been so long since I started a new nanoc site, have to relearn the basics
pavelkunc has joined #nanoc
number-six has quit [Remote host closed the connection]
jaspervdj has quit [Remote host closed the connection]
VitamineD has joined #nanoc
yogsototh has quit [Remote host closed the connection]
yogsototh has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
VitamineD has quit [Client Quit]
jarr0dsz has joined #nanoc
number-six has joined #nanoc
jaspervdj has joined #nanoc
VitamineD has joined #nanoc
gregkare has quit [Excess Flood]
gregkare has joined #nanoc
cDlm has joined #nanoc
VitamineD has quit [Read error: Connection reset by peer]
cDlm is now known as VitamineD
cDlm has joined #nanoc
VitamineD has quit [Ping timeout: 252 seconds]
cDlm is now known as VitamineD
gregkare has quit [Excess Flood]
gregkare has joined #nanoc
koan_ is now known as koan
VitamineD has quit [Quit: VitamineD]
jugglinmike has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
jarr0dsz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jarr0dsz has joined #nanoc
yogsototh has quit [Remote host closed the connection]
<dkm>
with cri, how do I pass/use environment info to subcommands?
<dkm>
I don't know if "environment" is the right terminology here. I have a data structure that is populated in the base command, I want it to be available in the subcommands
<bobthecow>
based on options or something?
<dkm>
well, I pass in a file name in the options of the base command
<dkm>
that file is parsed into a data structure
<bobthecow>
so ...
<bobthecow>
foo --file bar baz
<dkm>
then I want to have sub commands that use the resulting data structure
<dkm>
right
<bobthecow>
and in subcommand baz you want to get something that you already processed from the --file option.
<dkm>
yes
<bobthecow>
supercommand is available in each subcommand.
<bobthecow>
supercommand.name == "foo"
<dkm>
ah, ok, thanks
<bobthecow>
so i'd put a helper on the supercommand and use supercommand.file_option or whatever.
<dkm>
ok
<bobthecow>
are you using the command DSL or commandrunner instances?
<dkm>
the DSL
<bobthecow>
i've found commandrunner classes to work better for most non-trivial commands.
<dkm>
ok, I'll give it a look
<tom[]>
my site takes a while to compile. when i'm working only on my scss stylesheet, is there a way to ask guard to only process that file?
<bobthecow>
tom[]: nope.
<tom[]>
:(
<bobthecow>
but you can fix whatever makes your site take a while to compile when you're only changing that file.
<bobthecow>
have you checked your item dependency graph to see if anything has unnecessary dependencies?
<tom[]>
no
<tom[]>
guess that's something to learn next
<bobthecow>
once upon a time i had a site that took nine and a half minutes to compile.
<bobthecow>
Fore::CommandRunner is a subclass of Cri::CommandRunner which adds my helpers like field_and_files and split_file
<bobthecow>
you could use a subclass like that.
<bobthecow>
have a file helper.
<dkm>
ok, thanks
<bobthecow>
def file; File.read(options[:file]); end
<bobthecow>
then it doesn't rely on having access to the supercommand at all.
<dkm>
I think I was missing the 'runner MyCommandRunnerClass'
<dkm>
ah, yeah, I like that
<dkm>
guess there is no need to have access to supercommand then
<dkm>
except... then what's the point of having a super command/sub command at all
<dkm>
?
<ddfreyne>
dkm: Yeah, use options[:blah] to access options; don't query the supercommand
<ddfreyne>
dkm: super/subcommands are used to define how you invoke a command
<ddfreyne>
dkm: e.g. "compile" is a subcommand of "nanoc"
<ddfreyne>
dkm: Also, options defined in the supercommand (--help, --verobse, ...) will also be recognised by the subcommand
<bobthecow>
dkm: supercommand is just for making a `git commit` style subcommand structure
<dkm>
ddfreyne: so, I suppose the super command can be thought of as defining a namespace? i.e. so that you can have a 'compile' command that doesn't clash with another 'compile' in your PATH?
<bobthecow>
like `nanoc compile` is a subcommand of `nanoc`.
<bobthecow>
it's a really handy way of defining complicated command line apis.
<ddfreyne>
dkm: Yep
<dkm>
yeah, I guess my question is, why not just make a command 'compile' that does what 'nanoc compile' does
<bobthecow>
if you just need to compile, that's fine.
<dkm>
ok, I think I kind of grok it as a namespace
<dkm>
I'm ok with that
<ddfreyne>
dkm: I *could* have generated commands like nanoc-compile nanoc-create-site nanoc-prune etc... but having a main "nanoc" command is nicer
<dkm>
gotcha
<bobthecow>
but what happens when you have something like git, with 30 subcommands?
<bobthecow>
git checkout foo, git commit, git clone, etc.
<dkm>
bobthecow: right, and I guess that's why all the man pages for git are for things like git-add, git-remote, etc
<bobthecow>
and you could build them arbitrarily nested.
<bobthecow>
git-flow does that.
<bobthecow>
git flow feature start < three levels of subcommands.
<bobthecow>
in the case of git, it's happening because git is a magic wrapper that converts its first few arguments into subcommands.
<bobthecow>
so when you type `git remote add foo` it's actually executing `git-remote-add $*`
<bobthecow>
or `git-remote` or something.
<bobthecow>
at some level the subcommands become arguments rather than actual distinct executables.
<tom[]>
i don't know how to analyze or control dependencies in nanoc. my web search skills are poor. can y'all help me out with pointer(s)?
<bobthecow>
dkm: git stopped exposing those git-* executables at some point, but that's why the man pages are what they are
<dkm>
thanks for the explaination!
<bobthecow>
tom[]: nanoc show-data
<bobthecow>
if you're on a mac, run:
<bobthecow>
nanoc show-data | pbcopy
<bobthecow>
then paste it into an editor.
<bobthecow>
it has a *ton* of output and it's a lot easier to make sense of in a text editor :P
<dkm>
tom[]: and on linux xsel instead of pbcopy
<dkm>
just in case :)
<bobthecow>
and if you're on windows, just hold down the power button until it turns off, and walk away.
<bobthecow>
;)
<dkm>
:)
<bobthecow>
seriously, though, i would be so lost on windows without a proper terminal.
<bobthecow>
does your routing rule for styles do anything weird?
<tom[]>
route '/assets/styles/' do
<tom[]>
'/assets/styles.css'
<tom[]>
end
<tom[]>
it doesn't seem weird to me but that's probably a subjective property
<bobthecow>
no, that's not weird.
<bobthecow>
why, exactly, can't you hardcode that?
<tom[]>
:relativize_paths
<bobthecow>
that works on all paths.
<bobthecow>
regardless of how you put 'em in your file.
<tom[]>
each item has a its number of ../ in the link to the stylesheet
<bobthecow>
yeah. relativize_paths runs after the page is already htmls.
<bobthecow>
so it doesn't matter how that path gets there.
<bobthecow>
it will still relativize it.
<tom[]>
rly!
<bobthecow>
yep!
<tom[]>
i'll try
jarr0dsz has joined #nanoc
<tom[]>
lovely!
<tom[]>
didn't make compile faster :(
<tom[]>
is there something i should do to make nanoc rethink the dependencies?
<tom[]>
no. the dependences for styles look very reasonable now
<tom[]>
guard still needs 5-10 seconds to: update [0.00s] output/assets/styles.css
<bobthecow>
that's the same speed as before?
<bobthecow>
it does have a certain amount of overhead just loading up the site and figuring out if anything has changed.
<bobthecow>
that will change in 4.x, where guard will report directly to nanoc which files have changed and it'll speed up the boot time by quite a bit.
<tom[]>
i really don't know. there's 150 to 200 items
<tom[]>
it is the same speed as before
<bobthecow>
and you have the latest version installed?
<bobthecow>
the last couple of releases have fixed some unnecessary recompiling.
<tom[]>
3.6.5?
<bobthecow>
3.6.6
<bobthecow>
ddfreyne: feature request: it would be awesome if verbose output would let us know which things were actually recompiled, only to be "skipped" because they were identical.
<tom[]>
odd. i gem update'd today
<bobthecow>
are you using bundler?
<bobthecow>
rbenv/rvm?
<tom[]>
i think so
<tom[]>
bundle update. Using nanoc (3.6.6)
<tom[]>
same compile time
VitamineD has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
alerante has joined #nanoc
pavelkunc has joined #nanoc
tom[] is now known as tom[`tom`]
<dkm>
how does one set exit status in a cri command?
<dkm>
oh, I guess just with 'exit', nevermind!
<bobthecow>
exit 0 / exit 1
<bobthecow>
what are you building?
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
<ddfreyne>
bobthecow: That is what “identical” does (as opposed to “skipped”)
pavelkunc has quit [Client Quit]
<ddfreyne>
Haven't had a lot of time to work on nanoc 4.x lately
<ddfreyne>
(I also felt the need to do other things. But who doesn’t? :P)
<bobthecow>
oh right, i forgot that there was in identical in verbose output. i hadn't enabled it in a while :P
<bobthecow>
moral of the story: try the thing you're asking for before asking, because someone prolly thought of it before you.
<ddfreyne>
bobthecow: can't remember whether I asked you to take a look at these two PRs:
jarr0dsz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jarr0dsz has joined #nanoc
<bobthecow>
ddfreyne: i think i know someone who knows them.
<bobthecow>
i can poke if you want.
<ddfreyne>
Let me try and mess around a bit more before I give up
<bobthecow>
related to the "identical" thing, it would be awesome if i could get something like output.diff but that told me why something was recompiled.
<ddfreyne>
Once these three issues are resolved, I'll release 3.6.7
<bobthecow>
aliases, robots, sitemap all depend on everything in the site.
<bobthecow>
projects actually changed.
<bobthecow>
i'm not sure what the deal with the css files is, but i'm sure it's something to do with dependency calculation for LESS.
<bobthecow>
but wtf is with the wtf tag?
<bobthecow>
i can't come up with any reason that would recompile.
<bobthecow>
but now that it happened, i can't re-recompile and find out why.
<bobthecow>
so a file i could look at afterwords, like output.diff, would be super rad.
<ddfreyne>
Dependencies are scary :(
<bobthecow>
i know. but i'm pretty good at tracking down what made them depend on the wrong thing... once i figure out what they actually depended on :)
<bobthecow>
if something is reliably recompiling, that's one thing.
<bobthecow>
because i can keep running it and debugging until i find it.
<bobthecow>
but for something like this, i have no way of knowing why that recompiled.
<bobthecow>
so either a log file or an output.diff-style file i can look at after i notice something weird in a compile would be awesome.
<ddfreyne>
Yeah.
<ddfreyne>
So a `nanoc show-dependencies` before running `compile`?
jarr0dsz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<bobthecow>
but without the added overhead of loading my site up twice :P
<ddfreyne>
bobthecow: Yup
<ddfreyne>
bobthecow: Poke those Sass guys. I'm out of ideas.
<bobthecow>
k.
<ddfreyne>
I tried overriding Sass::Importers::Filesystem's #_find in my subclass that records @include'd filenames, but even if #_find returns nil, the site still compiles
<ddfreyne>
So I'm likely hooking into the wrong thing
<bobthecow>
comment on the issue? i'll point them at that.
<ddfreyne>
(This was not a problem before, because the Sass filter generated too many dependencies. Now that it more selectively generates dependencies, it's wrong)
<ddfreyne>
bobthecow: I also closed https://github.com/nanoc/nanoc/issues/294 because it seems to me a YAML timezone issue that was resolved by adding the troubleshooting entry