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