ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jugglinmike has quit [Ping timeout: 245 seconds]
louquillio has quit [Remote host closed the connection]
louquillio has joined #nanoc
louquillio has quit [Remote host closed the connection]
ics has joined #nanoc
louquillio has joined #nanoc
zi_ has joined #nanoc
zi has quit [Ping timeout: 245 seconds]
zi_ is now known as zi
<guardian>
o/
<ddfreyne>
bobthecow: Nice. I don’t agree with everything Rubocop says, but I’m documenting the reasons why, too
VitamineD has quit [Quit: VitamineD]
<ddfreyne>
e.g. AsciiComments
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
VitamineD has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
VitamineD has quit [Quit: VitamineD]
jugglinmike has joined #nanoc
VitamineD has joined #nanoc
<tom[]>
i don't understand anything [Rubocop] says
tantalum has joined #nanoc
ics has joined #nanoc
<bobthecow>
ddfreyne: i figured ascii comments is easy enough to go along with.
<bobthecow>
might as well.
<bobthecow>
there are some things i disagree with (e.g. default hash whitespace rules) but the style guide says that the one rubocop enforces by default is just one of two valid options :)
<bobthecow>
you can run that as many times as you want, and it won't do anything different.
number-six has quit [Ping timeout: 252 seconds]
<bobthecow>
should it also keep on truckin' when you try to do a set operation on a non-set property?
<bobthecow>
right now it fails, but it fails on whatever file it ran into the error on.
<bobthecow>
fore add title "wheee!" *.md
<bobthecow>
if you have a scalar title (as most titles are) it fails gloriously.
<dkm>
I don't think so: rational, don't over-control what the user can do
<dkm>
maybe there is a valid use case in which someone would WANT to make the title be "weeee!" for a list of files?
<bobthecow>
no, that's not what i meant.
<dkm>
oh
<bobthecow>
if your title is already `title: "something"`
<bobthecow>
and you do `fore add title anythingatall *.md` it will fail.
<bobthecow>
because `add` is a set operation
<bobthecow>
array push.
<dkm>
oh, I see
<bobthecow>
fore set title "wheee!" *.md works.
<dkm>
ok, yeah, I think it should fail, but perhaps with a more descriptive reason
<dkm>
though I haven't seen the exact output yet
<bobthecow>
it's a stacktrace too :)
<bobthecow>
lib/forematter/commands/add.rb:22:in `block in run': title is not an array (RuntimeError)
<dkm>
yeah, just tried it
<bobthecow>
so the issue you open could be "don't print stacktraces for normal user input"
<bobthecow>
:P
<dkm>
I think I would prefer something like ForeError ("attempt to add an element to somethign that is not a container"
<dkm>
)
<dkm>
right, I think the stack trace is only useful if it crashes for some unanticipated reason
<bobthecow>
agreed.
<bobthecow>
i'd :+1: an issue like that.
<bobthecow>
and maybe even fix it soon :P
number-six has joined #nanoc
jaspervdj has joined #nanoc
tantalum has quit [Ping timeout: 260 seconds]
<dkm>
oh, this might actually be a bug...
<dkm>
list.rb:13:in `each': undefined method `downcase' for nil:NilClass (NoMethodError)
<bobthecow>
do you know what file it's processing?
<bobthecow>
that would also be a handy thing to know in the error message :)
<bobthecow>
i imagine it's for a non-existent field?
<bobthecow>
or a field that's null
<dkm>
yeah, I'm not sure because it was one out of a list of a whole lot
<dkm>
but I am pretty sure ... yeah ^^
<dkm>
I said find content/ -type f -name '*.md' | xargs fore list tags
<dkm>
and there are definitely some files in there that do not have a 'tags' field
<bobthecow>
it should skip those though.
<dkm>
find content/ -type f -name '*.md' | xargs fore list title works for the same list
<dkm>
so yeah
<dkm>
yeah, I think so
<bobthecow>
ddfreyne: i've got a feature request for cri: can i pretty pretty please get -- to pass through, or at least be able to partition my positional arguments based on that?
<bobthecow>
i need it to disambiguate `fore add tags foo bar *.md`
<bobthecow>
`fore add tags foo bar -- *.md`
<bobthecow>
because i can do things like this, which makes for lots of fun and excitement:
<bobthecow>
fore add tags *.md not-a-file *.txt
<bobthecow>
and it'll add every file in *.md _as a tag_ to *.txt
<bobthecow>
:-/
<dkm>
bobthecow: I could see a 'has' command being usefule
<dkm>
find content/ -type f -name '*.md' | xargs fore has tags
<dkm>
with a grep-like '-v' option that would invert the output to list all files that do not have 'tags'
<bobthecow>
ahh, yes.
<bobthecow>
oh.
<dkm>
also, while I agree passing '--' through would be useful, why not read file names from standard in if none are given as command line args?
<dkm>
or would it make more sense to read standard in as data with frontmatter?
<bobthecow>
i think the latter.
<dkm>
either way, standard in should be used for something
<bobthecow>
yeah.
<bobthecow>
i agree.
<bobthecow>
i haven't gotten that far yet.
<bobthecow>
this is just v0.1 :)
<dkm>
understandable :)
<bobthecow>
open an issue for each of those feature requests though.
<dkm>
I agree, using standard in to read raw data would be more consistent
<dkm>
I think though it would be useufl to provie a command line argument that would treat standard in as a list of files
<bobthecow>
why not just xargs them then?
<dkm>
the reason being, the 'argv' buffer is finite
<bobthecow>
ahh. right.
<dkm>
so `#find command that produces a bagillion files | fore list tags` will produce unexpected results
<bobthecow>
any idea what the limits of argv buffer might be?
<dkm>
I think it is system dependant
<bobthecow>
things like `fore classify` could blow up spectacularly if you put too many things through it.
<dkm>
big enough that I've never run into it, it was actually a student in my class that pointed it out to me when I said something about passing "thousands of files" to grep
<bobthecow>
i think i've actually run into it before once or twice.
<dkm>
for something like 'fore' it is more likely to run into
<dkm>
since a standard use case would be to use it on very large lists of file names
<bobthecow>
i used to work for an ecommerce company with tens of millions of customers, and i might have run a command or two with large subsets of them as args :)
<dkm>
I could see it happening there for sure :)
bitsynthesis has joined #nanoc
<bitsynthesis>
hello #nanoc
<bobthecow>
hey bitsynthesis;
<bobthecow>
sup?
<bitsynthesis>
hi bobthecow! i'm interested in whether nanoc supports any sort of post processor functionality. i saw it in the future-features list
<bitsynthesis>
basically i'm looking to use nanoc for managing html email templates so i have to inline the styles after compilation
<bitsynthesis>
i can do this with a rake task that does the compile and then does the inlining
<bitsynthesis>
but thought i'd see what the recommended nanoc way would be
<dkm>
bobthecow: `getconf ARG_MAX` on linux, possibly OS X?
<bobthecow>
so do you need the template in both forms, or just in the inlined form?
<bitsynthesis>
just inlined
<bobthecow>
dkm: 262144
<bobthecow>
(os x)
<bobthecow>
seems consistent with how many chunks i had to break that command up into back in the day.
<dkm>
2097152 (on linux)
<bobthecow>
os x has a lot lower limits for things.
<bobthecow>
max files is absurdly low by default.
<dkm>
the explination I found was "The actual limit on argv is a limit on the total bytes used to represent both the argv and env values for an exec call"
<bobthecow>
bitsynthesis: if you only need them inlined, then make that part of your nanoc ruleset for those items.
<bobthecow>
dkm: oh, the env values too?
<dkm>
apparently, according to this one source
<dkm>
I should look more into the exec call and how it interacts with the system
<bobthecow>
huh. i wouldn't have guessed that it included env, but i guess that makes sense.
<bitsynthesis>
aha, gotcha. i'll run with that, thanks
<bobthecow>
are you using a library to do the inlining?
<bitsynthesis>
yeah, probably gonna use the premailer gem
<bobthecow>
i've seen it, but haven't had to inline styles in a while.
<bobthecow>
let me know what you come up with, though, because i think i have a good use case for inlining styles on my site.
<bitsynthesis>
will do. i think it's an exciting (as html email goes) project. the goal is to pull all our html email templates out of our SAAS email provider and into nanoc to allow for more flexible templating, inlining, possibly sass, and version control.
<bobthecow>
yeah, that seems like a great idea.
<bobthecow>
and if your email provider has a REST api, you could write a nanoc deployer to upload them again.
<bobthecow>
nanoc compile && nanoc deploy
<bobthecow>
:)
<bitsynthesis>
indeed they do. i hadn't even considered that!
tantalum has joined #nanoc
<bobthecow>
dkm: i'm not sure your issue #2 is exactly what you think it is.