[00:07] i'm trying to debug why the charm store doesn't have a particular charm.. specifically landscape-client none of the personal versions or the 'official' version are available [00:08] i wrote a quick go program and verified that the charm loads correct, and that the its in the ls getBranchTips output.. [00:08] i'm stumped as to why its not in the store then.. any suggestions? [00:12] hmm.. i did find one personal archive in the store.. cs:~therve/precise/landscape-client ( but none of the 4 others seems to have made it) === slank is now known as slank_away [04:58] Is the schema package documented anywhere? [06:24] This is driving me nuts. Getting a strange error in my tests: [06:24] Panic: runtime error: invalid memory address or nil pointer dereference (PC=0x8057A45) [06:25] Weird thing is, this is the third of a series or near-identical lookups. [06:25] jtv: what are the first couple of lines at the end of the panic dump? [06:25] I'm trying to test an environs/*/config module. [06:25] paste? [06:26] Hi dimitern! Coming up. [06:26] hi :) [06:26] dimitern: https://pastebin.canonical.com/83822/ [06:26] Part of the weirdness is that I see no reason why that configuration string shouldn't be there. [06:27] jtv: so do you have admin-secret defined in the config attrs? [06:27] I thought I did. [06:29] jtv: can I look at the module that fails? have you proposed the branch? [06:29] Not yet. I'll put it up for you somewhere. Thanks. [06:31] dimitern: try lp:~jtv/juju-core/mpv-config [06:31] jtv: np, I know how it is with these pesky go errors - it took me some time to start getting what's actually was wrong [06:31] * dimitern looking [06:33] I made _some_ progress: I converted a c.Check(err, IsNil) to an assertion and now at least I'm not getting the segfault. [06:33] Just a failure I can't explain. [06:35] I could see how the checks for all 3 config items would fail. But what did I do to break just the last one? [06:36] jtv: so the difference between Check and Assert is only in that the latter fails the test immediately, while the former still marks it as failed, but continues to run it, so there's something going on after that Check you changed [06:37] Yes... and I'm not even so worried about that. [06:37] What I'm worried about is how the error comes back non-nil in the first place. [06:37] (The check that fails looks a bit different from the others right now, but that's from experimentation with the problem.) [06:39] jtv: so I can see a potential problem in newConfig [06:40] jtv: cfg should be := make(map[string]interface{}) [06:40] jtv: but since you're initializing it, probably should be ok - but try separating the making and init [06:41] Yeah. I've just been doing that for new(). [06:41] I haven't been able to find any explanation as to why make() is needed if returning the address of a local is guaranteed to be OK. [06:41] jtv: try: cfg := map[string]interface{}{values} - can skip the loop [06:41] make is needed for maps [06:42] or slices [06:42] * jtv tries [06:45] dimitern: I'm not so sure I can skip the loop... "values" is meant to complement (and override) the existing "cfg." [06:47] dimitern: no change. :( [06:47] jtv: hmm [06:47] jtv: let me try you branch locally [06:49] Thanks again for helping out. I really appreciate it. [06:51] np [06:56] dimitern: I just updated my branch to avoid stack allocation of persistent objects. [07:00] jtv: so as far as I can see, admin-secret is not set for some reason by the time it's validated in config:Validate() [07:01] Yes... but how is it different from the other items? Wait... maybe it has a special meaning to juju. [07:01] Yup. [07:01] I guess attrs only receives the "unknown" attributes, and the juju-standard ones go somewhere else. [07:02] hmm shouldn't be [07:02] I'm comparing it with openstack provider to see what could be wrong [07:02] Yup. That's part of what I cargo--culted. [07:06] I think the map is structured wrong [07:06] see, the attrs should match the environments.yaml [07:06] i.e. tree-based, not flat [07:06] type attrs map[string]interface{} [07:06] cfg := attrs{"environments":attrs{"testenv":attrs{"type":"maas"}}} [07:07] something like this [07:07] Well this is related to rogpeppe's ongoing work tighten up those tests. [07:07] When you don't need to do the round-trip, you don't need that tree above the environ config. [07:08] hmm [07:10] yes it seems if you're using tree-based cfg, you need to marshal it to yaml and use ReadEnvironBytes, otherwise NewFromAttrs [07:12] sorry I couldn't help more, but ask rogpeppe when he's around [07:12] I will. Thanks. [07:12] (What you see is copied from his proposed test change :) [07:13] I see :) yeah, definitely he's the man then [08:19] jtv, dimitern: hi [08:19] rogpeppe: hiya [08:20] jtv: are you still around? [08:23] dimitern: what's the name of jtv's branch? i'll take a look at what's going on. [08:24] rogpeppe: lp:~jtv/juju-core/mpv-config [08:30] dimitern: ta [08:54] Hi rogpeppe [08:54] jtv: hiya [08:55] jtv: i'm just having a look at your branch now [08:55] My problem is now that I'm not seeing my admin-secret in my test config. [08:55] Thanks. [08:56] jtv: nearly worked it out. it's being lost in maasEnvironProvider.Validate [08:57] Is it? I wrote it, but I have no idea what most of it means. It's just stuff that seems to be needed based on other implementations. [08:57] jtv: yes, i'm afraid the config stuff is not ideal. it's been through a fair few iterations, but we're still not entirely happy with it. [08:57] jtv: well, i'm not anyway :-) [08:58] jtv: i think you're right about making the round trip test separate BTW [08:58] Thanks. [08:58] I don't mind a bit of legacy complexity, but it'd be so nice to know what's going on! :) [08:59] Hmmm mango from my own tree. [08:59] hey all [09:00] fwereade: yo! [09:00] fwereade: hey! [09:00] jam, dimitern, mgz: if you want to talk about last night's braindump let me know [09:01] fwereade: what's that? [09:02] hum, did I just send it to mramm? [09:03] dimitern, about get/set and upgrade-charm [09:03] fwereade: ah, this one, yeah [09:03] fwereade: sounds interesting [09:04] fwereade: I have a couple of things in line on the provider, which I hope to land today and then I can look into get/set or charm upgrades [09:05] dimitern, I strongly favour all of us having a chat about them before anyone gets too deep into implementing them, there are probably assumptions that I have failed to capture that a chat could smoke out [09:05] fwereade: sure, we'll talk first, I have no idea where to begin anyway :) [09:08] jtv: ah, i've found your problem [09:08] jtv: at least, i think i have; let me check. [09:08] jtv: yup. [09:09] jtv: the problem is you've included "admin-secret" in the maasConfigChecker schema fields [09:10] rogpeppe: that's odd - so what does this cause? [09:10] jtv: but you need to put only fields that are unknown to the config package in there, otherwise they'll override the known attributes when you do the Apply at the end of Validate. [09:11] jtv: the fact that you needed to put admin-secret in the schema defaults, despite it being a required field, was probably a hint. [09:11] I see. Thanks for finding that! [09:12] jtv: it's easy stuff to get wrong though. i'd love to find a nice way to factor out a lot of this stuff. [09:12] I wasn't aware that I needed to put it in the schema defaults, really. [09:12] rogpeppe: so schema defaults is only for fields which are not required and should have defaults? [09:12] dimitern: if you don't have a schema default, the field is required [09:12] rogpeppe: I see! [09:13] dimitern: but in this case the schema is used to validate only fields returned by config.Config.UnknownAttrs [09:13] rogpeppe: I get it now [09:14] 10x [09:14] Oh, so if I want these fields to be required, I can just leave them out of the schema instead of checking for them. [09:14] I mean, out of the defaults. [09:14] Not out of the schema, obviously. [09:14] jtv: out of the defaults, yes [09:14] Yayy that gets rid of some code. [09:15] jtv: that's kinda the point of the schema - it does quite a few checks for you so you know it's in a certain form before you start checking [09:15] Yeah, it's just that I couldn't find any documentation whatsoever for it. [09:15] So I had no idea what it did that I could rely on. [09:15] it's probably worth a comment somewhere then! [09:15] It would be, definitely! [09:15] jtv: have you tried "go doc launchpad.net/juju-core/schema" ? [09:16] Nope. [09:16] jtv: if in doubt, read the docs :-) [09:17] Hmm... that just produced the stuff I'd already read. [09:17] jtv: although they're not great there, it's true [09:17] Not documentation, just implementation notes. [09:18] What is a Checker? A Checker is called recursively etc. Now you know, so the rest can be explained in terms of Checkers! [09:18] jtv: yeah [09:18] jtv: one of gustavo's earlier efforts :-) [09:18] I find one of the hardest things to imagine is not knowing something that you do know. [09:19] The ability to grasp something complicated and to explain it don't really fit comfortably into one brain at the same time. :( [09:19] jtv: there should be a package-level comment that explains how things work [09:19] Definitely, yes! [09:20] jtv: one small remark: usually we name error values starting with "err", so your "noMaasServer" would be errNoMaasServer. [09:22] jtv: another one: there's not much point in putting a "maas" prefix on types/variables that are local to the maas package, so i'd define "environProvider", not "maasEnvironProvider", etc, thus saving quite a bit of typing :-) [09:22] Ah OK, I'll patch that up quickly, thanks. [09:22] jtv: ah, and error messages generally don't start with capital letters (they usually form part of a longer "sentence") [09:22] Well I found the environProvider slowed me down a lot because it sounds just like EnvironProvider, and because it's relative to the package you're in. [09:23] Ah, yes, back to K&R times. :) [09:23] When Bearded Dinosaurs Roamed the Earth. [09:23] :D [09:23] Can I punctuate? [09:24] jtv: sure, but there's generally no full stop. an error message isn't the full message that will be printed to the user. [09:24] Ah. [09:24] Good thing most of those error messages are no longer needed! [09:25] jtv: environProvider is supposed to sound like EnvironProvider BTW - it's a provider-specific implementation of the EnvironProvider interface. [09:26] jtv: all types in Go are relative to their package - it's common to define names that make sense in the context of the package itself. [09:27] jtv: so if you think of it as "maas.environProvider" it perhaps makes sense. rather than "maas.maasEnvironProvider", which has a certain amount of redundancy. [09:28] I understand that they're supposed to sound similar, but they sound _too_ similar! And I'm fully aware of the whole idea of nested namespaces. I myself thought that was a good idea, back in the 20th century. The real world taught me otherwise! [09:29] The best way to use a language is to use the idioms of that language. Java in Java, Smalltalk in Smalltalk, Go in Go. [09:30] jtv: namespaces aren't nested - they're two llevel. package.name [09:30] jtv: well, three level if you count structs and interfaces. [09:31] jtv: what TheMue says - this are just standard Go idioms. they seem to work pretty well most of the time. [09:31] Film at eleven! [09:31] jtv: :-) [09:32] I mean, this stuff we all know. I'm not saying it's new to me, but that it's stuff I found to be bad ideas. [09:32] jtv: what made you think that nested namespaces weren't a good idea BTW? [09:33] It increases the overhead of finding out what's going on. If I see package.Name, I need to find out which package that actually is. [09:33] It's an extra step of indirection in an inner loop. [09:33] Increases the overhead of understanding new code tremendously. [09:33] jtv: luckily it's possible to do that mechanically and instantly. [09:34] But tools like grep won't know about that. [09:34] jtv: there are tools that do. [09:35] i think what's confusing at first is that modules and files are not orthogonal in go [09:35] jtv: making all names unique takes us back to the pre-K&R days of having a shared struct field namespace [09:36] jtv: i mean pre-ANSI C of course [09:36] you can have module X, which is spread across several files and all of them define it, so finding X.Y is not as straightforward as in other langs [09:37] dimitern: Thankfully packages and files aren't the same. It would be a hard limitation. [09:37] but has it's advantages too ("silent" scope membership) and access in-module [09:39] dimitern: yeah, i rely heavily on godef (http://godoc.org/code.google.com/p/rog-go/exp/cmd/godef) [09:39] dimitern: which takes me straight to the definition of any name. [09:39] rogpeppe: sweet! I didn't know this [09:40] rogpeppe: thanks, I'll definitely use this [09:40] beats rgrep by a margin :) [09:40] dimitern: i believe there's perhaps similar functionality in some of the Go-modes for other editors. [09:41] rogpeppe: not for emacs, AFAIK [09:41] dimitern: BTW godef is a not-too-thick layer on top of http://godoc.org/code.google.com/p/rog-go/exp/go/types [09:42] dimitern: so you might want to customise it for your situation [09:42] dimitern: (it's nice when a single click takes you to the definition. [09:42] rogpeppe: yeah, I could try to automate it somehow from the editor when I have some time [09:42] ) [09:44] dimitern: it's particularly good when you've got something like: x.foo.Bar().Arble, in the middle of a loop where is the loop variable etc, and you can click on Arble and it'll do all the type inference (through embedded fields too) and go straight there. [09:44] rogpeppe: so not only X.Y, but even more complex expressions are supported [09:45] dimitern: yeah - it supports almost everything. one notable limitation is it doesn't support import to "." [09:45] dimitern: i need to fix that [09:45] rogpeppe: ah, yeah, I see how this can be tricky [09:47] dimitern: it's not actually too tricky - it's just not as efficient as i wanted it to be. i thought . imports would be very rare, but gocheck is a sadly common exception. [09:47] yeah [09:50] jtv: as for grep, i have an experimental command which covers some of the same ground, and makes it possible to grep for particular symbols even if they don't have a unique name: http://godoc.org/code.google.com/p/rog-go/exp/cmd/gosym [09:51] Argh, more tools, more cognitive load! [09:53] jtv: that's the unix way :) [09:56] jtv: BTW a grep pattern i use quite a bit: grep for ' Foo(' finds functions and method names named Foo, with surprisingly little redundancy. [10:04] w7z: /wave [10:04] morning [10:04] hey! [10:05] w7z: good to have you back. how was fosdem? [10:06] good! I'm feeling a little fluish as an after effect, but not as ropey as I was last night, just ignore the coffing [10:18] rogpeppe: sorry for being quiet — in meetings! [10:19] rogpeppe: can you take a look at a couple of related trivials? https://codereview.appspot.com/7307046/ and https://codereview.appspot.com/7299045/ [10:20] jtv: np [10:20] jam, w7z: morning [10:22] rogpeppe: would you be up for reviewing that branch? It's for our feature branch. [10:22] jtv: sure [10:22] jtv: did you see my comments on gomaas BTW? [10:23] Oh, yes... still have to go into details with those. [10:24] Too many tabs open! [10:24] jtv: i have that problem [10:24] The Launchpad+Rietveld split makes me worse at it. :) [10:24] Found it. [10:25] rogpeppe: I just saw your review on gomaasapi, thanks a lot for that, I'll work on it today. [10:25] rvba: cool, thanks. [10:25] rogpeppe: ^^ it's what we discussed last week [10:25] In particular, we did talk about the idea of representing a higher abstraction level. [10:25] dimitern: am on it [10:25] rogpeppe: thanks [10:26] We didn't want to mirror the whole MAAS API on that side manually — so our hope is that at some point we can generate a native API representation in some automated fashion. [10:26] Until then, given time constraints, we kept it very basic. [10:27] jtv: perhaps, to start with, you could restrict the provided API to the things that juju needs. [10:28] jtv: and build it up from there. [10:28] That option came up, but it's still mirroring the API details manually... plus it increases the risk of moving to an automated API. [10:28] Because it may require changes in approach. [10:29] For now we don't need to make very intensive use of the API yet, so we went with something highly generic that'll do for what we need. [10:29] Time pressure is a big thing for us. :) [10:29] jtv: as it is, the gomaasapi package is pretty incomprehensible without a deep understanding of how the maas client-server interaction works, which seems to lose the point of the package. [10:30] Yes, but bear in mind that the package's immediate reason for existence is the work we're doing now, immediately after. [10:30] So see this more as laying the foundations for an independent front-end, rather than providing a full front-end for general use. [10:31] (Also the MAAS API is extensively documented, so though it's not easy, it should be possible to figure out) [10:31] jtv: i'd be happier if the surface area was much smaller. [10:31] Measured in what terms? [10:34] jam: why you think it'll be tricky to land my change? what ordering? [10:34] dimitern: you can't just mark it approved, because it won't past the juju-core test suite [10:34] I mentioned it in my email [10:35] jam: yes, so how then [10:35] jam: juju-core first? [10:35] jtv: the number of artifacts exported from the package [10:36] jtv: most of the functions and methods in the package feel like http utility functions. [10:37] Well to be honest some of those things probably just shouldn't be exported — but those things are subject to change and Go makes it a bit harder to streamline them. [10:37] dimitern: so you can, at the risk that if there was something you didn't catch, you've broken the juju-core suite until your goose patch lands. [10:37] The manual way is to do the merges locally, make sure everything passes, and then push them up to the right location. [10:38] jtv: what do mean by "Go makes it a bit harder to streamline them." ? [10:38] rogpeppe: all you really need to know, I think, is JSONObject, MAASObject, and a constructor. [10:38] Un-exporting an item means changing its name everywhere. [10:38] jam: can you explain the manual way in more detail? [10:38] jtv: luckily the compiler will tell you exactly where you need to change the name... [10:39] Yes, but you have to go ask it. [10:39] And make the changes. [10:39] Being told by a computer what work you need to do is not the same as not having to do it. :) [10:39] jtv: sure, but it's not more than a minute or so's work. [10:39] dimitern: cd $GOPATH/src/launchpad.net/juju-core; bzr merge MY_JUJU_PATCH; cd ../goose; bzr merge $MY_GOOSE_PATCH; py test.py (-live); cd ../juju-core; go test ./...; bzr commit -m "?"; cd ../goose; bzr commit -m "?"; bzr push bzr+ssh://goose-bot@bazaar.launchpad.net/~goose-bot/goose/trunk; cd ../juju-core; lbox submit [10:40] rogpeppe: I'm sure it is. But so is everything else! [10:40] jtv: (BTW i did write that gosym command to try and make it easy to make bulk changes like that automatically; it needs some work though) [10:40] Oh, it helps automate that? That'd be very helpful for something like this. [10:40] jtv: can you explain the rationale behind JSONObject, BTW? [10:40] rogpeppe: does 'go fmt' take a regex, or do you use go fix? [10:41] (can you use go fix?) [10:41] jam: gofmt can do expression rewriting, but it's not type-aware. [10:41] jam: go fix is only used for go core API changes [10:42] rogpeppe: sure, I wasn't sure if you could pass it your own transformations. [10:42] jam: and if I do it the usual way - first submitting the juju patch, and immediately after coping the commit msg in the MP in LP and marking it as Approved? [10:42] rogpeppe: JSONObject is there to provide an abstraction layer that lets us provide (and test) dynamic data types including MAAS object types. [10:43] jam: no. i think that coming up with a language that can express sufficiently transformations is a hard problem [10:43] dimitern: juju-core will be broken for like less than 10m [10:43] dimitern: if juju lands first, it should work, but you just open the risk that you've broken the test suite until goose lands. [10:43] rogpeppe: I know the caller could just do everything with casts, but that takes aware our room to explore the problem and make changes. [10:43] jam: ok, I'll try that - it seems simpler [10:43] dimitern: it is the "wrong" order, but I'm pretty sure it is what wallyworld did earlier, and it certainly is easier :) [10:44] jam: i tried the "right" way, but no luck [10:44] dimitern: it will stop working once commits t ojuju-core actually have to pass their test suite. [10:44] wallyworld: what step didn't work for you? [10:44] jtv: i'm not sure i see how GetString is better than a cast [10:44] jam: but that'll be fixed once the goose patch lands, right? so it's just a few minutes of breakage [10:45] jtv: i think it would be better to simply return the object as unmarshalled json [10:45] rogpeppe: we still need to think about things like what is an error and what is a panic. [10:45] jam: longish story, bzr push to goose-bot trunk returned AppendRevisionsOnlyViolation error [10:45] rogpeppe: I'll land https://codereview.appspot.com/7299045/ - if you don't mind [10:45] jam: plus manually approving mp didn't trigger tarmac [10:46] jam: or maybe it did, but i couldn't ssh in to the machine to seer the logs [10:46] dimitern: yes sorry, LGTM [10:46] rogpeppe: tyvm [10:46] jtv: in general if you're checking something coming from an external source, it's an error not a panic [10:46] jam: so i ended up merging to trunk locally and pushing that [10:47] rogpeppe: does an impossible cast always panic? [10:47] jtv: no [10:47] Or does it have that weird optional-second-output thing? [10:48] jtv: yup [10:48] wallyworld: so you need to merge your change into trunk ,rather than merging trunk into your changes (that is the AppendRevisionsOnly thing). [10:48] jam: yeah, finally figured that out :-) [10:49] jtv: i'd be happier to see: type Object struct {Data interface{}} and methods on it to retrieve maas-specific things. [10:49] wallyworld: I'm checking the tarmac logs, it seems to think there is a ghost revision in your branch ancestry... thats a bit strange. [10:50] jtv: possibly with Data as an unexported field. [10:50] yeah [10:50] rogpeppe: what kind of maas-specific thing do you mean there? Attributes? Or would this also wrap numbers, arrays etc? [10:50] jtv: the methods that are currently available on MAASObject [10:51] wallyworld: it seems to be complaining about: $ bzr log -r revid:ian.booth@canonical.com-20130204235315-18qtwkohjlb8403u [10:51] "history_db_path" not set for BzrBranch7(file:///D:/dev/go/goose/trunk/) [10:51] 60.1.3 Ian Booth 2013-02-05 [merge] [10:51] Merge trunk [10:51] which doesn't make a lot of sense. maybe something with pushing and then it not completing properly because of ARO ? [10:51] jam: i never had a d:/dev/go/goose/trunk anything [10:51] i don't do windows [10:51] wallyworld: don't worry about the history_db_path part. [10:52] the actual failure is different, I was just logging the rev [10:52] i did pull to my loval copy of trunk and merge that at some point [10:52] wallyworld: it looks like tarmac doesn't do the nice thing and tell you what branch it is trying to merge. [10:53] :( [10:53] i'll have to figure out how to ssh in [10:53] wallyworld: I probably need to add your ssh-keys. juju doesn't default to adding the shared ssh key I set up (I think) [10:54] ok [10:55] rogpeppe: then you're talking about casting your way around everything. One thing that's very important to us is that code's intent be explicit, and especially with this being our first Go project, we don't pick up intent as easily from casts as we do from function names. [10:55] wallyworld: I just added the goose-bot pub key, I'll look for yours next [10:55] I thought there was a simple command to import keys from LP, but I don't remember what it is [10:55] ok [10:55] me either [10:56] wallyworld: your key should be added [10:56] ok, will try and ssh [10:57] jam: ssh_exchange_identification: Connection closed by remote host [10:58] when i tried ssh tarmac@10.55.60.11 [10:58] wallyworld: so it looks like tarmac was trying to land your branch for about 10 minutes before it stopped (but it never posted to Launchpad unfortunately) [10:58] jtv: i really don't see a significant difference between. s, err := o.GetString() and s, ok := o.(string) [10:58] i'm not that familiar with ssh to know inmmediately ehat that error means [10:58] wallyworld: ubuntu@10.55.60.94 [10:58] not sure where you got .11 [10:59] ok, i think i did a nova list [10:59] rogpeppe: that's why I said it's _our_ first Go, not yours! [10:59] and picked a server, can't recall now [10:59] wallyworld: right, instance 0 is the juju state server [10:59] instance 1 is the bot [10:59] which is running as "tarmac" but ssh access is via "ubuntu" [10:59] you can sudo su - tarmac if you need to. [10:59] rogpeppe: We do see a significant difference there. And that may well change, and we're trying to do everything the Go way here, but we do also need to be comfortable with what we're writing. [10:59] jam: ok, i'm in, thanks [11:00] rogpeppe: sorry about missing you comment, here's the fix: https://codereview.appspot.com/7308044 [11:01] dimitern: why the intermediate variable? [11:01] jam: because I need to deref it [11:02] ah, pointer stuff, sure [11:02] jam: btw the usual way worked smoothly :) [11:03] dimitern: yeah,it usually works quite quickly, I'm not sure what the problem was for Ian. It looks like one of his branches on LP wasn't complete. wallyworld did you happen to try to push to lp:goose *before* you pushed up your own branch for review? [11:04] jam: i don't believe so but can't say for 100% sure [11:04] jtv: i'm aware it's your first Go - i'm just trying to gently suggest ways of doing things that are more "go-like". JSONObject seems to be duplicating the go type system without any particular reason (all the information in the maasify'd object is present in the original interface{} value) [11:04] jam: actually I did just that - tried pushing to lp:goose, got bitten and went with what you said in the mail about the bot [11:04] wallyworld: what is weird is that it is claiming it failed to merge goose's trunk, but the revision it is complaining about should have only been in your branch. [11:05] dimitern: you shouldn't have direct commit access to 'lp:goose' to keep us all honest, but I do outline in the email how to get around it. [11:05] hmmm. that is weird [11:05] wallyworld: my guess is it was having trouble with your branch, but giving a bad error message. [11:05] could be. let's see what happens next time i guess [11:06] which *might* have been that your branch tip had a revision, which bzr didn't copy to your branch's local repository, because it was stacked on a repository that already had it. [11:06] (which should work, but tarmac might be trying something special under the covers) [11:06] I know it uses a lightweight checkout for trunk [11:06] rogpeppe: Yes and I appreciate that, but to us there _is_ a real difference between having the caller cast their way around and hiding that detail from them — including an apparent bug in the json package where you don't know if a number is going to be an int or a float64. [11:06] i use lightweight checkouts also [11:06] and using remote lightweight checkouts has had some edge cases in bzr in the past. [11:07] jtv: numbers are always float64 when unmarshalled into an interface{} [11:07] That's what I thought too. [11:07] jtv: unless you've found a counter-example... [11:07] Yeah. :( [11:07] jtv: http://golang.org/pkg/encoding/json/#Unmarshal claims that. Were you unmarshalling into a map? [11:07] jtv: if so, sounds like a bug. have you got something that demos the problem? [11:08] * jtv looks [11:14] jam, rogpeppe: wouldn't you know it — can't reproduce that now. I must have been wrong. [11:14] Yes, I was unmarshaling into a map. [11:14] jtv: my guess is while discovering it, you were probably trying out "what if it is an int" and got an int back. [11:15] Nope. [11:15] Not *consciously*. But I do wonder if somehow I got an int in there that I didn't first serialize. [11:16] Could easily have happened. [11:31] dimitern: care to come join us in mumble? [11:31] jam: sure [11:41] lunchtime [12:32] yay! so nova list server/detail filters support regex matching by name! [12:33] filtering current env's machines will be a breeze [12:35] wallyworld: I use local lightweight checkouts, but not lightweight checkouts of lp: branches. [12:35] dimitern: nice [12:35] ok [12:36] (and remote lightweight checkouts have had some rough edges) [12:36] i can't get by without [12:59] Goood morning all [12:59] niemeyer: hiya [13:00] rogpeppe: Yo! [13:01] weird.. it tells me I cannot join the weekly hangout [13:01] jam: how did you get in? [13:02] dimitern: I just joined [13:02] https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.pjo9s0ubrlo7fudfdu3bkivq34 [13:02] https://plus.google.com/hangouts/_/33acfc2c8af8792568274fa110371db956f9fde7 [13:02] You are not allowed to join this hangout. [13:03] why?! [13:03] dimitern: are you connecting with an @canonical account? [13:03] just a thoguht === TheRealMue is now known as TheMue [13:04] jam: yeah it seemed like that's the issue [13:05] dimitern: I think you can try the last link, and just go directly to the hangout, rather than via the calendar [13:06] yeah, I tried them all, switched to @canonical account ...a few times, no cigar [13:11] i'm switching the account, but somehow the link switches it back to the other (non canonical) one :( [13:11] can somebody invite me or something? [13:50] niemeyer, good morning [13:50] luunch [13:50] niemeyer, i'm trying to debug an issue with the charm store, the landscape-client charm isn't showing up on either the alias or most of the personal addresses [13:51] hazmat: Heya [13:51] i wrote a small go program and verifies that the charm loads correctly, and one of the personal charm branches (out of 4) does appear in the store [13:51] i'm a bit stumped as to causes or how to debug further [13:51] hazmat: Worth asking mthaddon for the logs to see if it's breaking on import [13:52] niemeyer, cool, i'll do that, thanks [13:52] hazmat: np [14:03]