[07:46] fwereade: morning! [07:47] wrtp, heyhey [07:47] wrtp, how are you? [07:47] fwereade: just got back from my bike ride; not raining this morning, yay! [07:48] wrtp, nice [07:48] fwereade: and my 82 year old ex-lorry-driver neighbour just told me that 12.04 is out on Thursday [07:48] wrtp, awesome :D [07:48] fwereade: (which i didn't actually know!) [07:49] wrtp, better yet -- community in action ;p [08:25] morning [08:35] heya TheMue [10:53] Lunchtime ... [11:10] fwereade: i've been thinking about SuperCommand etc [11:10] wrtp, cool, go on [11:11] fwereade: the fact that when SuperCommand parses itself again it misses the flags added by LoggingCommand seems like an indication of something wrong structurally. [11:12] fwereade: and i *think* i have an idea for a way to fix it [11:12] wrtp, cool, it's seemed likely that everyone else can see an obvious design that I've missed ;P [11:13] fwereade: the underlying problem is, i think, that you're trying to use LoggingCommand to add functionality to SuperCommand, but it doesn't - it just embeds it as you know. [11:13] wrtp, it seemed to me like a good and sane consequence of embedding over inheritance [11:13] wrtp, yep [11:13] fwereade: how about actually providing a hook for SuperCommand to do the flag parsing. [11:13] fwereade: because SuperCommand doesn't have any flags itself, so why not let its user add them? [11:14] * fwereade thinks [11:14] fwereade: so it could have a SetInitFlagSet(func(*gnuflag.FlagSet)) method for example [11:17] wrtp, I think it'd also need hooks for the other methods too though [11:17] fwereade: or that function could be an argument to NewSuperCommand [11:17] wrtp, we need to do something with them in Run() [11:17] fwereade: which other methods? [11:18] wrtp, Run and potentially ParsePositional-or-whatever-it-is could each want to do something with the flags on the logging type [11:19] fwereade: ParsePositional sounds wrong, as it would never get any positional arguments [11:19] wrtp, ParsePositional on supercommand always gets the subcommand as a positional arg [11:20] wrtp, and all the subcmd's args as well because it doesn't intersperse [11:21] wrtp, (incidentally I like `func Reduce(args []string) (Command, []string, error)`) [11:21] wrtp, then for consistency's sake you'd want (bare) Parse to return the final command ready to Run [11:22] wrtp, and that would actually always be the one originally passed in, but doesn't *have* to be [11:24] oh the twisted heaps we create just so we can intermix global flags and command-specific flags [11:27] fwereade: the thing is that having Reduce return a Command is *only* useful for the supercommand case AFAICS [11:28] wrtp, sure, but that bothers the other commands not one bit [11:29] fwereade: so rather than make that interface, which is used all over the place, more complex, why don't we make SuperCommand (which is a very small amount of code currently) slightly more complex instead? [11:29] wrtp, and it has a nice fit with the actual problem it's solving -- it is intuitively sensible that the process of parsing a given command be identical whether or not it's actually a subcommand [11:30] wrtp, it's used a certain amount; it amounts to writing ", nil" in a very few places [11:30] fwereade: i'm looking at the code that was deleted from SuperCommand in this CL and thinking: why can't the Logging piece implement just that code [11:31] fwereade: if you have that interface, it implies that a subcommand can itself return a subcommand [11:31] wrtp, IMO this is less of a cognitive load than adding two separate hooks to SuperCommand for InitFlagSet and Run [11:31] wrtp, well, actually, is there any reason it shouldn't? [11:32] fwereade: well, your current code wouldn't work - you'd need a loop [11:32] wrtp, like I suggest in the discussion already? [11:32] fwereade: oh, i didn't see that! [11:32] wrtp, ok it's a rubbish loop as I discovered when checking against reality but the core idea is there [11:33] fwereade: ok, here's another idea: make NewSuperCommand take a Command as an argument [11:33] fwereade: it will call Run but always with zero arguments [11:34] wrtp, hmm, at least it concatenates all the hooks into one package ;p [11:35] wrtp, I'm not sure that's intrinsically *better* than the loop idea... the fact that the loop works however many subcommands you have implies to me that it's well-suited to the problem [11:35] fwereade: then you'd call NewSuperCommand(name, doc, &LoggingSetupCommand{}) [11:35] fwereade: to me it seems like overengineering. that's not the problem we're trying to solve. [11:35] wrtp, yeah, but the set of Commands that can usefully go in there is limited [11:36] wrtp, it's not the same thing as a Command, its fundamental nature is a set of hooks rather than a command [11:37] fwereade: true. alternative: SuperCommand could define its own interface type to be used as an argument. [11:37] wrtp, this is still fundamentally the hooks idea [11:38] fwereade: indeed. but i think that's fundamentally what's going on. you want to "hook" the global flags into any arbitrary subcommand [11:38] wrtp, and given that we have just one way in which we need to tweak SuperCommand [11:38] wrtp, we end up reducing the code to precisely the original implementation [11:39] wrtp, because SuperCommand checks some status and then does something in response in each of InitFlagSet and Run [11:39] wrtp, and it's just that it's an implicit do-we-have-a-hook check instead of an explicit self.SetsLog check [11:39] wrtp, with additional tomfoolery to set it all up [11:40] wrtp, I don;t feel that's a win [11:40] fwereade: i'm not sure [11:41] wrtp, it may be more extensible in the future, but so is mine; they're both interestingly extensible in different ways and I don't think we currently have reason to prefer one over the other on that front [11:41] fwereade: i think the hooks possibility makes it easy to add more global flags that aren't related to logging. [11:41] wrtp, sure, that would be an awesome change at precisely the moment we actually have such a need [11:41] fwereade: and i think that the "return a command" thing we will never ever use apart from in supercommand. it seems to me like we're spreading supercommand mess around. [11:43] fwereade: for the record, this is the kind of thing i'm thinking of: http://paste.ubuntu.com/943945/ [11:44] fwereade: then all the ParsePositional stuff can remain exactly as it is now. [11:45] fwereade: and the logging set up code is almost identical to now [11:46] wrtp, ok, so that's still an extra type and extra setup work to do everything the original implementation did, in the same way, which I was asked to change [11:46] fwereade: that's true. but at least the concerns are now separated. SuperCommand now has nothing to do with logging. and the logic is quite easy to follow, i think. (but then i would, wouldn't i? :-)) [11:47] wrtp, how does SuperCommand as separated out have anything to do with logging in the first place? [11:48] fwereade: it doesn't, but it did, didn't it? [11:48] sorry, i'm not sure what the question is [11:48] fwereade: SuperCommand as you're proposing has nothing to do with logging, no. [11:49] fwereade: but i'm not keen on the way that it makes all commands into recursive Command producers. i think that adds to cognitive load, when we can isolate it into SuperCommand. [11:50] wrtp, I think that the right doc for Reduce could make it all very clear [11:51] wrtp, in practice, returning 2 nils in a few places is not an especially painful cost [11:51] fwereade: but there's always the question: why are *all* these commands returning Command when *none* of them apart from SuperCommand uses that functionality? [11:51] fwereade: or will ever use that functionality... [11:52] wrtp, can we keep the unknowable future off the table? [11:54] fwereade: when i first read the SuperCommand code, i had to spend a little while, as i didn't find it easy to see what was going on. I now understand it (and I think it's nice for the problem being solved), but i really think that the whole recursive command thing belongs *there*, not in every command that's being implemented. the Command interface should map nicely to the command interface we want to implement IMHO. [11:58] * fwereade is still thinking [11:59] * wrtp is trying to work out if he's being unreasonable. [12:00] * wrtp hopes not :-) === wrtp is now known as rogpeppe [12:00] wrtp, I understand your concerns -- I think -- but they don't carry the same weight in my mind [12:00] rogpeppe, ^^ [12:01] :-) [12:01] rogpeppe, consider that (bare) Parse itself is only ever called with a SuperCommand in my proposal [12:01] rogpeppe, there is, as there always was, a certain commingling of functionality [12:02] fwereade: which Parse are you referring to there? [12:02] rogpeppe, the precise balance at a given point depends on the needs of the current codebase [12:02] rogpeppe, cmd.Parse [12:04] rogpeppe, it will surely become immediately apparent if the future needs of the codebase require that we rearrange the responsibilities of the cmd package [12:04] [13:01] rogpeppe, consider that (bare) Parse itself is only ever called with a SuperCommand in my proposal [12:04] isn't it called with a LoggingSuperCommand? [12:05] rogpeppe, ha, ok, something that flawlessly impersonates a SuperCommand, if you must [12:06] rogpeppe, but that definition only lends weight to my assertion that Parse, which is called with two distinct things that both expect this behaviour, is correct to accommodate their shared functionality [12:06] fwereade: not quite flawlessly... (given the recursive calling problem) :-) [12:06] * fwereade concedes somewhat grudgingly [12:08] rogpeppe, the trouble is still that, considering proposals [rog] and [original], [rog] does what [original] did, and adds a bunch of other stuff that's only used in one case; [original] failed to find favour, and I don't think that an implementation that does just the same thing, but with more boilerplate, is likely to fly [12:08] Hello! [12:08] niemeyer, heyhey [12:08] niemeyer: yo! [12:09] fwereade: While you're there, I don't understand why we need recursion at all :-) [12:09] +1 ! [12:09] niemeyer, rogpeppe: it is now a loop ;p [12:09] fwereade: Not even that! [12:10] fwereade: recursion via Y-combinator :-) [12:10] fwereade: more, err := scmd.Consume(args) [12:10] fwereade: ... [12:10] niemeyer: no, we need some sort of repeated parsing whatever we do [12:10] fwereade: subcmd := scmd.subcmds[name] [12:10] fwereade: subcmd.Consume(args) [12:10] niemeyer: this is my current preferred proposal: http://paste.ubuntu.com/943945/ [12:10] fwereade: This is a linear call.. supercommand calls subcommand.. [12:11] niemeyer: moin [12:11] * niemeyer looks [12:11] TheMue: Heya [12:11] niemeyer, wait, so supercommand Consume calls subcmd Consume? [12:11] rogpeppe: That works too [12:12] fwereade: Yeah, that sounds fine in principle.. am I missing something? [12:12] niemeyer, well, subcommands can have flags, and cmd.Parse is already set up to deal with flags before passing the positional args on to Reduce/Consume/whatever-it-currently-is [12:13] niemeyer, duplicating that in SuperCommand would seem to be kinda rubbish [12:13] i like the current names. InitFlagSet, ParsePositional and Run work well for me. [12:14] niemeyer, rogpeppe: we have always had recursive Parse calls; they were disguised by being indirect, via ParsePositional, but it was always how it worked [12:14] fwereade: Sorry, I don't understand.. probably because I don't have the picture so clear in my head as you do [12:14] as i said earlier, that's an interface that works well for commands, even if it isn't quite sufficient for SuperCommand. [12:14] fwereade: I know.. and as I mentioned in the review, I've always disliked that.. it's magical, and unnecessary, iMO [12:14] fwereade: The problem seems so simple.. I don't get why we need all this back and forth [12:15] fwereade: SuperCommand wraps a number of subcommands.. it gets called, handles what it must, and delegates the rest [12:15] fwereade: No recursion, no looping [12:15] niemeyer: the fundamental difficulty is the mixing of global and sumcommand flags AFAICS [12:15] s/sumcom/subcom/ [12:15] niemeyer, how many times do we call Parse on a FlagSet in the course of this? [12:15] niemeyer, twice! there are two parsing steps needed [12:16] and we call InitFlagSet three times, right? [12:16] fwereade: Yep.. twice, exactly.. not more, not less [12:16] rogpeppe, we may create a fresh FlagSet for usage output [12:16] fwereade: No need for recursion or looping in that case [12:16] twice on the supercommand and once on the subcommand [12:16] fwereade: ah, makes sense [12:17] niemeyer, well, once *or* twice really, given that we expect Parse to work on anything that implements Command [12:17] fwereade: Parse should be completely unaware about any of that [12:18] fwereade: is there a particular reason we export cmd.Parse BTW? does anything outside of the cmd package actually use it? [12:18] fwereade: as should the interface of Command [12:18] fwereade: The only particularity is that a supercommand needs to call the subcommand.. that's all really [12:18] fwereade: The mechanisms out of the supercommand should not be aware of that [12:18] niemeyer, and mingle flaget flags [12:19] i'm all for mingling flagets [12:19] fwereade: ? [12:20] niemeyer, the client of Parse doesn't see a difference; AFAICT the point of difficulty is in the interface for Command itself, right? [12:21] niemeyer, sorry, misunderstood [12:21] fwereade: Maybe I should just try to code a sketch [12:21] fwereade: that's true for me, certainly. i think the interface for Command works well, and we're mangling it solely because of SuperCommand issues. [12:21] niemeyer, I was saying the SC needs both to select subcommands and reregister its own flags [12:21] fwereade: I'm unhappy about this: [12:21] func (c *SuperCommand) InitFlagSet(f *gnuflag.FlagSet) { [12:21] if c.subcmd != nil { [12:21] c.subcmd.InitFlagSet(f) [12:22] fwereade: This is all magical.. [12:22] fwereade: It's called once, somewhere, and then twice, in a full moon [12:22] fwereade: Maybe it's set, or not.. and behaves in one way or the other.. [12:23] fwereade: and most methods go like that.. [12:23] fwereade: [12:23] func (c *SuperCommand) Info() *Info { [12:23] var info *Info [12:23] if c.subcmd != nil { [12:23] niemeyer, as I recall we discussed this in some detail and it seemed to be the right way to deal with the legacy interspersed-or-not flag ickiness [12:23] fwereade: My reaction to it, IIRC, is that it was a bit on the clever side and practical, even if it was hard to understand [12:24] fwereade: Things are now being extended into other directions that extend the cleverness through the interface of Command, Parse, documenting recursiveness in the interface itself, etc [12:24] fwereade: I'm getting lost [12:25] fwereade: I totally admit it's probably my small brain, but I'd love if we could make this straightforward somehow [12:25] fwereade: It sounds simple just from the description of what we need [12:25] niemeyer: the heart of it is in the requirement that we handle both "juju -v bootstrap" and "juju bootstrap -v" [12:26] [13:24] fwereade: Things are now being extended into other directions that extend the cleverness through the interface of Command, Parse, documenting recursiveness in the interface itself, etc [12:26] +1 [12:26] fwereade: Ok, but that *sounds* (and I may be missing details for sure) simple.. [12:27] fwereade: The supercommand is wrapping the subcommands.. it is in control of what happens [12:27] fwereade: It knows there are only two possible layers, and it has the second layer entirely at its will [12:28] niemeyer: to give you a bit of context on my thinking, would you read the comments on https://codereview.appspot.com/6107048/ and https://codereview.appspot.com/6100050/ please? [12:30] fwereade: I had read the first one before we started to talk.. checking the second [12:33] fwereade: Done [12:33] niemeyer, is anything I'm saying sounding any saner? [12:34] fwereade: Everything you say is sane.. I just believe the problem may be solved in a simpler way [12:35] fwereade: I'll give it a quick shot [12:35] niemeyer, before you do [12:35] fwereade: A hack, arguably, but hopefully it'll be helpful [12:35] niemeyer, you seemed to like rog's proposal [12:36] fwereade: I don't think it's necessary either [12:36] niemeyer, ok then :) [12:37] fwereade: Maybe it will be, though.. once we want to use supercommand with other globals [12:37] fwereade: But this is an aside.. the key point I'm making around non-recursiveness and non-looping is independent from it [12:37] niemeyer, I feel that's a touch speculative [12:38] fwereade: Sure, I've been speculating since we first talked about this, and I'm now trying to stop speculating to show some code :) [13:10] fwereade, niemeyer: here's a version of supercommand with no recursive magic: http://paste.ubuntu.com/944043/ [13:11] niemeyer: So, I now branched my last branch at the point before I modified the NeedsUpgrade behavior, but also before doing the changes of the according review. Do you expect a propose now to first take a look that this branch is in a proper state or shall I first do the review changes and then propose again? [13:11] (branched from a slightly earlier version, so using ParsePositional, as i believe Consume was added only for the recursive thing) [13:11] rogpeppe, how do you switch off logging? [13:12] TheMue: Feel free to do the review changes [13:12] fwereade: the logging flags thing is orthogonal to this. [13:12] niemeyer: ok [13:12] fwereade: i still think my GlobalFlags proposal would work well [13:12] rogpeppe: Cheers.. I'm looking at this as well, as I mentioned [13:13] rogpeppe, and, yes; you eliminate recursion by having a function that parses flags call a different function that parses flags in exactly the same way [13:13] niemeyer: sorry, i'd already been playing with it, so thought i'd push out something to think about. [13:13] fwereade: not exactly - it adds extra flags [13:14] rogpeppe: No worries.. I'm just trying to focus on it for a moment to understand the problem better [13:14] fwereade: that's *the* crucial reason why SuperCommand exists, AFAICS [13:14] rogpeppe, that it gets in the exact same way that Parse does... [13:15] rogpeppe, there is repetition inherent in this problem [13:15] rogpeppe, we can loop or we can recurse or we can duplicate code and kid ourselves that it's simpler because we've managed to avoid a loop [13:15] fwereade: the entire reason for the recursion was so that we could reuse the 6 (!) lines of Parse? [13:17] rogpeppe, well, there are many reasons all of which interrelate in one way or another, but yes, that is one of them [13:17] fwereade: when nothing actually calls Parse itself other than Main, AFAICS. we could inline it into Main and noone would notice, i think. [13:18] fwereade: i think the version of SuperCommand.ParsePositional i posted shows very directly the logic of SuperCommand. [13:20] rogpeppe, yes it does, it looks to me very very much like the original version, except it wantonly duplicates the logic in Parse rather than just calling it; and it doesn't allow global args to come after the command, which was a requirement [13:20] fwereade: it *does* allow global args to come after the command [13:20] fwereade: it passes all tests [13:22] rogpeppe, I don't see where you register the global flags for the second flagset Parse [13:22] fwereade: newFlagSet [13:23] fwereade: actually i was confused by that at first. [13:23] fwereade: i'm not sure newFlagSet should take a Command, but that's another issue [13:24] rogpeppe, well, the way you're using it makes it wrong; the way it was used before was fine ;) [13:25] fwereade: ok, perhaps [13:26] rogpeppe, still, I just do not get how repetition is not part of the problem [13:26] fwereade: repetition of what? [13:26] rogpeppe, and why I am being criticised for using elementary constructs which express repetition [13:26] rogpeppe, repetition of parsing [13:26] rogpeppe, one Command parses part of the command line and delegates to another for the rest [13:27] rogpeppe, this is two parses; one would also be perfectly legitimate, because Parse should accept a Command [13:28] fwereade: the repetition is performed once only, but you're making a very general mechanism to replace something that's uses exactly the same lines of code [13:28] fwereade: You're not being criticised.. I'm trying to simplify the logic we (the team) has in place.. that's impersonal [13:28] niemeyer: +1 [13:29] niemeyer, rogpeppe: sorry, inappropriate language, I sometimes come to identify with my code a touch too much, ty for reminder [13:29] fwereade: Your code was largely reviewed and agreed with [13:31] fwereade: this is all the diff it takes to make your code non-recursive and everything else can carry on using exactly the same interface before: http://paste.ubuntu.com/944063/ [13:31] fwereade: i don't see how that's not a win [13:33] rogpeppe, ok, the internal implementation should not matter; do we agree that the real pain point is in returning things other than errors from ParsePositional [13:33] ? [13:33] fwereade: what do we want to return from ParsePositional? [13:33] rogpeppe, well, an error, right? that's the interface you've been fighting to preserve [13:34] fwereade: "the real pain point is in returning things other than errors" [13:34] fwereade: so what else do we want to return? [13:35] rogpeppe: I'm starting to think: a command and list of unconsumed args (which replaces ourself entirely if used and is in practice nil, nil for most Commands, although there are other plausible uses of such a mechanism) [13:35] rogpeppe, plus an error [13:35] fwereade: but why? [13:36] rogpeppe, because it is a perfect fit for the problem space and reduces duplication [13:36] fwereade: we're talking 6 lines of duplication here! [13:36] fwereade: and you're proposing to change the interface in many places just because of that? [13:36] rogpeppe, and you're saying that 6 lines of duplication is a *better* thing than a loop to express the same repetition? [13:37] fwereade: yes [13:38] g'morning [13:38] * hazmat is glad to finally be home [13:38] rogpeppe, in and of itself that makes little sense to me; with the wider context of "because it allows us to have a cleaner signature for ParsePositional" I can understand it [13:38] heya hazmat [13:38] fwereade: {fmt.Println("a"); fmt.Println("b")} can be better than for _, s := range []string{"a", b"} {fmt.Println(s)} [13:38] hazmat: hiya [13:39] fwereade: and in this case, it's not strict repetition - the body of the loop is slightly different each time through. [13:39] fwereade: FWIW, I'm still on it.. [13:43] fwereade: if it *was* a simple loop, i wouldn't mind much. my problem is with the fact that to avoid this repetition you're proposing complicating the Command interface that's implemented everywhere. [13:48] rogpeppe, where by "everywhere" you mean "in two places"? [13:49] rogpeppe, hm, sorry, suddenly unsure whether you're looking at the version with FlagCommand [13:49] rogpeppe, ok, 3 places, FlagCommand implements it ;) [13:49] fwereade: ah, i'm not. [13:49] fwereade: but still. [13:50] fwereade: it's implemented (even if only with embedding) by every subcommand [13:50] rogpeppe, I guess this may be one of the sources of disconnect; my position is that the prectical cost is utterly minimal [13:51] fwereade: the Command interface is something that people will see when maintaining the code. it's a very good thing that it's as simple as possible. [13:52] fwereade: both myself and niemeyer found the recursive nature of supercommand difficult to understand. [13:52] rogpeppe, I thought one of the benefits of Reduce was that it actually made everything cleaner [13:52] fwereade: sometimes 6 lines of extra code are worth one less level of abstraction IMHO [13:53] fwereade: i think everything's cleaner if *all* the supercommand magic is strictly within supercommand [13:54] fwereade: in fact, the patch above isolates all the magic into SuperCommand.ParsePositional - a few lines of sequential code. [13:56] fwereade: FWIW i don't think i've seen a CL with FlagCommand in it [13:57] rogpeppe, it's in https://codereview.appspot.com/6107048/ [13:58] rogpeppe, niemeyer proposes something better but I haven't reproposed with that in [14:00] fwereade: even with ZeroArgsConsumer, i still see 5 implementations of Consume [14:02] rogpeppe, you mean including places where ZeroArgsConsumer is embedded? [14:02] fwereade: no [14:02] e.g. func (c *agentConf) Consume(args []string) ([]string, error) { [14:03] fwereade: every time someone sees that method, they have to wonder: does it actually return something other than an empty arg list? [14:03] Strawman on the way.. [14:04] fwereade: and the only reason for it is SuperCommand [14:04] * rogpeppe likes the nutty, chewy taste of straw [14:05] rogpeppe, ah, typo, I was mid-edit :/ ...sorry :) [14:05] https://codereview.appspot.com/6118044 [14:06] Tests are broken, but it actually builds at least [14:09] niemeyer: i like the look of that [14:09] niemeyer: particularly the way lines of code melt away :-) [14:09] niemeyer: not sure about calling FlagSet.Parse twice on the same flag set, but i guess it might be ok. [14:10] rogpeppe: We can always make it ok :) [14:10] rogpeppe: But I suspect it's already fine [14:10] niemeyer: yeah, or just initialise a new flagset [14:11] rogpeppe: I'd rather not, if possible.. I really like how we have a single place where this is happening [14:11] niemeyer: that's true. it removes a lot of head-scratching. [14:17] niemeyer, that's *very* nice indeed [14:18] niemeyer, almost horrifyingly so [14:24] fwereade: Cheers [14:25] niemeyer, I'm still trying to think through how it'll work with the responsibility split but I think it goes in a nice direction there too [14:26] fwereade: Yeah, I suspect it should be fine [14:26] niemeyer, ok, I'll take a short break and get onto it [14:26] niemeyer, fwereade, TheMue: are we still planning to have a meeting this afternoon? [14:26] fwereade: ctx takes care of most of the issue there already, I believe [14:26] oh, yeah, good plan [14:26] rogpeppe: +1 [14:26] I'm happy to have it *now* [14:27] i've got a 1 to 1 with robbie in 5 minutes, but i'm good after that [14:27] I have only about half an hour, but should be useful at least [14:27] rogpeppe: In half an hour I've got my 1:1 with Robbie. [14:27] rogpeppe: Aw, ok [14:27] rogpeppe: After lunch then [14:27] in 1h30? [14:27] niemeyer: i'm sure i could defer with robbbiew [14:27] rogpeppe: I'm short.. [14:27] rogpeppe: 1h30 would work best there too [14:27] niemeyer: sounds good to me [14:28] 16UTC then [14:28] niemeyer: yup. [14:28] niemeyer: OK [14:28] fwereade, TheMue: Sounds good? [14:29] niemeyer, 1h30 from now sounds good [14:30] Super [14:32] rogpeppe: we 1:1ing? or did you defer me :/ [14:32] :P [14:33] robbiew: we are [14:33] robbiew: G+? [14:34] rogpeppe: aye [14:34] https://talkgadget.google.com/hangouts/_/extras/canonical.com/the-hulk-hideout [14:34] rogpeppe: ^ [14:37] niemeyer: Please forget latest propose. Somehow the merge of parent changes brought unwanted stuff in. Seems I took the wrong revision. [14:46] TheMue: np [14:49] niemeyer: I've got to admit that I'm a bit puzzled while trying to understand which revision I should take. I opened it in Bazaar Explorer to get a better impression. But I didn't thought that the needed merge to propose the stuff would get my not-wanted code back. *sigh* [15:13] * niemeyer => lunch [15:14] niemeyer: So, now I've rolled back to an earlier revision, made the needed changes and would now like to propose it. How can this be done without the problem of a "diverged-branch"? [15:14] niemeyer: Oh, lunch, enjoy. ;) [15:21] TheMue: you need to have merged with trunk [15:22] TheMue: if bzr diff looks right, then the codereview should look right, assuming you've got the prereq correct [15:23] TheMue: also, i didn't know this for a while: you can't change the prereq of an existing merge proposal - you have to delete and repropose if you want to do that [15:23] rogpeppe: aha, have to take a look [15:25] rogpeppe: How do I do it? [15:26] TheMue: there's a "Delete this proposal" link in the top right of the merge proposal page [15:28] rogpeppe: You mean "Delete patch set"? [15:28] rogpeppe: Otherwise I'm on a different page. *lol* [15:29] TheMue: this page: https://code.launchpad.net/~themue/juju/go-state-unit-resolved-watcher/+merge/102497 [15:29] TheMue: "Delete proposal to merge" [15:30] rogpeppe: Ah, thx, I've been on the review page. [15:31] TheMue: the launchpad pages are the important thing. [15:31] TheMue: you don't want to delete the codereview page. [15:32] rogpeppe: I just hoped both play together. [15:33] TheMue: codereview.com knows nothing about launchpad.net or vice versa. the only link is lbox. [15:34] rogpeppe: So we need a "lbox sync" supercommand. ;) [15:35] TheMue: there's no change you can make in codereview that we'd want to sync to launchpad, other than comments, which get transferred anyway. [15:35] TheMue: so lbox is already like lbox sync, just in one direction [15:36] rogpeppe: OK, to make it more clear. So we need a … . [15:36] TheMue: oh [15:36] TheMue: ha ha :-) [15:36] rogpeppe: I've got to admit it has been a bad one. ;) [15:37] rogpeppe: Just hoped to get a link into the supercommand discusion today. [15:37] TheMue: what kind of link? [15:38] rogpeppe: Hmm, maybe wrong wording. How would say it if you want to connect a sentence now to a discussion that has been helt some time ago? [15:38] rogpeppe: A connection? [15:39] TheMue: you'd probably say something like "just hoped to make a reference to the supercommand discussion today" [15:39] "reference" is the word [15:40] rogpeppe: Ah, ok, thx, learned again. Sounds a bit formal from a German perspective. [15:41] TheMue: Here we also have the word "Referenz", but it is used in a different context. [15:54] TheMue: alternative phrasing "i was referring to the supercommand discussion" or "i was trying to refer to ..." [15:57] rogpeppe: Sounds like the same stem. How would you say it if you're in the context of making a joke? Would you also "refer to"? [15:58] * TheMue likes English lessons here in the channel, as long as I don't have to pay for. [15:59] TheMue: probably not in a joke itself. i'd just use some phrasing that alludes to the original thing. [16:00] rogpeppe: I tried it with the "lbox sync" supercommand, but yes, that hasn't been funny. [16:00] TheMue: i can't say i laughed out loud :-) [16:01] rogpeppe: I'll try to make a better one next time. [16:01] TheMue: i wait with eager anticipation [16:02] rogpeppe: I hope I won't dissappoint you. [16:03] * niemeyer is back [16:04] niemeyer, fwereade, TheMue: meeting? [16:04] rogpeppe: I still have the "diverged-branches" problem. [16:04] TheMue: push --overwrite [16:04] yep! [16:04] rogpeppe: Wanna do the honors? [16:06] niemeyer: k [16:07] niemeyer, TheMue, fwereade: invites out [16:11] * hazmat lunches [16:18] Lost my connection.. trying again [16:19] rogpeppe: WTF.. is everybody else in? [16:19] niemeyer: yeah [16:19] niemeyer: we're still there [16:19] rogpeppe: I'm retrying but it shows me as being online in my own list.. [16:20] niemeyer: you're there, but in cartoon form only [16:20] rogpeppe: I can hear you typing [16:20] niemeyer: lol [16:20] Come on G+! [16:20] I can hear everybody [16:20] I'm disconnecting and retrying [16:21] can you use the text chat box? [16:21] rogpeppe: I could.. just disconnected.. will retry [16:21] Killing Chrome and restarting [16:25] Shait [16:25] niemeyer: dammit [16:26] This software wasn't so crackful before [16:27] niemeyer: it's working fine for us :-) [16:27] rogpeppe: That's the kind of trick that always works.. if you restrict what "us" means enough, it everything is wonderful! ;-) [16:28] niemeyer: us == ∅ :-) [16:30] niemeyer: maybe if you invited us, the server might be located in a better place... [16:30]