[02:20] davecheney: does go test buffer output? [02:47] * thumper loses davecheney [02:47] hmm... [02:47] * thumper waits [05:58] wallyworld_: if you prefer today, https://plus.google.com/hangouts/_/750982817f7631223162e5af2eceb6726c27bfe3 === tasdomas_afk is now known as tasdomas [07:03] thumper: /wave [07:42] mornin' all [07:44] morning! [08:29] jam: oh hai [08:29] jam: just read your email respons [08:29] hi thumper [08:29] jam: I'll pop back in in 30min to see if fwereade is around [08:29] I'm pretty sure william is gone today [08:30] ah, that's right [08:30] leave [08:30] geez [08:30] so we can check in 30min, but probably just going for tomorrow might work better [08:30] thumper: fwereade is gone all week btw [08:30] dimitern: thanks for the clarification. [08:30] he still wanted to meet with us during that time, but it is hard to meet up today. [08:31] thumper: I can do the same time tomorrow [08:31] thumper: does it work for you? [08:31] jam: not sure about that - he'll probably pop in at some point in irc at least (provided he has decent connection in backwater gozo :) [08:32] jam: can you do now? [08:33] hi dimitern [08:33] thumper: I could do now for a bit. I techincally have a call with dimitern in 30min, but I think he would accept moving it around a bit. [08:33] obviously mark won't be there. [08:33] thumper: do you have 5m about a couple of bzr pipes question? [08:33] jam: we could be done in 30 minutes [08:33] jam: I don't think there is that much to discuss :) [08:33] thumper: hiya [08:33] dimitern: leave the question and I'll answer as fast as I can [08:34] jam: sure, np moving it later [08:34] jam: I'm fine with mark not being there [08:34] jam: lets hang out [08:35] oh for the love of god why did hangouts get so hard to start? [08:36] thumper: https://plus.google.com/hangouts/_/16239e7d8ea236f8aa18ed4ada6c87f9e6dc3dfc === ehg_ is now known as ehg [08:40] thumper: ah, actually thanks to the very good docs you wrote I managed :) cheers [08:41] jam: ping me when you're done [09:11] dimitern: poke [09:12] would you prefer hangout to mumble? [09:12] jam: don't mind a hangout [09:13] dimitern: https://plus.google.com/hangouts/_/e7c22066f25817d34f2bb47a6c1eabc32def3fc6d [09:13] jam: i'm there [09:15] dimitern: I don't see you yet, I'm also in mumble if it is easier for you to get there. [09:15] jam: hmm - ok. let's mumbe then [09:15] mum-be! [09:16] night all [09:16] let's get ready to mummmbleeee!!! [10:17] mgz: ping [10:17] pong [10:19] mgz: sorry, stupid question maybe, but i'm trying to unlearn cobzr workflow and switch to normal bzr one - i'm using a LW checkout of juju-core, my current branch is trunk, how to create a feature branch out of it? tried bzr branch . new-branch, but it seems to do more than it should [10:21] `bzr switch -b new-feature` [10:21] mgz: and running go build ./... && go test ./... afterwards gives me lots of errors: http://paste.ubuntu.com/5683245/ [10:22] your commands tells bzr to create a new copy of the current branch under the same tree structure, which no doubt confuses go [10:22] (fix by `rm -rf new-branch`) [10:24] mgz: ah, ok, so how can I fix what I messed up? I did the rm -fr new-branch, but how to switch back to trunk? (040-move-set-agent-alive-out-of-machiner) dimitern@kubrik:~/work/juju-core$ bzr switch trunk [10:24] bzr: ERROR: Not a branch: "/home/dimitern/work/go/src/launchpad.net/juju-core/trunk/". [10:24] what does `bzr branches` say? [10:25] mgz: bzr: ERROR: Not a branch: "/home/dimitern/work/go/src/launchpad.net/juju-core/040-move-set-agent-alive-out-of-machiner/". [10:25] exciting. [10:26] mgz: oh well, maybe I should scrach everything and start over - nothing done yet, so nothing to lose [10:26] edit .bzr/branch/branch.conf [10:26] or yeah, just start over [10:26] mgz: thanks [10:26] so, are you aiming for native colo, or a shared repo? [10:27] the general idea is the same, but what you need in the go world is slightly different [10:28] mgz: i want to have ~/src/juju-core shared repo with no trees, have $GOPATH/../j-c bound to that lwco and have a symlink in ~/work/juju-core to safe typing [10:29] okay, like jam does. pretty sure he still uses switch, but also has some locations magic [10:30] mgz: i'm a bit confused that i have to specify paths for switch and merge - with cobzr i needed just the branch names [10:32] mgz: so generally, when i'm in trunk to create a new branch I just need bzr branch -b new-branch and it'll switch to it as well? [10:34] no, `bzr switch -b`, which creates the branch [10:35] mgz: ah, right. and then while i'm in new-branch to merge trunk in: bzr merge trunk ? [10:35] you need a path for merge, but often you just want `bzr merge :parent` [10:36] mgz: cool! i'll add alias for this [10:39] mgz: strange though while in new-branch "bzr branches" shows * . only and "bzr show-pipeline" shows what I expected: * new-branch [10:39] yeah, branches go borked about the shared repo case again I think [10:40] *got [10:40] mgz: but i did a fresh clone of trunk [10:42] mgz: and now, while in new-branch i did bzr switch trunk, then bzr remove-branch new-branch and it said: bzr: ERROR: Branch is active. Use --force to remove it. [10:42] what does `bzr info` say now? [10:43] mgz: http://paste.ubuntu.com/5683309/ [10:44] that still seems sane [10:45] mgz: light chechout root: . seems fishy - should it be like that? [10:45] ah, wait [10:46] no, should be okay [10:47] it may be just a confused remove-branch somehow [10:47] mgz: how to manually remove it? [10:48] it's not very useful for the branch-in-dir layout anyway, as you want to rm the directory after, and that's what you need to remove the branch too [10:48] dimitern: just `rm -rf ~/src/juju-core/new-feature` [10:49] you can try `bzr rmbranch ~/src/juju-core/new-feature` first [10:49] and use --force if that complains [10:49] mgz: too late :) [10:49] new experiment time :) [10:50] just `bzr switch -b new-feature && bzr switch trunk` then go [10:50] mgz: i'll try again [10:50] (or `bzr branch . ~/src/juju-core/new-feature`) [10:52] mgz: in addition to --no-trees what else should i specify to init-repo so there are no files in there? with cobzr there were just empty dirs for branches and the root dir was empty as well (safe for .bzr) [10:52] just that [10:53] mgz: oh, I see the problem - instead of doing init-repo i just did mkdir juju-core && bzr branch lp:juju-core trunk before [10:57] mgz: now it works and bzr branches reports * new-branch \n trunk as expected [10:58] mgz: i added bash completions for bzr commands (very handy!) and a small script to show me the current branch name in the prompt. it will be really useful if somehow i can complete branch names as well in bzr commands - any idea what can i use? [10:59] not off hand [11:02] oh well, it's not that bad with a few aliases and such [11:02] * dimitern bbiab [11:22] back [11:48] rogpeppe1: ping [11:48] dimitern: pong [11:48] rogpeppe1: if i move setagentalive in MA.Entity(), when should I stop the pinger then? [11:48] dimitern: i don't think that's the right place for it [11:49] rogpeppe1: where then? runloop? [11:49] dimitern: possibly. let me look again, one mo [11:51] dimitern: hmm, how many pingers do we want going at once? [11:51] rogpeppe1: how many? just one i think [11:51] rogpeppe1: for the machine entity the MA is responsible for [11:51] dimitern: in which case i think that the current way is perhaps the only decent solution [11:52] dimitern: unless we make another worker specifically to maintain the pinger [11:52] rogpeppe1: i thought we agreed to move it [11:52] dimitern: yes, but i'm not sure it's right [11:52] dimitern: in the machine agent there are two concurrent runLoops [11:53] rogpeppe1: which are? [11:53] dimitern: the API server and the rest of the workers [11:53] dimitern: and we will have three [11:53] dimitern: as we move towards using the API for the workers [11:53] rogpeppe1: william mentioned you agreed to merge some of these loops [11:54] rogpeppe1: not sure what was it [11:54] dimitern: i'm not sure that's what we arrived at [11:54] rogpeppe1: well this is kinda blocking me [11:55] dimitern: in my understanding we decided to have a separate loop for workers which connect to mongo and workers which connect to the API [11:55] rogpeppe1: i can switch to the other task - machine api instead [11:56] rogpeppe1: and leave the AA stuff until next week to have an agreement [11:56] dimitern: i think that's not a bad idea, particularly as fwereade doesn't appear to be around currently. [11:56] dimitern: sorry not to be more help [11:57] rogpeppe1: it's ok, i just need to start from somewhere. can do the AA stuff later, it's orthogonal [12:02] rogpeppe1: do you have 20m for a quick hangout about the machine api? [12:02] dimitern: sure [12:02] rogpeppe1: i'll start one as soon as we finish the standup [12:02] dimitern: ok [12:10] rogpeppe1: they changed *everything* on g+ - how do i start a hangout now?? [12:11] dimitern: i'll try! [12:11] dimitern: do you think "hangouts" are the same as "hangouts on air" ? [12:12] rogpeppe1: no - those are live streaming ones [12:12] rogpeppe1: public [12:14] dimitern: https://plus.google.com/hangouts/_/efbe73ddf30405282d381b4767ff0762c0dee700?authuser=0&hl=en-GB [12:21] hi guys, I'm getting "ERROR: Not a branch" for goose when I run go get -v -u launchpad.net/juju-core/... : http://pastebin.ubuntu.com/5683526/ [12:21] I didn't see anything in the juju-dev@ mailing list about this, or about some branch changing [13:35] ahasenack: you probably didn't update goose for a while [13:36] dimitern: I run go get -v -u everyday [13:36] ahasenack: trunk moved to another location owned by the go-bot [13:36] dimitern: if I trash everything under $GOPATH/src and run go get -v launchpad.net/juju-core/... will it be using the right branch? [13:36] ahasenack: you'll need to pull it from lp:goose and use --remember and --overwrite [13:36] ahasenack: that should work if you can do it\ [13:37] sure, it's fast [13:37] dimitern: thanks [13:37] ahasenack: but use go get -v -u === wedgwood_away is now known as wedgwood [14:01] mramm2, rogpeppe1: kanban? === tasdomas is now known as tasdomas_afk === hatch_ is now known as hatch [14:42] rogpeppe1: you did godef right? [14:42] dimitern: yeah [14:43] rogpeppe1: awesome! it turns out go mode for emacs supports it as an alternative to searching for tags [14:43] rogpeppe1: and it works way better than tags as well [14:43] dimitern: ah, cool. i knew someone integrated it at some point [14:43] dimitern: i wasn't sure if it was available anywhere [14:44] dimitern: it doesn't *always* work, but it's not bad [14:44] rogpeppe1: in go 1.1 it's used [14:44] dimitern: the go parser it uses is an ancient fork of the go parser package [14:45] dimitern: i really want to update it to use go/types some time, but y'know, "in my copious spare time" :-) [14:45] rogpeppe1: if it doesn't work for some code i'll tell yu :) [14:45] dimitern: someone should make it work for vim too [14:45] rogpeppe1: yeah [14:45] dimitern: it doesn't know about import . [14:46] dimitern: as in the way we import gocheck [14:46] rogpeppe1: yeah [14:46] dimitern: that's the main limitation i know about currently [14:47] dimitern: i find the functionality indispensible when browsing through other people's code (and our own, actually, come to that) [14:47] dimitern: you can get it to tell you type information too [14:47] dimitern: although i rarely use that functionality [14:48] rogpeppe1: i'm content with having a "jump" shortcut that works for most cases, rather than having to grep [14:48] dimitern: yeah. that's the main thing. [14:48] dimitern: it should work with any identifier [14:49] dimitern: including field names, type names, method names etc [14:49] rogpeppe1: yeah, just tested it within the apiserver - sweet! ws.ws.x.y.z.Stop() - no problem :) [14:50] dimitern: yup, even when ws itself comes from a for loop or something [14:51] rogpeppe1: really nice [14:56] dimitern: at one point i instrumented the godoc web interface so that every identifier was shown as a link. that was quite cool. [14:57] rogpeppe1: they actually have that now in go 1.1 [14:57] rogpeppe1: not sure how [14:58] dimitern: not really - only in the doc pages, not in the source code itself. [14:58] rogpeppe1: ah, i see - well it's a start at least [14:59] dimitern: yeah, it's a great improvement [15:16] rogpeppe1: why isn't there a srvService? ServiceExpose/Unexpose are global [15:17] dimitern: ServiceExpose and ServiceUnexpose are client methods [15:17] dimitern: we need srvService too [15:17] dimitern: (and that will not have an Expose method) [15:17] rogpeppe1: hmm.. i have no way to see how some methods on srvMachine should look like [15:18] dimitern: i suggest you add methods on srvMachine only as they are needed [15:18] rogpeppe1: let me paste you a few i have so far and tell me if i'm on the right track [15:19] dimitern: these are all the calls i think we need: http://paste.ubuntu.com/5684020/ [15:20] rogpeppe1: a bit more we need in srvMachine [15:20] dimitern: oh yes? [15:20] rogpeppe1: http://paste.ubuntu.com/5684027/ [15:20] dimitern: i did the survey that led to that list ages ago, so things have probably changed since then [15:21] dimitern: that looks right. we've only done proper lifecycles and status setting relatively recently [15:22] rogpeppe1: so it looks sane? [15:22] dimitern: yes apart from SetStatus [15:22] dimitern: API calls can have at most one argument [15:22] rogpeppe1: why? [15:22] dimitern: and that argument must be a struct [15:23] dimitern: because we need the parameters to be named [15:23] dimitern: and function params have no associated names [15:23] rogpeppe1: ah, ok - so params.MachineSetStatus ? [15:23] dimitern: read go doc launchpad.net/juju-core/rpc [15:23] dimitern: no, SetStatus is fine [15:23] dimitern: oops [15:23] dimitern: yes [15:23] dimitern: that sounds about right [15:24] rogpeppe1: yeah, there's unit setstatus as well [15:24] rogpeppe1: but it's the same [15:24] dimitern: perhaps just params.SetStatus then [15:24] rogpeppe1: ok [15:24] rogpeppe1: and i need to do state.Life -> params.Life conversion as well [15:25] dimitern: yes. i think you can just use state.Life.String actually. [15:26] rogpeppe1: ah, cool, even better [15:32] rogpeppe1: i just realized i have to implement a whole Pinger similarly to EntityWatcher in apiclient as well [15:33] dimitern: not nearly that complex. [15:33] dimitern: it's much more similar to AllWatcher [15:33] dimitern: but simpler than that [15:33] dimitern: it'll only have one method, Stop. [15:33] rogpeppe1: not only that - Alive() as well [15:34] dimitern: ah yes, that too [15:34] dimitern: but no complex logic - just a call-through to the api [15:37] rogpeppe1: yeah seems so [15:41] rogpeppe1: the problem is pingers are in state/presence, and I don't see how to use that when I'm supposed to have st *State only [15:42] dimitern: you'll need to define an api.Pinger type [15:42] dimitern: oh sorry, wrong problem. [15:42] rogpeppe1: by api you mean put it in apiclient.go [15:42] dimitern: i'm not sure i see your problem [15:42] rogpeppe1: yes, i'm there [15:43] dimitern: what's the difficulty with using a pinger in the API server? [15:43] rogpeppe1: well the api.EntityWatcher uses stuff like err := w.st.call(w.etype, w.eid, "Watch", nil, &id); [15:43] rogpeppe1: but i need to call stuff not in state/ but state/presence/ [15:44] dimitern: from the API client? or the server? [15:44] rogpeppe1: from the client [15:44] dimitern: why so? [15:44] rogpeppe1: ok, think for a moment - SetAgentAlive -> *pinger, error [15:45] dimitern: you will need a new srvPinger type, if you hadn't realised that already [15:45] rogpeppe1: in the api it's params.PingerId instead [15:45] rogpeppe1: ah [15:45] dimitern: so do just what the watcher stuff does [15:45] rogpeppe1: yeah [15:45] rogpeppe1: ok, sorry :) [15:45] dimitern: np === mramm2 is now known as mramm [19:16] Hey -- juju-core has a rather nasty behavior for relation-list if you are calling it on something like a peer relation with only one unit. Should it be a bug? It breaks charm suppor and probably many other charms: See here for an example: https://pastebin.canonical.com/91346/ [21:36] FYI -- I have filed: https://bugs.launchpad.net/juju-core/+bug/1182224 [21:36] <_mup_> Bug #1182224: relation-list returns null with json-output [23:23] * kyhwana pokes Makyo idly [23:23] Oh, hey Kyh. [23:24] Makyo: oh his :) [23:24] Is it idly time around here? Was planning on trying to write a smokeping charm, since there doesn't seem to be one. [23:26] kyhwana, Yeah, it's past EOD for a lot of folks. #juju might be more active? [23:26] ahh ok [23:27] kyhwana, mmmmaaybe marcoceppi or m_3 would know a bit more, too, if you need :) [23:27] well, will ask around later. That'll be today's After Work project :) I keep breaking my smokeping install at home :| [23:28] Ah, yeah :S [23:29] I keep wanting to do some random charm, but every time I think I have a good idea, I find it's already been done :P [23:34] hah, I checked the charm list and there's no smokeping one. (otherwise I would've deployed it myself) [23:35] Yeah, well, hey, there's your chance \o/ === wedgwood is now known as wedgwood_away