=== weblife is now known as web-brandon [00:43] thumper: what's your stance on things like ctx/txn? [01:44] axw: I strongly prefer what uncle Bob calls "Unse Pronounceable Names" [01:45] personally I use context [01:45] and prefer transaction [01:45] thumper: ok. my reasoning is that, for things like ctx, the translation to context is automatic (for me) [01:46] so I pronounce it "context" [01:46] but the point is, you need to translate [01:46] there is a cognitive process there [01:46] that takes ctx, and makes context [01:46] not consciously [01:46] but it is there [01:46] when I see it, I still see "see tee ex" [01:46] sure, so is translating source code into your native language [01:46] i think it's a very minimal cost [01:46] and we're trained to do it very effectively [01:46] davecheney: but writing code is all about people reading it [01:46] if it's not the same for everyone that's fair enough [01:47] axw: I agree that some don't have that [01:47] but do you have a problem reading "context" as a variable? [01:47] davecheney: computers are easier to train [01:47] thumper: only when it means the source line > 80 chars, or becomes a series of ugly lines [01:48] * davecheney is sad that we can't apply common sense here [01:48] axw: I agree, in which case the logic should be simplified [01:48] computers are good at optimising [01:48] davecheney: common sense isn't as common as we'd hope [01:49] axw: I remember writing some code one, it was c++ [01:49] where I managed to use a single for_each function [01:49] thumper: btw I'm not advocating ctx necessarily, just playing devil's advocate [01:49] in the end though, I rewrote it with a normal for loop that took two or three more lines [01:49] because it was more readable [01:49] one of my favourite programming mantras is: [01:50] just because you can, doesn't mean you should [01:50] however, smart C++ programmers would have been able to see what my extremely clever function was doing [01:50] but it wasn't obvious [01:50] I'd go for obvious over clever every time [01:51] however, I feel that there are some on our team that prefer clever [01:51] thumper: agreed. I used to fall into the clever code trap, but try hard to steer away from it now. It doesn't scale well in teams, and I tend to forget what my code is meant to do [01:51] agreed [01:52] * axw remembers in horror at his former colleagues' naming conventions [01:53] or lack thereof [01:53] basically all the variables would be the first letter of the variable's compound word type [01:53] var atp AggregateTableProvider [01:53] fun times [01:58] haha [01:59] bbl, lunch === jtv2 is now known as jtv [02:24] thumper: txn reads perfectly well! :) [02:25] thumper: however when I see ctx my mind pronounces it as "cuntox" [02:25] heh [02:25] blame big kev ... [02:25] well, everyone is different [02:25] yeah [02:25] which is precisely why you are right [02:25] the idea is to code for the majority [03:03] poking through the state pkg, and noticing some odd items a couple of the docs have counts, like serviceDoc has relation count, relations have unitcount.. is that just an optimization vs querying those? [03:49] kvt: probably [04:26] bigjools: ping [04:27] davecheney: hail [04:28] * thumper read that as 'fail' [04:28] perhaps I have too much on my mind [04:28] understandable [04:55] jam: I've added Dubai to my clock city list so I can know what time it is there. [04:56] thumper: :) [04:56] jam: so you are 8 hours out from me [04:56] jam: got time for a quick hangout? [04:56] thumper: right. I'm right at the end of your day, I believe. though it depends whether I wake up and poke around before officially "starting". [04:56] sure [04:56] * thumper starts one [04:57] https://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b152404?hl=en [04:57] jam: ^^ [04:58] thumper: trying to connect, it rings on my phone where I don't want to connect [04:58] and isn't loading on the desktop where I do [04:58] haha :( [04:58] hmm.. [04:58] jam: did you want to set one up [04:58] ? [04:59] let me make sure I'm signed into all of my accounts quickly [05:00] thumper: I'll call you back, it is just getting stuck at "joining video call". [05:01] kk [05:02] calling you [05:02] https://plus.google.com/hangouts/_/f16d2fd28ebc5923a5ceb1a2e1ffc57f5b152404 [05:02] thumper: ^^ [05:02] I really don't prefer the "calling" style of hangout, vs just creating one and having people join it. [05:41] night people === tasdomas_afk is now known as tasdomas [06:21] bigjools: 16:19 < kurt_> davecheney: do you know this error? error: cannot create bootstrap state file: gomaasapi: got error back from server: 400 BAD REQUEST [06:21] any ideas ? [06:22] davecheney: yes, maas was not accepting empty files. There's an SRU about to go out for it [06:22] if desperate, use the daily PPA [06:24] ok, will tell 'em [06:37] bigjools: did you see my comment on the gwacl/vhd bug? [06:37] axw: from this morning? [06:38] if so yes, and I replied [06:38] oh [06:38] (yes) [06:40] bigjools: thanks. didn't get an update - I thought it would auto-subscribe me [06:42] axw: hang on, you are upset because LP _didn't_ spam you ? [06:43] you'll quickly change your tune [06:48] haha [06:49] most of the spam I get is because stupid people stupidly do stupid team nesting in teams that have stupid subscriptions [06:49] this is why I left ~uju as soon as I could [06:49] ~juju even [06:49] yes, that guy in china who subscribes me to bugs with the intel chipset [06:49] WTF [06:53] allenap: poke about https://code.launchpad.net/~allenap/juju-core/makefile-stuff/+merge/181113 I commented on it, but haven't heard a response from you yet. [06:54] axw: is there a reason https://code.launchpad.net/~axwalk/juju-core/testing-mgo-nounixsocket/+merge/181218 isn't landed? [06:55] jam: nope, I just forgot to. thanks - I'll do it now [06:56] axw: I was guessing so. I'm just going through activereviews and cleaning it out. [07:13] jam: looks like the bot's /tmp is full of gocheck dirs [07:13] are you able to clean that? [07:13] axw: if you're able to see it, you're able to clean it, but I'll do it [07:13] I can see it because my MP failed [07:13] tests failed, because /tmp/gocheck-blah exists [07:14] jam: gocheck doesn't set a seed for rand when it generates the temp dirs [07:39] mornin' all [07:54] morning rogpeppe [07:54] jam: hiya [08:01] rogpeppe: I have a couple more CLI API patches up that would appreciate a quick review. [08:01] jam: ok, will have a look [08:01] https://codereview.appspot.com/12744052/ [08:01] and [08:02] https://codereview.appspot.com/12744053/ [08:04] jam: BTW we can work around the int64 vs float64 thing if we want to, but given that the API is accessed from javascript, I'm not entirely sure we should. [08:05] rogpeppe: right. My concern is if someone out there is getting their settings as YAML and then parsing it into a struct that requires an int. [08:05] We do have a "type" object in that struct, though. [08:05] So the other option is that GetConfig/SetConfig start understanding the actual content of those messages [08:06] but I'd like to just punt on all that :) [08:07] rogpeppe: gustavo mentioned we can change the decode function to "UseNumber" but I'm not sure what that actually changes? If it doesn't have a decimal you get an int64? [08:07] It uses arbitrary precision integers? [08:09] jam: you can change it to get any type you want - one possibility is just to use a string. [08:10] rogpeppe: I tracked it down, it is "json.Number" which is actually a string, and then you "Number.Float64()" [08:10] it still wouldn't let us use DeepEquals easily [08:10] but it would let us get what we want later on. [08:10] But if we have to do that step [08:10] we can int64(floatValue) [08:10] jam: thx for review. setting an option to nil means unsetting it, so that the default is valid. and setting an option to "" will not be translated to nil anymore (as before). so for string options "" is a valid value while it's an error for other ones (like in pyjuju). [08:10] and it just matters when you have > 40bits of precision in your int74 [08:10] int [08:11] TheMue: right that is where I thought we were going: Allow "" to be a valid setting, and use nil to indicate you want a default value. So your patch fits that just fine. [08:11] jam: exactly [08:11] jam: and that might actually be a problem [08:12] jam: yep [08:12] rogpeppe: you mean losing precision on ints? [08:12] jam: yes [08:12] jam: we might be causing subtle breakage in existing charm usage [08:13] rogpeppe: float64 has exact precision up to ~52 bits so it only matters if someone enters 2**61+1 that they care about that +1 [08:13] jam: yes [08:13] jam: but that still might be important [08:13] jam: for instance someone might be storing bytes in there or something [08:14] rogpeppe: don't store bytes in a number type [08:14] I think that is a fine statement [08:14] we have strings [08:14] jam: indeed [08:14] and base64 [08:14] jam: but it's still a possible issue [08:14] rogpeppe: I would be willing to take a patch that changed "juju set" to notice that you might lose precision and warn you [08:14] rogpeppe: I'm happy to deal with it when someone shows it is an actual problem. [08:15] jam: tbh i think it's ok to just say we only cope with 52 bits of precision [08:15] rogpeppe: I feel the same way. [08:15] jam: in fact, we *could* deprecate the "int" type entirely [08:15] which is why I JFDI with float() [08:15] jam: +1 [08:36] jam: those two CLs reference the same MP [08:36] jam: i think i just reviewed the one without the prereq [08:37] jam: so it proabably counts as a review of both :-) [08:50] rogpeppe: yeah, I meant https://codereview.appspot.com/12943045/ [08:51] rogpeppe: so for Client object. What fwereade_ really wanted is to avoid exposing "Environ" to the CLI code as much as we can (because we shouldn't need stuff like provider creds for almost everything we do). [08:51] jam: yeah, that seems reasonable [08:51] rogpeppe: beyond that, there isn't much that api.State provides CLI above "api.State.Client()". [08:52] jam: agreed [08:52] so I'd like to start with restricting it to just Client, and see if we can make it with that [08:52] jam: i think that sounds fine too [08:52] but I'm happy to fix the comment [08:52] rogpeppe: ah, back to you. IT turns out that multiple Close of api.State actually isn't ok [08:53] underneath api.State.Close() just calls rpc.Conn.Close() [08:53] which returns: errors.New("already closing") [08:53] rogpeppe: should multiple Close calls be an error? [08:53] jam: it's not clear [08:54] rogpeppe: we had a test that state.State.Close() can be called multiple times (though like I copied, it didn't actually check the err return :) [08:54] jam: on network connections, i think the second close will return an error [08:54] you can add that, and it passes [08:54] it fails for api.State.Close() [08:56] jam: we could make rpc.Conn.Close return nil if it's already closing [08:56] rogpeppe: that would be my preference, but you wrote it and I wanted to check what your reasoning was [08:57] jam: i think i was principally following the original logic of net/rpc [08:57] jam: which returns an error in that case [08:58] jam: (if in doubt i followed net/rpc's conventions) [08:58] rogpeppe: right: http://golang.org/src/pkg/net/rpc/client.go?s=7213:7248#L262 [08:58] though it returns a typed error [08:58] which we could suppress at a higher level if we wanted. [08:58] jam: that's true. but it's a typed error that actually means two possible things [08:59] jam: 1) you just closed it; 2) the server shut down on you [08:59] rogpeppe: sure, though if I'm calling Close() and that happened to be shutdown by the remote side, that doesn't sound like an error [09:00] so I don't know if you need to distinguish between the two cases in this path [09:00] in *my* opinion, Close() is one of those idempotent functions that you can call multiple times to make sure resources were cleaned up [09:00] rogpeppe: if you agree, I'm happy to change rpc.Conn and assert it higher in the stack. [09:02] jam: I think that sounds reasonable (presumably you mean "lower in the stack"?) [09:02] rogpeppe: well I mean assert it across the stack [09:02] so we assert api.Client.Close and APIConn.Close() and api.State.Close and rpc.Conn.Close() [09:03] They happen to be implemented in terms of eachother, but it is nice to have the statement "Close() is idempotent at the various levels" [09:03] jam: what's APIConn ? [09:04] rogpeppe: juju.APIConn [09:04] jam: oh doh! [09:04] Contains an api.State and api.Environ [09:04] rogpeppe: mirroring juju.Conn [09:04] jam: yes, that all seems reasonable [09:04] but *probably* going away [09:04] I didn't want to be ripping it out at this point, but we have api.Client() where functionality that needs a place like juju.Conn can go, there doesn't seem much point in having both, and we *don't* want most CLI things to need an object that has Environ on it. [09:05] jam: yes, i think it will probably go away, though there are one or two lingering bits [09:05] rogpeppe: hopefully most of it involves moving things into the API :) [09:05] jam: yeah, i'm very much +1 on putting everything behind api.Client [09:06] jam: it wasn't possible before, because we couldn't mix logic that involved both Environ and State in a State method. [09:08] rogpeppe: out of curiousity, why is rpc.Conn defined in "server.go" rather than "client.go" ? [09:08] jam: it could be either [09:08] jam: it's both the server and the client side [09:09] jam: it could have been in a separate file, i guess, but i don't think it's a big issue [09:10] mgz: morning! [09:10] qmorning! [09:11] rogpeppe: no, it just wasn't where I was looking for it when dealing with connection on the client side. And the word "Conn" exists all over the place in our source code. :) [09:11] mgz: morning [09:11] jam: you should really use better tooling :-) [09:11] rogpeppe: we should use better names [09:11] jam: rpc.Conn seems just fine to me [09:12] jam: it's unambiguous [09:12] rogpeppe: except for net/rpc/Conn [09:12] jam: they're both connections [09:12] rogpeppe: but they both use "rpc.Conn" and are entirely different code. [09:12] even if they are "similar" [09:13] jam: ah, sorry, thought you were referring to net.Conn vs rpc.Conn [09:14] rogpeppe: there may not actually be a net/rpc/Conn, but punning 'rpc' with a stdlib package is also not great naming. [09:14] jam: in a large s/w environment, there are always going to be duplicate names. the package name spacing means that it's possible to reliably and quickly find the actually definition for any given name [09:14] jam: and there are tools that integrate with your editor that makes that easy to do [09:15] jam: (assuming you use emacs or vim :-]) [09:15] s/actually/actual/ [09:17] jam: do you think that all our names should be globally unique? [09:18] rogpeppe: I'm not sure about globally unique, but avoiding repeated 10 times would be nice [09:18] eg State [09:18] Conn [09:18] and Client [09:20] jam: i think that that's actually a benefit - those names are well known concepts, and they're unambiguous when used in context (rpc.Conn vs net.Conn; uniter.State vs machiner.State, etc) [09:20] jam: i guess it comes down to the "no needless repetition" thing [09:20] jam: which is a conventional approach in Go [09:20] jam: but does have some down sides, as you point out [09:21] rogpeppe: I *do* like not having var foobar foo.FooBar = new foo.FooBar(fooing the bars) [09:21] jam: but you prefer foo.FooBar to foo.Bar ? [09:22] rogpeppe: I like it being really easy to translate "foo := SomethingReturningAFoo()" into what Foo that is returning. [09:23] and using "tools that are already installed on my system" rather than having to dig up "nostandard but useful tools" from 3rd parties. [09:23] jam: presumably if it's foo.NewBar(), that's fairly obvious [09:25] rogpeppe: except it is "rpc.Conn" and that is actually net/rpc/Conn or foo/bar/baz/rpc/Conn [09:25] rogpeppe: so I have to look up what "foo" is actually being imported here. [09:26] jam: it's true that package identifiers aren't unique (we use "testing" many times, for example) [09:26] rogpeppe: and it is a source of confusion occasionaly. [09:27] jam: yeah, it can be. but hopefully in situations where ambiguity might be a problem, we rename the identifiers appropriately. === tasdomas is now known as tasdomas_afk [09:27] jam: we only use net/rpc in one place in our tree, for example === tasdomas_afk is now known as tasdomas [09:27] rogpeppe: so there is "it is unambiguous when you've paged in enough context" and there is "it is unambiguous when you read 3 lines of code" [09:29] jam: personally, i think it's reasonable to assume some contextual knowledge. but that might be just me. [09:29] jam: and i have to say that when browsing code i'm not familiar with, i use godef a lot [09:29] rogpeppe: in a team of 10+ having people look at code that they aren't as familiar with it is *useful* albeit not *required* to minimize the need for contextual knowledge. [09:31] rogpeppe: it is a goal (generally) to code is such a way that it is understandable to people who aren't as intelligent as myself (especially since *I* will not remember everything in 1 month either :) [09:31] jam: i totally agree with that [09:31] jam: but i don't think that the redundant naming helps greatly there [09:32] jam: in general, i find external Go code (using similar naming conventions to our current ones) is quite easy to browse and understand [09:33] jam: but again, i do use godef (and godoc.org) a lot [09:33] rogpeppe: one thing I would *really* like for godoc, is if you could click the Bar in "func Something() Bar)" and have it take you to the definition. [09:34] jam: i think it does that, doesn't it? [09:34] jam: yeah, it does [09:35] jam: it linkifies all type names [09:35] rogpeppe: not in the one-line overview, and the "func Something" doesn't give you the arguments or the return type, but if you keep drilling down until you get to the grey-box with more stuff that does eventually get there. [09:36] jam: i might be looking at a different godoc.org to you [09:36] jam: in the one i'm looking at, it's two clicks [09:38] jam: (one to click on the one line overview, which takes you to the actual description, then another to click on the type name) [09:38] rogpeppe: and a bit of visual searching to find the right thing, but with practice not too bad. I'm not sure if it used to do that, or if the specific layout of the page made it hard for *me* to see it. [09:39] jam: it's quite possible. and the site does change - it might not have been so good in the past. [09:39] I think I would also like to see the overview of functions for a Struct when you go to the structs definition (like there is in the top level index). [09:40] AFAIK there isn't a way to jump to the place in the index [09:40] and the index mixes [09:40] things that return Foo [09:40] with methods on Foo itself [09:40] eg, http://godoc.org/net/rpc has Client [09:40] which has functions returning a Client [09:40] and functions on Client [09:40] but no concise "these are the methods on Client" [09:40] jam: yeah, it tries to classify factory funcs [09:40] I don't mind them being nearby [09:40] but it would be useful to have a simple "here are the methods" section [09:41] jam: that's the overview, i guess [09:41] in my head it would exist here: http://godoc.org/net/rpc#Client [09:41] rogpeppe: they aren't visually distinct from the "here are factory functions" [09:41] they are slightly different [09:41] jam: yeah, you have to look for the (client *Client) [09:42] jam: if you can think of a nice way of visually distinguishing them, i'm sure they'd be open to suggestions [09:42] jam: it's not something that had occurred to me [09:43] rogpeppe: Are all of the tests for "state/api/*" code over in state/apiserver? [09:43] I don't see any _test.go files in state/api [09:43] which is.. a bit surprising [09:44] (I realize you sort of need apiserver in order to test api code, but I would expect to find api tests in the api package) [09:44] rogpeppe: which might be why I put the APIClient.Close test in juju/* [09:44] (I'm only *just now* remembering that I saw some api.Client tests in apiserver a few days ago) [09:45] rogpeppe: as in, I don't have an immediately obvious place to put new tests that api.State.Close() and api.Client.Close() are idempotent. [09:45] rogpeppe: so how do you find where there would be tests for api.State? [09:45] rogpeppe: having a unique name instead of State [09:46] would make that pretty obvious (i would think) [09:46] so references of X not definitions of X [09:46] and some of those references might be in the package itself [09:47] jam: my original scheme for testing API functionality was to put all tests in the client. [09:48] rogpeppe: there are no tests that I see in state/api/*, and there is no state/api/client/ directory [09:48] rogpeppe: is it just that they were moved elsewhere? [09:48] rogpeppe: also, no tests for state/api.State object that I can immediately find [09:49] * rogpeppe goes to look [09:50] jam: the tests that are now in state/apiserver/client did originally live in state/api, i believe [09:52] jam: yeah, that seems to be the case. they should really be in state/api/client, i think [09:52] rogpeppe: I'll file a techdebt bug, but not fix it right now. [09:53] jam: sgtm [09:54] jam: FWIW, i still think that testing all API stuff through the client makes sense, as there's so little actual logic in the RPC layer. [09:54] jam: and the way things are, we've got vast swathes of almost-but-not-quite identical tests at each layer [09:55] jam: i guess the main reason we can't do that is that we decided to expose stuff in the API server that we don't make available in the client.; [09:56] rogpeppe: which I've already run into, though it was in the "and this isn't tested" category AFAICT [09:56] AddUnit supported ToMachineSpec but that wasn't exposed in api.Client [09:57] jam: ha, yes [09:57] jam: i have difficulty keeping track of what our test coverage is in this area [09:57] jam: because the tests are so overlapping [09:58] rogpeppe: so where do you think tests about api.State are today? (where should I add a test that calling api.State.Close() multiple times doesn't give an error) [09:58] jam: i think that tests on api.State should live with the other tests on api.State. [09:58] jam: it seems that that's currently (but wrongly) in state/apiserver/client [09:59] jam: so i'd add it to those, to be moved over at some later date [10:00] rogpeppe, I was taking a casual look at Prepare... there's a 3.5 second sleep in jujud/machine.go [10:00] fwereade_: yes, i've removed that since. [10:00] fwereade_: but not re-proposed the branch [10:00] fwereade_: (that was me trying to reproduce a saw-it-once-only test failure) [10:01] rogpeppe, :) [10:05] rogpeppe, seems fine to me, go ahead and land it, if anything turns out to be a problem for the followup work we'll find out soon enough [10:05] fwereade_: i'm pretty sure it was nothing to do with my changes [10:09] fwereade_: did you have anything to add to the float64() vs int64() discussion about the ServiceGet() api? [10:11] jam, I'm fine accepting the json precision restrictions (well, I don't like it, but I don't think it's worth the effort of fixing) [10:12] fwereade_: well *JSON* supports arbitrary precision integers AFAICT [10:12] golang json.Unmarshal defaults to float64 though you can tweak it to return "type Number string" [10:12] but that would make testing it harder rather than easier AFAICT [10:13] jam, shall we just call it a bug and move on? [10:14] jam, unless you judge it simple enough to make it Right rightnow [10:15] fwereade_: my personal feeling is that 'juju get' will return similar-enough types that it probably isn't a problem, and I'm willing to deal with it when charms themselves really do need it [10:15] jam, seconded [10:15] fwereade_: and I would say the test should be in state/api, except there are 0 tests in there :) [10:15] which is what I was just chatting about with roger [10:15] jam, but let's document it as a bug regardless so it's easier to hunt it down and figure it out when it *does* happen [10:16] jam: presumably we have a potential issue even if we do use int64 because python would (presumably) use arbitrary-precision ints when needed [10:16] fwereade_: bug #1217282 [10:16] <_mup_> Bug #1217282: api.Client tests should be in state/api not state/apiserver/client/

[10:16] jam, oh bollocks, they're all in apiserver [10:16] fwereade_: as yet I haven't actually found direct tests of api.State either. [10:17] rog mentions they might be in state/apiserver/client/* but I haven't actually found a suite that is focused on the api.State object. [10:17] jam, oh yay [10:18] jam: I sent an email that got blocked by the message size limit on juju-dev.... the autoreply I got said it was awaiting moderator approval... are there actual moderators that might approve it, or should I just recreate it? [10:18] natefinch: I am not one of the moderators. Gustavo might be, but it is probably easier to just resubmit. [10:18] I believe you can reject the existing message yourself. [10:19] jam: yeah.... bah. 40k limit? What is this, 1998? :) [10:23] morning evilnickveitch [10:23] I don't remember you having the "evil" goatee, though. [10:23] jam, hey! My facial hair is in a constant state of flux to confuse my enemies [10:25] fwereade_: in https://codereview.appspot.com/12752044/diff/8001/cmd/juju/get_test.go you made a comment regarding "default" in "juju get" [10:26] jam: i'd like to see tests in state/api focused on the functionality that's in that package. you're right, tests for api.State itself seem to have vanished. i'm pretty sure i wrote some originally. [10:26] fwereade_: could you explain your thoughts a bit more? [10:27] fwereade_: i haven't touched the logic of get here, only moved. but i could handle it in a third CL. [10:27] has anyone seen this when testing? [10:27] PANIC: machine_test.go:58: MachineSuite.TearDownTest [10:27] ... Panic: unauthorized db:presence ns:presence.presence.beings lock type:0 client:127.0.0.1 (PC=0x414321) [10:27] TheMue, saying "the value is nil, and that's the default" is redundant/meaningless because a nil value is only possible when there's no default set [10:28] TheMue, so a trivial CL stripping "default: true" out of settings where the value is nil would be cool [10:28] fwereade_: ok, will do [10:28] bbiab [10:33] natefinch: you have https://code.launchpad.net/~natefinch/juju-core/005-azure-address/+merge/181117 still pending though it has my approval. just poking for you to think about landing it. [10:34] jam: thanks, meant to talk to you about that. It's LGTM pending live tests, but the values aren't actually used anywhere in the branches, so I sorta can't live test [10:34] natefinch: I meant "test against Azure" [10:34] natefinch: nice work in the win32 installer [10:34] as in actually running it live [10:35] i hope you get some feedback [10:35] but given the self selection population in the channel [10:35] please don't take it too hard if you don't get a lot of feedback [10:35] davecheney: my message got caught by the size limit on the mailing list, so no one but mods have seen it I suspect :) [10:36] jam: I guess I can insert some temporary code to call instance.Addresses[]... my point was that nothing calls that method in the branch I'm on [10:37] at least as far as I could tell [10:38] natefinch: i saw it === andre____ is now known as andrew_w_deane [10:38] i am not a nod [10:38] mod [10:39] davecheney: oh, ok, so maybe it was let through and there wasn't a message back to me about it... and since I don't think I get my own messages from the list... makes it hard to tell what's going on. [10:40] natefinch: you do [10:40] but gmail doesn't show them too you [10:40] davecheney: oohh... ok, that could be it [10:40] you can also check the listserv directlu [10:41] Ahh yeah, I always forget I can do that [10:42] well, good. [10:58] * TheMue => lunchtime [10:59] natefinch: talking about the windows installer. should we just make a 32 bit one and not worry about it? juju-the-client won't ever really benefit from >4GB addressable space. Though I realize go itself works better in 64-bit because of how it does virtual adress [10:59] addressing [10:59] juju-the-client isn't long lived enough to really matter. [10:59] when we get to 'jujud-the-daemon' we'll want to focus more on 64-bit [11:00] jam: yeah, that's probably a good point. There's very little benefit from 64 bit as you said. And 32 bit is more portable, which is a lot more valuable [11:00] (I originally started in 64-bit, and then went to 32-bit when we had C dependencies, because 64-bit mingw wasn't very good, and was thinking to switch back but maybe we just want to stay 32-bit for juju-the-client for now) [11:05] does anyone know where cloud-init writes the original text of the user data ? [11:10] dave, sec [11:10] i can never find the bugger [11:11] /var/lib/cloud/instance/user-data.txt [11:11] mgz: ta muchly [11:11] bloody hell, cloud-init has everything that opens and shuts [11:11] oh shit, its base64 encoded [11:11] well, that is one terminal i wont be using again [11:12] lol [11:12]