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
<bobthecow> ddfreyne: commented.
<bobthecow> ddfreyne: hrm. if you're not using rainbow, who is?
<bobthecow> oh. rubocop uses rainbow.
<bobthecow> cri uses colored.
alerante has quit [Remote host closed the connection]
<bobthecow> okay. effing core mixins.
<bobthecow> colored mixes in a private method called color into String.
<bobthecow> rainbow, by default, mixes in a public method called color.
<bobthecow> they do different things.
<bobthecow> as of 2.0, rainbow won't mix in by default.
<bobthecow> which will be awesome.
<bobthecow> you know, cri could solve this by switching to rainbow ;)
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
alerante has quit [Changing host]
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
Jutah_ has joined #nanoc
louquillio has quit [Ping timeout: 240 seconds]
Jutah has quit [Ping timeout: 240 seconds]
antognolli has quit [Ping timeout: 240 seconds]
Jutah_ is now known as Jutah
louquillio has joined #nanoc
antognolli has joined #nanoc
alerante has joined #nanoc
alerante has quit [Remote host closed the connection]
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ics has joined #nanoc
number-six has quit [*.net *.split]
bobthecow has quit [*.net *.split]
number-six has joined #nanoc
bobthecow has joined #nanoc
number-six has quit [Excess Flood]
number-six has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 240 seconds]
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 246 seconds]
<ddfreyne> bobthecow: I've had issues with that before... hmmm.
<ddfreyne> bobthecow: Gah, problem with argument_groups...
<ddfreyne> bobthecow: Imagine having 'rm -f -- -blah' to delete the file '-blah'. The -- stops option parsing and starts a new argument group. Currently, cri only creates a new argument group if the previous one is not empty. So the argument groups in this case will be [ [ '-blah' ] ] which makes sense.
<ddfreyne> However, `git checkout -- blah` <- argument_groups will be [ [ 'blah' ] ], not [ [], [ 'blah' ] ]
alerante has joined #nanoc
alerante has quit [Ping timeout: 252 seconds]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 252 seconds]
alerante has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alerante has quit [Remote host closed the connection]
relix has joined #nanoc
relix has quit [Ping timeout: 272 seconds]
alerante has joined #nanoc
relix has joined #nanoc
relix has quit [Ping timeout: 252 seconds]
<bobthecow> :(
<bobthecow> ddfreyne: i don't actually know of any prior art for that.
<bobthecow> i can think of programs that use -- to disambiguate positional arguments, and i can think of programs that use -- to stop processing flags.
<bobthecow> git add, for example.
<bobthecow> echo "foo" > -whot; git add -whot
<bobthecow> it says to use `git add -- -whot`
<bobthecow> but `git checkout` lets you use flags anywhere before the file arguments.
tantalum has joined #nanoc
iosdiof has joined #nanoc
<bobthecow> ddfreyne: release v2.5.0!
<bobthecow> you know you want to!
<ddfreyne> bobthecow: Hmm.
<ddfreyne> bobthecow: Not until this problem is resolved in a reasonable way (either by code, or by explaining things)
<ddfreyne> bobthecow: atm, `git checkout -- blah` will not work (it will be treated the same as `git checkout blah`)
<bobthecow> i think dropping that empty? condition like i mentioned is the ideal solution.
<ddfreyne> hmmm.
<bobthecow> what's your concern with that?
<bobthecow> *most* people only need it for the first style (stopping parsing options flags)
<bobthecow> the few people who need it for the second style can deal with the hassles that come with it.
<bobthecow> i don't think there's a good way to magically make it work for both stopping options parsing and separating argument groups without making the dev do a little work defining what she wants.
<ddfreyne> bobthecow: How would you use -- to stop option parsing in e.g. `git checkout -- -blah` ?
<ddfreyne> It won't work and I don't see a way to work around that easily...
<bobthecow> that's what i'm saying... git handles it themselves because it's an edge case.
<bobthecow> git add -blah
<bobthecow> git add -- -blah
<bobthecow> ^ that acts like you'd expect.
<ddfreyne> bobthecow: How about not having argument_groups, but rather an option to get the list of arguments *including* -- ?
<bobthecow> because in git add, -- has no special argument group meaning.
<ddfreyne> raw_arguments or so.
<bobthecow> but then we're back to what i think is the most common case: needing to split arguments on those --
<bobthecow> and now devs have to do it by hand.
<bobthecow> having access to the raw arguments wouldn't be a bad thing, but i still think there's value for argument groups.
<bobthecow> that said, i can write my own wrapper in my base class if i have access to raw arguments.
<ddfreyne> bobthecow: My issue with argument_groups right now is that any solution will be opinionated, and it will not cater to all users
<ddfreyne> I'd rather provide something more low-level, with the possibility for users to treat the data they want it
<bobthecow> works for me.
<bobthecow> i think going back to the earlier idea of an array-ish for arguments would be better.
<bobthecow> then you could have methods on it for getting groups.
<bobthecow> methods for getting raw.
<bobthecow> etc.
<ddfreyne> bobthecow: Yeah, ArgumentArray, and cri would provide #raw and allow users to extend that (by e.g. adding #grouped or so)
<bobthecow> fwiw, my needs would be best met by something like this: args :field, values: 0..-1, files: 1..-1
<bobthecow> i almost wrote that.
<ddfreyne> what is field, values and files in this case?
<bobthecow> but without a good heuristic the partition between values and files would have to be explicit.
<bobthecow> argument names.
<bobthecow> three positional arguments, two of which are arrays.
<ddfreyne> Right
<bobthecow> but it needs the heuristic for implied grouping to be fully awesome.
<bobthecow> some of my commands have a signature like this:
ics has joined #nanoc
<bobthecow> args :field, :value, files: 1..-1
<bobthecow> others:
<bobthecow> args :field, files: 1..-1
<bobthecow> right now i've got one DSL extension for dealing with the value/values/nil middle chunk, but it's a bit ugly.
<ddfreyne> hm yeah
<ddfreyne> bobthecow: `if (i = args.index('--'))` <- this will never work in cri atm, because -- is never part of args. With ArgumentArray#raw this could work though
<bobthecow> i know. that was there as a placeholder.
<bobthecow> while i was waiting for the groups issue to be resolved.
<ddfreyne> the `args` there could be replaced by `args.raw` and it'd work, given ArgumentsArray#raw is implemented
<bobthecow> yeah.
<bobthecow> for cp, the positional args dsl call would be
<bobthecow> args from: 1..-1, :to
ics has quit [Ping timeout: 252 seconds]
<bobthecow> for git checkout:
<bobthecow> args ref: 0..1, files: 0..1
<bobthecow> 0..-1 rather
<bobthecow> again, not super useful without the heuristic for splitting it.
<ddfreyne> bobthecow: Maybe being able to assign a custom ArgumentArray subclass to each command would be nice.
<bobthecow> maybe, but that might be a bit overkill, right?
<ddfreyne> e.g. CheckoutArgumentArray with #branch and #files
<bobthecow> yeah, i was going to make the #args dsl method implement named methods for each of its argument/groups
<bobthecow> so if you called `args from: 1..-1, :to` it would make a #from that returns arguments[0..-2] and a #to that returns arguments.last
<bobthecow> but if there's an ArgumentArray, putting those methods on the argument class would be even better.
<bobthecow> arguments.from, arguments.to
<ddfreyne> But the #from and #to from one command can be different on another command
<bobthecow> right. so you only mix in the ones that apply.
ics has joined #nanoc
<bobthecow> anyway, i didn't implement the dsl method because it's not as useful for anything besides super basic positional argument lists.
<bobthecow> as soon as you need logic to guess (is this argument a file?) it stops being awesome.
<ddfreyne> So do you agree being able to assign custom ArgumentArray subclasses is useful?
<bobthecow> maybe use a struct-like constructor for ArgumentArray so that for normal use you don't have to subclass?
<ddfreyne> Not sure what you mean there
<ddfreyne> you can always pass Class.new(ArgumentArray) etc
<ddfreyne> Hm.
<ddfreyne> ArgumentArray subclasses are probably a bit silly because you can define this stuff in the command dsl anyway
<ddfreyne> OK, so just ArgumentArray which implements #raw.
<bobthecow> meaning, if argumentarray constructor could take something that indicated what positions were what.
<bobthecow> for me, the weirdest thing i have to deal with isn't the split between values and files, it's the fact that the first argument is always popped off before splitting.
<bobthecow> so with argument groups, it was coming out of the first group.
<ddfreyne> bobthecow: What about args 0 => :field, 1 => :blah, 2..-1 => :otherstuff, and then you'd be able to do arguments[:blah] and get the 1st arg?
<bobthecow> that's what i was saying, but with a prettier dsl :P
<bobthecow> having it accept a symbol as an index is weird if it's an array-ish though.
<ddfreyne> Yeah, maybe the other way around
<bobthecow> args :field, :blah, otherstuff: 0..-1
<ddfreyne> Still, that is a separate nice feature that is not necessarily related to argument_groups
<bobthecow> the ranges like that make more sense to me.
<bobthecow> true.
<bobthecow> related but not so much.
<ddfreyne> Step 1: ArgumentArray with #raw
<bobthecow> just related in that it makes things weird when you're trying to extract explicit positional arguments out of the groups.
<ddfreyne> Step 2: symbolic names for arguments
<ddfreyne> Hmmmm.
<ddfreyne> args 0 => :field, 1..-1 => [ :tags, :files ]
<ddfreyne> and then split on --... would that work in this case?
<bobthecow> ,
<ddfreyne> How do you model `git checkout` using that though? I don't think you can
<bobthecow> maybe, but it's back to the heuristic for splitting when there's no explicit --
<bobthecow> you'd have to allow a proc or something.
<bobthecow> maybe we say you can model simple things, but anything complex needs custom stuff?
<bobthecow> args :field, 1..-1 => :everythingelse
<bobthecow> and you have to split that using arguments[:everythingelse].groups
<ddfreyne> Is it really worth implementing something like this?
<bobthecow> or whatever.
<bobthecow> dunno.
<bobthecow> in my case, 80% of my commands could use a simple args.
<bobthecow> only the ones requiring multiple values in the argument signature would need the custom code.
<bobthecow> most of mine have the signature: <command> <field> <value> <file> [<file> ...]
<bobthecow> or: <command> <field> <file> [<file> ...]
<bobthecow> those ones are easy to model using a dsl call.
<bobthecow> the complicated one is: <command> <field> <value> [<value> ...] <file> [<file> ...]
<bobthecow> and that's only 20% of my commands.
<ddfreyne> bobthecow: But the basic ones are easy to model using a custom CommandRunner anyway (say, FieldFilesCommandRunner and FieldValueFilesCommandRunner or so)
<ddfreyne> (or mixin, if you want)
<ddfreyne> So it seems to me that getting hold of the “raw” arguments (with --) definitely seems worth it, because it gives enough power to disambiguate arguments
<ddfreyne> And whether you want a DSL for assigning symbolic names to arguments or not is then up to you, extending cri with what you need
<ddfreyne> bobthecow: ATM I feel that anything more than ArgumentsArray#raw is overkill, but I'd like to play around with symbolic names for arguments in the nanoc CLI and see how I can write something that is generally usable so that it fits most people's use cases
<ddfreyne> bobthecow: I like cri right now, because it has zero bloat and I want to keep it that way
<bobthecow> ddfreyne: i agree. #raw would get me what i need right now.
<bobthecow> i don't think having #groups would hurt though.
relix has joined #nanoc
<bobthecow> with empty groups where `command -- arg`.argument.groups == [[], ['arg']]
<bobthecow> s/argument/arguments/
tantalum has quit [Quit: Leaving]
<bobthecow> i removed the DSL extensions I had, simplified everything.
<bobthecow> now I just need arguments.raw to make it all work :)
louquillio has quit [Remote host closed the connection]
alerante has quit [Remote host closed the connection]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]