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:18 |
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 | 01:19 |
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:10 |
hazmat | davecheney,sadly no clock unites you, i, m3 and mgz | 02:11 |
hazmat | mail it must be | 02:11 |
davecheney | le sigh | 02:11 |
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:40 |
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:41 | |
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:42 |
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:43 |
davecheney | but we import gocheck into the packages' own namespace | 02:44 |
thumper | ah... | 02:44 |
thumper | davecheney: so how often do you need to do that? | 02:45 |
davecheney | once per pacakge | 02:45 |
* thumper nods | 02:46 | |
m_3 | davecheney: ok, back | 02:57 |
m_3 | davecheney: damn... that totally sucked | 02:57 |
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:58 |
davecheney | should be 2/3pm our time, give or take | 02:59 |
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:18 |
davecheney | thumper: the is the init() hook, which is executed pre main | 03:19 |
davecheney | there is no concept of package loading | 03:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:26 |
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:27 |
* thumper thinks more | 03:28 | |
davecheney | thumper: care to share ? | 03:29 |
* thumper has just worked out why "go test ./..." often has weird delayed output | 04:08 | |
thumper | buffered i/o | 04:08 |
=== jtv2 is now known as jtv | ||
fwereade | mornings | 08:14 |
TheMue | Good morning | 09:35 |
=== TheRealMue is now known as TheMue | ||
hazmat | has anyone been able to get a vpc default/only account? | 11:20 |
mgz | jam, dimitern: standup? | 11:33 |
dimitern | mgz: in a sec | 11:33 |
rogpeppe1 | hi all | 11:41 |
=== rogpeppe1 is now known as rogpeppe | ||
dimitern | rogpeppe: hiya | 11:44 |
TheMue | Hi all | 11:56 |
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 | 12:00 |
=== wedgwood_away is now known as wedgwood | ||
* TheMue needs inspiration regarding JUJU_HOME and testing. Anyone interested? | 13:41 | |
benji | TheMue: sounds like fun... what is JUJU_HOME? | 13:45 |
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:46 |
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:47 |
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:48 |
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:50 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
gary_poster | thanks fwereade | 13:58 |
benji | TheMue: does go have a thread-locals? That is where I would stash slightly-less-than-global-globals. | 14:00 |
TheMue | benji: One moment, meeting. | 14:07 |
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:46 |
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:47 |
gary_poster | cool, thanks | 14:48 |
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:58 |
mramm | gary_poster: mind if I poke my head in? | 14:59 |
gary_poster | mramm, no, please do | 15:00 |
gary_poster | fwreade, rogpeppe, the conversation is so scintillating in our chat room that I'm sure you want to join in... | 15:02 |
rogpeppe | fwereade: how about something like this? http://paste.ubuntu.com/5610973/ | 15:27 |
rogpeppe | fwereade: except... what to call "EntityName"? | 15:27 |
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:34 |
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:35 |
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:38 |
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:39 |
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:40 |
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:41 |
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:42 |
rogpeppe | fwereade: this better? http://paste.ubuntu.com/5611029/ | 15:44 |
fwereade | rogpeppe, sorrt | 15:44 |
fwereade | rogpeppe, yeah, I think so | 15:44 |
rogpeppe | fwereade: promise? :-) | 15:46 |
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:47 |
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:52 |
rogpeppe | fwereade: i.e. have you got a better name for it? | 15:53 |
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:03 |
rogpeppe | fwereade: yeah, i think it's orthogonal, and can be treated as a separate issue to be fixed independently | 16:04 |
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:06 |
rogpeppe | fwereade: one thought we had: "ExternalName" (i'm not that keen but just throwing it out there) | 16:07 |
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:08 |
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:12 |
rogpeppe | fwereade: okeydokey | 16:15 |
TheRealMue | fwereade: ping | 16:48 |
TheRealMue | fwereade: Have to step out but will ping you again later. ;) | 16:49 |
rogpeppe | mgz: have you used bzr pipelines? | 17:03 |
mgz | rogpeppe: I have, but abentley is the real expert | 17:03 |
rogpeppe | mgz: ah. i'm hoping they'll "just work" with cobzr, but i wanted to check before potentially destroying my repo | 17:04 |
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:05 |
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:06 |
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:07 |
rogpeppe | mgz: yeah | 17:08 |
mgz | well, you shouldn't need to merge is the point, just pull in the revs | 17:09 |
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:15 |
rogpeppe | abentley: thanks! | 17:16 |
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:36 |
rogpeppe | abentley: but i just created the branch and merged in. no problem. | 17:37 |
abentley | rogpeppe: What was the command you typed? | 17:39 |
rogpeppe | abentley: bzr add-pipe name-of-existing-branch | 17:39 |
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:41 |
abentley | rogpeppe: cool. | 17:43 |
rogpeppe | abentley: first pipeline operations completed successfully - one pump, one interactive back merge. very useful! | 17:44 |
abentley | rogpeppe: great. | 17:44 |
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:54 |
gary_poster | yay rogpeppe thanks! how many left after that? | 17:55 |
rogpeppe | gary_poster: probably three or four | 17:55 |
gary_poster | rogpeppe, ok cool, thanks. I'll look forward to reviewing soon. | 17:56 |
rogpeppe | gary_poster: thanks a lot | 17:56 |
rogpeppe | gary_poster: bzr pipes are going to make my a *lot* easier here, i'm hoping... | 17:57 |
gary_poster | lol, I bet | 17:57 |
rogpeppe | right, that's me for the day | 18:49 |
rogpeppe | see y'all tomorrow | 18:50 |
=== _thumper_ is now known as thumper | ||
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:10 |
thumper | fwereade: I'm just reading your email response | 20:11 |
thumper | sure | 20:11 |
fwereade | thumper, cool | 20:11 |
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:19 |
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:22 |
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 | 20:23 | |
thumper | ah poos | 22:12 |
thumper | hi davecheney | 22:12 |
thumper | davecheney: you are not related to that first msg | 22:12 |
thumper | :) | 22:12 |
davecheney | morning | 22:14 |
davecheney | i could be a poo | 22:14 |
davecheney | you never know | 22:14 |
* m_3 definitely a pooh | 22:31 | |
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:37 |
davecheney | m_3: eep | 22:40 |
davecheney | ok, will send you a hangout in the next 30 mins | 22:40 |
m_3 | cool... good for another three hours or so | 22:42 |
davecheney | m_3: https://plus.google.com/hangouts/_/be405f06d5b6f273d4eb071ded2408bf336e502a?authuser=1&hl=en | 23:25 |
m_3 | ack | 23:26 |
m_3 | omw | 23:26 |
=== arosales1 is now known as arosales | ||
=== wedgwood is now known as wedgwood_away |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!