[01:18] <thumper> davecheney: I'd love a sanity check on the series email just sent to the list
[01:18] <thumper> davecheney: it is that classic thing of getting home, and going "ah... wat?"
[01:19] <davecheney> thumper: that is too be expected
[01:19]  * davecheney reads
[01:19] <thumper> davecheney: I've summarised what I think I should do at the bottom of the email, but really want to check before diving in
[02:10] <hazmat> m_3, davecheney can i get a dial in on that voice.. or has the clock passed
[02:10] <davecheney> hazmat: m_3 is down with hardware issues
[02:10] <davecheney> but lets schedule it for tomorrow
[02:11] <hazmat> davecheney,sadly no clock unites you, i, m3 and mgz
[02:11] <hazmat> mail it must be
[02:11] <davecheney> le sigh
[02:40] <thumper> davecheney: so... I'm trying to understand the "go test" process
[02:40] <davecheney> right
[02:40] <thumper> davecheney: so with gocheck, how does it add stuff to the standard testing calls?
[02:41] <davecheney> there will be a file that bridges between the go test expected function
[02:41] <davecheney> and the gocheck one
[02:41]  * davecheney finds an example
[02:42] <davecheney> you can figure out which one it is
[02:42] <davecheney> it is the name printed when you run go test -v
[02:42] <thumper> davecheney: var _ = Suite(&MainSuite{}) does the magic register
[02:42] <davecheney> that is part of the story
[02:42] <davecheney> that registers the Suite with gocheck
[02:43] <thumper> right
[02:43] <davecheney> but there is a bridge to jump from go test to gocheck
[02:43] <davecheney> both are necessary
[02:43] <thumper> yeah, I'm missing that bridge bit
[02:43] <davecheney> from cmd/cmd_test.go
[02:43] <davecheney> func Test(t *stdtesting.T) { TestingT(t) }
[02:43] <davecheney> the TestingT is actaully gocheck.TestingT
[02:44] <davecheney> but we import gocheck into the packages' own namespace
[02:44] <thumper> ah...
[02:45] <thumper> davecheney: so how often do you need to do that?
[02:45] <davecheney> once per pacakge
[02:46]  * thumper nods
[02:57] <m_3> davecheney: ok, back
[02:57] <m_3> davecheney: damn... that totally sucked
[02:58] <m_3> davecheney: so yeah, I'd love to bump til tomorrow if that's cool with you
[02:58] <davecheney> m_3: no worries
[02:58] <davecheney> will be online at 8am
[02:59] <davecheney> should be 2/3pm our time, give or take
[03:18] <thumper> davecheney: what level of hooks are there in go during package load?
[03:18] <thumper> davecheney: is there a way to get something run as the package is loaded?
[03:19] <davecheney> thumper: the is the init() hook, which is executed pre main
[03:19] <davecheney> there is no concept of package loading
[03:20] <thumper> when is the init() hook run? and for which package?
[03:20] <davecheney> it is run pre main()
[03:20] <davecheney> for all packages, in dep order
[03:20] <thumper> ah...
[03:20] <thumper> interesting
[03:20] <davecheney> so if A depends on B then B's init() gets run before A's
[03:20] <davecheney> ___but____
[03:20] <davecheney> inside a package you can have multiple init() functions
[03:21] <davecheney> but there is no ordering on those
[03:21] <thumper> but all init() methods are called?
[03:21] <davecheney> yes
[03:21] <thumper> isn't there name clashes?
[03:21] <davecheney> init is a magic method
[03:21] <thumper> so if I have three different files, a.go, b.go and c.go and all are in package d
[03:21] <davecheney> when it is compiled each gets a sequyence number appended to avoid colisions
[03:21] <thumper> and each file has an init() func
[03:22] <thumper> they are all called?
[03:22] <davecheney> they are all called
[03:22] <thumper> ok
[03:22] <davecheney> the order in which they are called is not known
[03:22] <thumper> when are global vars created in relation to the init methods?
[03:22] <davecheney> http://play.golang.org/p/kYYu_ZSixq
[03:22] <davecheney> thumper: before
[03:22] <davecheney> var's are handled in init methods
[03:22] <davecheney> that you don't create
[03:23] <thumper> are they guaranteed to run before the init methods I define?
[03:23] <thumper> they sound special
[03:23] <davecheney> yes
[03:23] <davecheney> top level initalisation is special
[03:23]  * thumper nods
[03:23]  * thumper is thinking magic
[03:23] <davecheney> http://play.golang.org/p/NjZU1tGibR
[03:26] <thumper> so... vars in package d are initialized before a defined init() method in a dependent package?
[03:26] <thumper> global vars that is
[03:26] <davecheney> package level vars yes
[03:26] <davecheney> there are no global vars
[03:26] <davecheney> for each packge it goes
[03:27] <thumper> ok, that is what I meant
[03:27] <davecheney> vars, init()s, then the packages that depend on that package
[03:27] <davecheney> all the way back up to main
[03:27] <thumper> oh... :(
[03:27]  * thumper thinks
[03:27] <thumper> actually, I think that still works
[03:27] <davecheney> the langauge _should_ prevent you from seeing an uninitalised variable
[03:28]  * thumper thinks more
[03:29] <davecheney> thumper: care to share ?
[04:08]  * thumper has just worked out why "go test ./..." often has weird delayed output
[04:08] <thumper> buffered i/o
=== jtv2 is now known as jtv
[08:14] <fwereade> mornings
[09:35] <TheMue> Good morning
=== TheRealMue is now known as TheMue
[11:20] <hazmat> has anyone been able to get a vpc default/only account?
[11:33] <mgz> jam, dimitern: standup?
[11:33] <dimitern> mgz: in a sec
[11:41] <rogpeppe1> hi all
=== rogpeppe1 is now known as rogpeppe
[11:44] <dimitern> rogpeppe: hiya
[11:56] <TheMue> Hi all
[12:00] <jam> mgz:  did you go through the standup already?
[12:00] <mgz> jam: yup, we was fast
[12:00] <jam> k, I did have some things to specifically bring up, but I can bring them up on IRC
=== wedgwood_away is now known as wedgwood
[13:41]  * TheMue needs inspiration regarding JUJU_HOME and testing. Anyone interested?
[13:45] <benji> TheMue: sounds like fun... what is JUJU_HOME?
[13:46] <TheMue> benji: It's a new env variable controlling the home of the juju file, today hard coded .juju.
[13:46] <benji> makes sense
[13:47] <TheMue> benji: When changing the variable, or a global variable representing it, for a test and multiple tests run concurrently they may get into conflict.
[13:47] <TheMue> benji: As it is a global state.
[13:48] <benji> yep; global state is a killer in tests (and everywhere else, really)
[13:48] <TheMue> benji: Exactly. We already have some tests where $HOME is changed.
[13:50] <benji> I don't know how the internals of go's testing infrastructure works, but my first though would be to channel all reads of JUJU_HOME into a function and then make tests use that instead of accessing the real variable
[13:50] <TheMue> benji: The problem stays.
[13:52] <TheMue> benji: Test A needs its home and sets it, test B too, now in test A it is read and it gets the - internal or external - value B had set.
[13:52] <benji> indeed
[13:52] <benji> each test would then need to create a temporary directory and set its local idea of home to that
[13:52] <TheMue> benji: It's btw a func returning JUJU_HOME or as default ~/.juju
[13:53] <TheMue> benji: Yes, and if the tested function calls JujuHome(), what will it get then?
[13:53] <benji> how about making the default function return an error in tests, that way you don't have accedental reading of the shared state and then have each tests make a process- (or thread-) local version
[13:54] <fwereade> TheMue, surely the problem only appears when run with explicit test.parallel > 1?
[13:54] <TheMue> fwereade: Yep, only then. Otherwise it's simple. ;)
[13:54] <fwereade> TheMue, panic in test setup if that's set then?
[13:55] <benji> as I understand it, test.parallel defaults to the value of GOMAXPROCS, which may be greater than 1
[13:55] <benji> (another instance of global state being a bad actor)
[13:55] <fwereade> benji, but *that* is only >1 when explicitly set, right?
[13:56] <TheMue> fwereade: We very often rely on the home internally, so all tests that even nested may access it would have to panic.
[13:56] <gary_poster> fwereade, rogpeppe hi.  Would you be available for hopefully a quick G+ in about 4 minutes (top of hour) to resolve lingering confusion about how to proceed with the annotations changes from frankban and Makyo?  We could meet in http://tinyurl.com/guichat
[13:56] <benji> fwereade: I assume so.
[13:57] <fwereade> gary_poster, sorry, we have a meeting coming right up -- how about 30 minutes later?
[13:57] <gary_poster> fwereade, we have a meeting then. :-) 60 minutes later instead, at the top of the next hour?
[13:57] <fwereade> gary_poster, sgtm if it sgt rogpeppe
[13:58] <gary_poster> thanks fwereade
[14:00] <benji> TheMue: does go have a thread-locals?  That is where I would stash slightly-less-than-global-globals.
[14:07] <TheMue> benji: One moment, meeting.
[14:46] <mgz> hm, so I don't really need to be in ~gophers, and can land things on juju-core and goose regardless,
[14:46] <mgz> but now can't triage goose bugs for instance, as ~gophers still owns the project
[14:47] <gary_poster> ~gophers was deactivated entirely, apparently
[14:47] <dimitern> i'm still not unclear why all that was even needed? changing gophers and all
[14:47] <gary_poster> rogpeppe, are you up for a call in 13 minutes?
[14:47] <gary_poster> 12 :-)
[14:47] <rogpeppe> gary_poster: yup
[14:48] <gary_poster> cool, thanks
[14:58] <gary_poster> fwereade, rogpeppe, frankban, Makyo call in http://tinyurl.com/guichat in 2 minutes.  I'm there already :-)
[14:58] <gary_poster> I will have to bow out early; I'm taking the role of facilitator
[14:59] <mramm> gary_poster: mind if I poke my head in?
[15:00] <gary_poster> mramm, no, please do
[15:02] <gary_poster> fwreade, rogpeppe, the conversation is so scintillating in our chat room that I'm sure you want to join in...
[15:27] <rogpeppe> fwereade: how about something like this? http://paste.ubuntu.com/5610973/
[15:27] <rogpeppe> fwereade: except... what to call "EntityName"?
[15:34] <fwereade> rogpeppe, I'm not quite sure about that Entity in there
[15:34] <fwereade> rogpeppe, I would honestly like to keep them separate
[15:34] <fwereade> rogpeppe, Refresh is only relevant to AuthEntity anyway, right?
[15:35] <rogpeppe> fwereade: ok, so you can ask for an annotator by name, but you can't ask the name of the annotator when you've got it?
[15:35] <Makyo> fwereade, Service has Refresh as well, correct?
[15:35] <rogpeppe> fwereade: isn't Refresh relevant to all state entities with a doc?
[15:38] <fwereade> rogpeppe, I am saying that having independent *Name methods that happen to return the same string is a price I consider worth paying to separate these bits of functionality
[15:38] <fwereade> rogpeppe, Refresh is not elevant to any Annotator AFAICT
[15:38] <rogpeppe> fwereade: Machine is an Annotator
[15:39] <rogpeppe> fwereade: and has Refresh
[15:39] <fwereade> rogpeppe, the fact that most annotators can be refreshed is not the point
[15:39] <fwereade> rogpeppe, and files can be closed as well as written
[15:40] <rogpeppe> fwereade: so you'd return a simple Annotator from AnnotatorEntity?
[15:40] <fwereade> rogpeppe, I think so -- maybe I'd even just call it Annotator(string) (Annotator, error)
[15:41] <rogpeppe> fwereade: and document that the syntax of the name is... what?
[15:41] <fwereade> rogpeppe, specific to annotations
[15:41] <fwereade> rogpeppe, by happy coincidence it is the same as that used for corresponding objects that can log in
[15:42] <rogpeppe> fwereade: duplicate the documentation?
[15:42] <fwereade> rogpeppe, roughly speaking, but the sets of relevant entities are different so it won't be *exactly* the same
[15:44] <rogpeppe> fwereade: this better? http://paste.ubuntu.com/5611029/
[15:44] <fwereade> rogpeppe, sorrt
[15:44] <fwereade> rogpeppe, yeah, I think so
[15:46] <rogpeppe> fwereade: promise? :-)
[15:47] <fwereade> rogpeppe, I'm pretty sure that fits what I've been after since the beginning
[15:47] <fwereade> rogpeppe, if I'm being inconsistent then I should absolutely be called on it, but I have been trying not to be
[15:52] <rogpeppe> fwereade: so, the plan is to leave EntityName around as it currently is, rather than changing it everywhere, but would you prefer we retro-fixed it to... something else?
[15:53] <rogpeppe> fwereade: i.e. have you got a better name for it?
[16:03] <fwereade> rogpeppe, hmm, I didn't see an EntityName in the things you suggested
[16:03] <rogpeppe> fwereade: yup, it's not needed by the things that use those interfaces, as far as i could make out
[16:03] <fwereade> rogpeppe, I had kinda assumed that was orthogonal, and that my views on that specific name had been made clear
[16:04] <rogpeppe> fwereade: yeah, i think it's orthogonal, and can be treated as a separate issue to be fixed independently
[16:06] <fwereade> rogpeppe, ok, fair enough, I'm very happy to see the separate interfaces and can live with a name I don't like
[16:06] <rogpeppe> fwereade: if you think of a sensible name, the change should be quite simple when we decide to do it.
[16:07] <rogpeppe> fwereade: one thought we had: "ExternalName" (i'm not that keen but just throwing it out there)
[16:08] <fwereade> rogpeppe, I still think the interfaces would be *better* if they included *Name methods but as I said I can live with EntityName
[16:12] <fwereade> gents, I need to come back later to talk with thumper, so I'm knocking off early in the interest of having a bit of an evening before then
[16:15] <rogpeppe> fwereade: okeydokey
[16:48] <TheRealMue> fwereade: ping
[16:49] <TheRealMue> fwereade: Have to step out but will ping you again later. ;)
[17:03] <rogpeppe> mgz: have you used bzr pipelines?
[17:03] <mgz> rogpeppe: I have, but abentley is the real expert
[17:04] <rogpeppe> mgz: ah. i'm hoping they'll "just work" with cobzr, but i wanted to check before potentially destroying my repo
[17:05] <mgz> they'll just work, cobzr is just creaky porcelain around some core bzr features
[17:05] <rogpeppe> mgz: that's what i'm thinking
[17:06] <rogpeppe> mgz: if i've got a few branches that already form a logical pipeline, can i link them together, or will i have to create new branches and merge my existing ones into them?
[17:07] <mgz> I've never tried to do that
[17:07] <rogpeppe> mgz: (i find myself in a position where the functionality that pipes provide looks like it'll be really useful)
[17:07] <mgz> you probably need to create the pipes, but should be able to just pull in the existing branches
[17:07] <rogpeppe> mgz: ok, i'll just start from scratch and merge. shouldn't be a problem.
[17:08] <rogpeppe> mgz: yeah
[17:09] <mgz> well, you shouldn't need to merge is the point, just pull in the revs
[17:15] <abentley> rogpeppe, mgz: in fact, you can just use the existing branches.  bzr add-pipe will accept a location (i.e. the path to a branch) as its input.
[17:16] <rogpeppe> abentley: thanks!
[17:36] <rogpeppe> abentley: that didn't actually work for me - i got this error: 'bzr: ERROR: A control directory already exists: "file:///home/rog/src/go/src/launchpad.net/juju-core/.bzr/cobzr/242-allwatcher-handle/".'
[17:37] <rogpeppe> abentley: but i just created the branch and merged in. no problem.
[17:39] <abentley> rogpeppe: What was the command you typed?
[17:39] <rogpeppe> abentley: bzr add-pipe name-of-existing-branch
[17:41] <abentley> rogpeppe: locations work, names don't.  "bzr add-pipe ~/src/go/src/launchpad.net/juju-core/.bzr/cobzr/242-allwatcher-handle" should have worked.
[17:41] <abentley> rogpeppe: Or whatever equivalent path.
[17:41] <rogpeppe> abentley: ah, ok. i didn't realise there was a difference.
[17:41] <rogpeppe> abentley: it's no matter any more anyway
[17:43] <abentley> rogpeppe: cool.
[17:44] <rogpeppe> abentley: first pipeline operations completed successfully - one pump, one interactive back merge. very useful!
[17:44] <abentley> rogpeppe: great.
[17:54] <rogpeppe> gary_poster, dimitern, fwereade, anyone else: here are the next two branches in the allwatcher task: https://codereview.appspot.com/7727044/ https://codereview.appspot.com/7727045/
[17:55] <gary_poster> yay rogpeppe thanks!  how many left after that?
[17:55] <rogpeppe> gary_poster: probably three or four
[17:56] <gary_poster> rogpeppe, ok cool, thanks.  I'll look forward to reviewing soon.
[17:56] <rogpeppe> gary_poster: thanks a lot
[17:57] <rogpeppe> gary_poster: bzr pipes are going to make my a *lot* easier here, i'm hoping...
[17:57] <gary_poster> lol, I bet
[18:49] <rogpeppe> right, that's me for the day
[18:50] <rogpeppe> see y'all tomorrow
=== _thumper_ is now known as thumper
[20:10] <thumper> fwereade: morning
[20:10] <thumper> fwereade: around?
[20:10] <fwereade> thumper, heyhey
[20:10] <fwereade> thumper, little bit caught up, 5 mins maybe?
[20:11] <thumper> fwereade: I'm just reading your email response
[20:11] <thumper> sure
[20:11] <fwereade> thumper, cool
[20:19] <benji> this is the second time I have gotten this error from "lbox propose":  error: ERROR: Failed to update bug task: Server returned 400 and body: milestone_link: Constraint not satisfied.
[20:22] <fwereade> benji, I haven't seen that one, but it's rare for me to remember to attach bugs ;)
[20:22] <benji> :)
[20:22] <fwereade> thumper, right, I think I've unfucked my logic
[20:23] <fwereade> thumper, although that was what I thought when I propsed originally, so...
[20:23] <fwereade> thumper, anyway
[20:23] <thumper> fwereade: so hangout?
[20:23] <fwereade> thumper, free for a G+?
[20:23] <thumper> aye
[20:23]  * fwereade start one
[22:12] <thumper> ah poos
[22:12] <thumper> hi davecheney
[22:12] <thumper> davecheney: you are not related to that first msg
[22:12] <thumper> :)
[22:14] <davecheney> morning
[22:14] <davecheney> i could be a poo
[22:14] <davecheney> you never know
[22:31]  * m_3 definitely a pooh
[22:37] <m_3> davecheney: I'm just crunching on the queue... available to g- at your convenience
[22:37] <m_3> the charm queue is quite sysiphean this week
[22:40] <davecheney> m_3: eep
[22:40] <davecheney> ok, will send you a hangout in the next 30 mins
[22:42] <m_3> cool... good for another three hours or so
[23:25] <davecheney> m_3: https://plus.google.com/hangouts/_/be405f06d5b6f273d4eb071ded2408bf336e502a?authuser=1&hl=en
[23:26] <m_3> ack
[23:26] <m_3> omw
=== arosales1 is now known as arosales
=== wedgwood is now known as wedgwood_away