ddfreyne changed the topic of #nanoc to: 3.6.7 (dec 9th) | 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 | gregkare smells of elderberries
ics has joined #nanoc
<bobthecow> ddfreyne: poke
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> okay, guys. I made a thing, and you should all use it: https://github.com/bobthecow/forematter
<bobthecow> ddfreyne: ^
<dkm> bobthecow: consider gracefully handling "File not found" runtime errors?
<bobthecow> oop.
<bobthecow> yeah. that should have been on my todo list.
<bobthecow> :)
<bobthecow> it prints a stacktrace, right?
<dkm> it does
<bobthecow> it actually depends on the command... most of 'em print out a usage statement.
<dkm> and I mean really, I don't get why I have .#blah_blah.md broken symlinks, but I suppose that's a separate issue
<dkm> I blame emacs
<dkm> my usage was: find content/ -name '*.md' | xargs fore list tags
<bobthecow> oh. so there's something there, but it isn't a file.
<dkm> and there were bad files in the output of `find`
<dkm> yeah, I suppose I could do '-type f'
<bobthecow> open an issue?
<dkm> but actually that still crashes because find still considers the symlink to nowhere a file
<dkm> sure
<bobthecow> most commands should probably print something to stderr, but actually work?
<dkm> well, it should just skip that file
<dkm> if find returns a list of files, work on the ones that it can open, and print a message to stderr when it can't
<bobthecow> but print 'em to stderr.
jaspervdj has quit [Read error: Connection reset by peer]
<bobthecow> yeah. that's what cp does.
<dkm> but don't halt the processing of the rest of the list because of one bad apple
<bobthecow> makes sense.
<dkm> and grep, and wc, and...
<dkm> ultimately how that is best handled depends on the intent of the application
<bobthecow> fore: fakefile.md: No such file
<dkm> for a compiler for instance, it is likely that an error in one file will mean it is meaningless to process remaining files
<bobthecow> most fore commands are idempotent, and affect individual files.
<dkm> right
<bobthecow> fore add tags bacon *.md; fore add tags bacon *.md
<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.
<bobthecow> fore list unknown *.md
<bobthecow> doesn't fail.
ddfreyne changed the topic of #nanoc to: 3.6.7 (dec 9th) | 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
<ddfreyne> hai
<ddfreyne> God, so much text in here
<dkm> bobthecow: hmmm, more investigation is warrented, it seems
<bobthecow> ddfreyne: you've been gone too long ;)
<ddfreyne> bobthecow: I am not sure what you mena by --
<ddfreyne> bobthecow: -- marks the end of processing, so anything after it will end up in 'arguments'
<bobthecow> right.
<bobthecow> command subcommand foo bar -- baz
<bobthecow> that's also a common pattern ^
<ddfreyne> What would the point of having -- be then?
<bobthecow> used to disambiguate between types of positional arguments.
<ddfreyne> It's useful in e.g. command subcommand foo bar -- --baz
<bobthecow> in my case, `fore add tags ham bacon sausage *.md`
<ddfreyne> bobthecow: What about fore add tags ham,bacon,sausage *.md ?
<bobthecow> i'm adding three tags. currently, i do this by working from the back and finding all the files, then everything at the front is tags.
<bobthecow> but ham,bacon,sausage is a valid value for tags.
<ddfreyne> Hmm.
<ddfreyne> So you'd like tohave -- in the arguments array?
<bobthecow> the same way git checkout uses it.
<bobthecow> git checkout origin/master
<bobthecow> git checkout -- origin/master
<bobthecow> for disambiguating positional arguments
<bobthecow> i don't know if it makes sense to have it in the list... for most things you just want it to ensure that you don't process any more flags.
<bobthecow> but i at least need a way to split the argument list by that.
<ddfreyne> Yeah that is reasonable
<ddfreyne> Not sure how to implement that (while remaining backwards compatible)
<bobthecow> make arguments a not-quite-array
<bobthecow> with a method for getting chunks of arguments.
<bobthecow> foo bar -- baz -- qux --
<ddfreyne> bobthecow: Ahh, good idea
<bobthecow> [foo, bar], [baz], [qux]
<bobthecow> [foo, bar], [baz], [qux], nil
<ddfreyne> bobthecow: add an issue on the cri github repo
<bobthecow> kk
<ddfreyne> bobthecow: cool
louquillio has quit [Remote host closed the connection]
louquillio has joined #nanoc
louquillio has quit [Remote host closed the connection]
louquillio has joined #nanoc
tantalum has quit [Quit: Leaving]
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
whk has quit [Ping timeout: 272 seconds]
VitamineD has quit [Quit: VitamineD]
whk has joined #nanoc
jarr0dsz has joined #nanoc