[00:00] SpamapS, the versions vary across the env [00:00] sorry poor naming choice [00:00] versions of juju, but as long as provisioning agent doesn't pass a zk secret.. you just wouldn't have a zk secret, right? [00:00] mixed mode == multiple versions extant in the env [00:00] sure ok I don't care what you call it, I just want it to work :) [00:00] SpamapS, yup.. no otp identity token, nothing to do [00:01] Its the only thing I really think we have to get into 12.04.1 [00:01] everything else we can pull people to PPA I think [00:01] SpamapS, my timeline is bit stretched [00:01] if we merged it now [00:01] would it just break all add-units ? [00:02] SpamapS, its not done, i still need to propogate identities to all the agents [00:02] SpamapS, so with the move to august for 12.04.1 what's the date for last merge [00:02] * SpamapS makes the FAIL face [00:02] you wanted 6 weeks [00:02] oh dude [00:02] I don't care about *actual* 12.04.1 [00:02] June 6 man. I don't want to hold onto trunk like this for 3 months [00:03] If we can't get it in, we can't get it in. [00:03] c'est la vie. [00:03] actually i take that back, there is a branch that does the agent identity thing [00:03] SpamapS, let's just branch then [00:04] SpamapS, you want 9 weeks of no changes ? [00:04] for 12.04.1? [00:04] No stress. I just think, priority wise, thats the only one that really needs to get back to the conservative "hey whats this thing juju" users that will use it from the distro. [00:04] june 6th isn't going to happen, i'm fully booked till june 14th [00:04] hazmat: alright, then we won't ship stuff to those users. [00:04] i'd have to pull a resource to make other stuff move [00:04] or we'll branch a stable branch. [00:05] Don't stress, thats the key. [00:05] It happens, or it doesn't, but no heroic efforts are needed. [00:05] SpamapS, too late.... my post uds bliss has passed [00:05] hazmat: thats why we have deadlines [00:05] so we *don't* have to stress [00:05] immovable deadlines even [00:05] SpamapS, that works when you only have one deadline maybe, but when you have four concurrently, its a bit different [00:05] thats why stuff needs to be done *before* feature freeze [00:06] even in universe/unsupported .. we shouldn't target to go nuts the last week of the cycle. [00:06] hazmat: meh, it still works. You have a deadline, you know how much time you have available for this one project. Its not enough.. resource starvation communicated. No stress. [00:06] ack [00:07] And I can set expectations for the precise-updates version appropriately as well. [00:08] I think instead I'll just try and make an 'unstable' PPA on June 6, and make sure there's some way to get juju-origin to use it. [00:09] then we can just freeze ppa:juju/ppa onto the galapgos release, which I hope we can call 0.5.1, and then just start building trunk into ppa:juju/unstable and let users know they should get on that one if they want the new stuff from honolulu [00:12] SpamapS, so 12.04.1 got moved back a month, why doesn't our deadline move with it? === flaviamissi_ is now known as flaviamissi [00:48] amusing.. https://bugs.launchpad.net/edubuntu/+bug/1000000 [01:03] yes, a nice variant on https://bugs.launchpad.net/ubuntu/+bug/1 [03:52] hazmat: because I want trunk to open up for features [03:59] SpamapS, then let's cut a precise branch, but that should still change june 6th to july 6th [04:01] hazmat: we can just make the precise packaging branch the precise branch :) [04:03] hazmat: in fact, with the Low priority stuff thats been landing in galapagos, I think I may give up on trying to ship "galapagos" into precise-updates [04:06] hazmat: the idea was extreme discipline so we could adhere to SRU policy. That has basically gone out the window. [04:10] SpamapS, i think we have different notions of extreme.. anyways.. the question to me at the moment is what in the current set of revs doesn't meet that notion, we can revert, cut the branch, and reapply to trunk [04:21] hazmat: Well the SRU policy is pretty clear that only high impact bugs will be SRU'd [04:22] hazmat: so, cosmetic fixes are generally rejected, and with the heavy testing requirement, are kind of a waste of time. [04:22] SpamapS, but things aren't tested in isolation? [04:22] hazmat: plus we have to extract each and every one into its own quilt patch so SRU team can review each change. It just becomes a lot of red tape and b.s. for cosmetic fixes. [04:22] SpamapS, this also applies to universe? [04:23] or that thing formerly known as [04:23] hm [04:23] hazmat: yes, the only difference is that with universe, the community is expected to do the fixes (which, since we're juju devs.. we are considered the community) [04:23] amusing [04:23] the policy is identical, just the expectation of response is different. [04:23] SpamapS, so outside of 536, i could probably a valid case for each of the other 4 commits [04:25] SpamapS, also we need the output formating fix that bcsaller is working on wrt to not having python stringification of values [04:25] ie. one more [04:26] hazmat: we also have the problem of not being able to test from -proposed easily. ;) [04:27] yeah.. i got lost in the weeds trying to make local use cloud-image so i didnt have to implement that twice [04:28] lp:~hazmat/juju/proposed-support ;-) [04:29] so many branches [04:29] so little time :) [04:32] hazmat: I'm willing to do all the test verification on even the Low priority bugs .. as long as the SRU team is willing to review the uploads. [04:33] hazmat: I figure if we ship 3 - 5 in an upload every 2 weeks the SRU team should be ok with that. [04:36] SpamapS, any reason not to go ahead and cut the precise branch now [04:38] hazmat: we have.. its at lp:ubuntu/juju [04:38] actually lp:ubuntu/precise/juju ;) [04:38] gotcha [04:38] cool [04:42] hazmat: so I'll just manage the flow of things from lp:juju -> lp:ubuntu/precise/juju :) [04:42] hazmat: and you guys can keep doing trivials as long as they don't cause me any conflicts. :) [06:37] rogpeppe: you in the house ? [07:12] davecheney, heyhey [07:13] davecheney, instance id is not the same as machine id; machine id is juju-internal but instance id is provider-supplied [07:14] davecheney, the providers don't have any reason I'm aware of to know about the details of juju state, so I don't think they should know about instance ids [07:14] davecheney, gaah, providers should not know about *machine* ids [07:15] davecheney, they should deal purely with *instance* ids [07:16] davecheney, the machine state should contain the corresponding instance id which you can use to shut down the machine [09:46] mornin' to anyone who's around... [10:12] hi there. [11:32] Aram: if you don't type my irc alias, i don't see your remark! [11:32] :). [12:32] lunch [13:01] Hello! [13:01] I suspect my Thinkpad's battery has just died on me [13:02] Quick reboot.. [13:09] niemeyer: hiya [13:10] rogpeppe: Heya [13:10] Looks like battery is no more indeed [13:10] niemeyer: bummer [13:12] niemeyer: about List: i've gone with directories, but said that it should return the entire (recursive) contents of the directory. that means you can find out the entire contents of a bucket without explicitly recurring. [13:13] rogpeppe: Ok [13:14] rogpeppe: Where do I get a replacement bat in the UK? [13:14] niemeyer: also, you said you had a couple of suggestions around that paste. do you remember another? [13:14] niemeyer: in the UK i'd order it on the internet [13:14] niemeyer: why UK? [13:15] rogpeppe: ROTFL.. *really*!? You'd use the *internet*! [13:15] :-) [13:15] niemeyer: i can't be more specific - i'd froogle it. [13:15] rogpeppe: Yeah, got it.. I just had a good laugh :) [13:15] rogpeppe: I may be going there in a couple of weeks [13:15] niemeyer: cool. whereabouts? [13:16] rogpeppe: London [13:17] rogpeppe: There's a sprint being planned and I was invited to help out as possible [13:17] niemeyer: would it be helpful if i sourced a battery for you? [13:18] rogpeppe: Not sure.. if I can find a good spot to buy it, I might just send it to the office. [13:18] rogpeppe: I'd appreciate your help in case the place doesn't take international credit cards, though [13:18] niemeyer: sounds like a good plan. that also sounds like a possibility. [13:19] rogpeppe: I'll have a look later at Amazon UK to see if I can find anything [13:19] niemeyer: usually they do, but you might find the exchange rate isn't great. [13:19] For now, just put my battery in the fridge for it to relax for a moment [13:19] rogpeppe: The exchange rate with credit cards is controlled by the government.. they're forced to use the official rates [13:19] chill out that battery man [13:20] rogpeppe: I'll just have to pay 6% extra of tax, unfortunately [13:20] niemeyer: really? i never knew that. [13:20] niemeyer: on top of our 20% VAT? [13:20] rogpeppe: Yeah.. financial operations tax in Brazil [13:20] rogpeppe: To discourage people from buying stuff abroad, is my guess [13:20] rogpeppe: Silly [13:21] niemeyer: sounds like you *do* want me to buy it for you :-) [13:21] rogpeppe: Hehe, thanks, but don't worry for now.. [13:21] niemeyer: just let me know if you need it [13:22] This is the second time this happens to me, btw [13:22] Last Thinkpad I had, the exact same happened [13:22] Looks like Lenovo has issues with batteries [13:23] what model is this thinkpad? [13:41] Aram: T410 [13:41] I have one as well. [13:42] curious that you had problems, I never had battery problems with any thinkpad. [13:43] had a lot of problems with dells and hps though [13:52] Aram: It's the second time [13:52] Aram: Last one died in the same way [13:52] strange. [13:52] Aram: Maybe I use it too much? :) [14:07] rogpeppe: My current battery costs £164.16 at Lenovo (!!) [14:07] niemeyer: yeah, they're way expensive. [14:07] niemeyer: i was looking at getting a spare recently. [14:07] It's almost the price of a whole laptop these days [14:07] niemeyer: you can get an OEM battery [14:07] niemeyer: but who knows how good it'll be... [14:09] Oh, found the same one on Amazon uk for £84.56 [14:10] niemeyer: that's cool. link? [14:10] I wonder how long it's been in stock though.. that's always an issue with batteries [14:10] rogpeppe: http://www.amazon.co.uk/Lenovo-ThinkPad-Battery-55-battery/dp/B003FXQ3ZK/ref=sr_1_1?ie=UTF8&qid=1337177298&sr=8-1 [14:11] niemeyer: given that they're the cheapest supplier, maybe they'll be clearing stock quickly... [14:12] niemeyer: interesting to see how much of a markup lenovo direct has though. [14:13] rogpeppe: Yeah.. even if the cheap one lasts half as long, it's still ok :) [14:21] niemeyer: some bizarre behaviour from gnu tar: http://paste.ubuntu.com/990736/ [14:22] Reading [14:22] niemeyer: i can work around it with tar xzf /dev/fd/0, but.... [14:22] rogpeppe: Weird indeed [14:23] niemeyer: ah! i've found the problem. [14:23] rogpeppe: Oh? [14:23] niemeyer: i had a bogus version of tar in my path [14:25] niemeyer: it's a pity our tests will fail if someone has an odd environment. but i don't want to hard-code /usr/bin/tar ... [14:25] pwd [14:37] rogpeppe: Yeah, this is fine IMO [14:38] rogpeppe: All kinds of crazy things can happen if you has a buggy env [14:38] s/you/one [14:38] rogpeppe: Btw, the battery death reminded me that I started the mgo zk in the trip to Brazil [14:38] rogpeppe: Looking really nice so far [14:38] niemeyer: it's a bit weird really, because one of the original advantages of unix is that you can customise your commands. [14:39] rogpeppe: Next time I have a moment I'll start on watches [14:39] niemeyer: cool. have you proof-of-concept-ed the watchers? [14:39] oh, ok [14:39] rogpeppe: Not yet, but I have a pretty good idea about how to implement them now [14:39] rogpeppe: I started the research on the trip [14:39] rogpeppe: It's quite racy, so has to be carefully thought out [14:40] niemeyer: yeah. it's a critical component. [14:40] rogpeppe: I'm planning to use the internal replication mechanism to do it.. I *think* it'll end up quite nice [14:40] maybe we should do like the web guys that try to detect browser capability and serve custom pages depending on that, that way we could support user customized environments :P. [14:40] * Aram hides. [14:40] niemeyer: it'll be interesting to see how the benchmarks (network bandwidth & latency particularly) work out [14:41] rogpeppe: Quite optimistic on that regard [14:41] Aram: ./configure :-) [14:41] rogpeppe: Don't be silly.. we should start with autoconf.sh [14:41] niemeyer: good to hear [14:41] niemeyer: of course! [14:42] not [14:42] :-) [14:42] autoconf.sh => configure => make.. it's crazy how people end up finding that normal [14:42] the whole notion of probing a system to find out what kind of thing it is is bogus [14:43] yeah, that worked so well for cross compiling :). [14:43] tbh, i wouldn't mind setting PATH=/bin:/usr/bin [14:43] that's what I do most of the time in my scripts. [14:44] Aram: it's a reasonably sane approach. [14:51] niemeyer: question: do you think List should return the full path names of the files, or the pathnames with the dir prefix stripped off? [14:52] niemeyer: i'm starting to question how much effort i want to put in to make S3 buckets look like directories. [14:52] niemeyer: maybe we *should* just use a prefix model [14:53] rogpeppe: I'm happy with that too [14:53] niemeyer: i think i'll go with that for the time being as the path of least resistance. [14:53] rogpeppe: Full path names sounds simpler [14:54] niemeyer: then we don't have to worry about the impedance mismatch. and we can revisit the decision later if we need to. [14:54] rogpeppe: Yeah [14:55] rogpeppe: Btw, I'm thinking we'll end up having some kind of manifest file for the generic HTTP public provider [14:55] rogpeppe: This will also make that simpler [14:55] niemeyer: no need to use the Separator stuff either. [14:55] rogpeppe: Definitely [14:56] niemeyer: the manifest file should be auto-generated, otherwise we've got a problem with two clients uploading tools concurrently. [15:00] rogpeppe: This is about the public storage [15:01] rogpeppe: For the private storage we should be able to list our stuff [15:01] rogpeppe: Which will be guaranteed, given we're hopefully moving towards a internal storage mechanism [15:01] niemeyer: ok, that seems reasonable. the interface can be the same in both cases (StorageReader) [15:02] rogpeppe: RIght [15:02] * rogpeppe quite likes the StorageReader/StorageWriter distinction. [15:02] rogpeppe: Btw, I was going to suggest this before my ISP broke yesterday: StorageReadWriter may be spelled as Storage only [15:02] rogpeppe: StorageReader, StorageWriter, and Storage [15:02] niemeyer: that works [15:02] +1 [15:02] Supa' [15:02] :) [15:04] Ok, it's lunch time here [15:04] Back soon.. reviews on the afternoon today [15:09] niemeyer: enjoy [16:01] niemeyer: why does your battery stats indicate 0 for the cycle count? [16:02] s/does/do/ [16:08] Aram: Probably side effect of death [16:12] niemeyer: https://codereview.appspot.com/6145043 [16:13] niemeyer: slightly worried that the branch is too big now and i'll need to spend some more hours splitting it up... :-| [16:56] niemeyer: i'm going to have to go soon [16:59] rogpeppe: I'll have a careful look [17:15] niemeyer: just replied to https://codereview.appspot.com/6215045/ . it would probably be good to have a chat about this tomorrow. [17:16] rogpeppe: Sure [17:17] rogpeppe: There's a leap in your description that I can't follow [17:17] rogpeppe: "by making Environ.Check operate directly on a map[string]interface{}, we make that possible." [17:17] rogpeppe: Nothing has to change in the way CheckConfig works to make that possible [17:27] niemeyer: how do we merge the attributes generated when marshalling an environment with the other attributes held in the environment settings node? [17:27] niemeyer: (i don't have to go immediately, BTW) [17:32] * rogpeppe is trying to recall all the discussion points that came up with fwereade and dfc at the time. [17:33] rogpeppe: Hm [17:33] rogpeppe: I don't understand hte problem [17:33] rogpeppe: Check isn't about merging [17:33] rogpeppe: ConfigCheck is about validation and coercion [17:33] niemeyer: Check has to parse the attributes that are created with Marshal (or whatever it would be called) [17:34] niemeyer: so it helps if the two things read and write the same structure [17:35] rogpeppe: That's fine.. there's still no reason to change the function signature [17:35] niemeyer: i don't see how it can work. what if Marshal returns a single int? [17:36] rogpeppe: I still don't get what problem you're trying to solve, sorry.. ConfigCheck returns a schema checker, which checks the schema by validating and coercing to the proper types in case it is valid [17:36] rogpeppe: What is Marshal? [17:37] rogpeppe: What problem are we trying to solve? [17:37] niemeyer: ok, so... [17:37] niemeyer: when we bootstrap, we need to ask the environment to save some of itself to the State. [17:37] niemeyer: or at least that needs to happen at some point [17:37] Yep [17:38] I'm with you [17:38] niemeyer: so the question is: how does that happen? and once we've got the settings inside the State, how do we create an Environ from them? [17:39] rogpeppe: We create an environment by retrieving the ConfigNode for the environment configuration, and providing the Map() onto a new environment via Open. [17:39] rogpeppe: Another Option is to provide the ConfigNode itself onto Open, and change Open's signature to take a Getter, for example. [17:40] rogpeppe: Neither of those options require any changes to ConfigChecker [17:40] niemeyer: that doesn't work - Open expects a nicely formatted structure that has been produced through Check. [17:40] rogpeppe: No, it doesn't.. there's no Check today, and neither of us mentioned anything about it so far [17:40] niemeyer: ok, i'm proposing to rename Coerce to Check. [17:40] rogpeppe: Yes, I can see *that* :-) [17:40] rogpeppe: But you didn't mention why, and I can't see any reason to [17:41] niemeyer: but the point is: all the preconditions are checked there. if we start passing attributes directly to Open, then the checks will have to go there too. [17:41] rogpeppe: One thing isn't related to the other in any way.. [17:42] rogpeppe: If you pass a Getter into Open, there's no guarantee it's right either [17:42] niemeyer: i wasn't proposing to pass a Getter into Open [17:42] niemeyer: i was proposing to pass a Getter into *Check* [17:42] rogpeppe: Yeah, you're proposing something else, and I'm trying to guess why [17:42] niemeyer: then Check can do all the checks it does right now. [17:42] rogpeppe: Yes, you were proposing that, but you didn't say why, and I can't see any reason to do that in the explanation above [17:43] rogpeppe: We seem to be a bit stuck on the lack of reasoning around htat [17:43] niemeyer: it depends if you think the current division of labour works well or not [17:43] rogpeppe: It works very well today, and nothing I can see above seems to change that [17:43] niemeyer: currently the Coerce method checks that all the fields are there and have sane values [17:44] niemeyer: if we start passing unchecked values to Open, then that checking will have to move into Open. [17:44] rogpeppe: The values we pass today onto Open are checked. Renaming a method doesn't solve anything. [17:44] [18:39:22] rogpeppe: We create an environment by retrieving the ConfigNode for the environment configuration, and providing the Map() onto a new environment via Open. [17:44] rogpeppe: Yes!? [17:45] niemeyer: so in that case, where is the checking done? [17:45] rogpeppe: I *really* hope we're not saving an invalid configuration onto the state!? [17:45] niemeyer: who knows? we need to check it. [17:45] rogpeppe: No, sorry.. this is a broken design [17:46] niemeyer: also, currently Check saves everything into a nice private structure. [17:46] rogpeppe: If you want to valid the state, it should be on its way in, not on its way out [17:46] niemeyer: state is external. [17:46] niemeyer: we might have got the version checking wrong [17:46] niemeyer: we don't want to do unchecked type conversions. [17:47] rogpeppe: Besides that, validating the state would mean passing the result of Map() onto exactly the same validation & coercion function [17:47] rogpeppe: Which goes back onto the point that there's unjustified fuzz around that method [17:47] niemeyer: i don't find it fuzzy. the Coerce and Open methods have a close relationship, but it's well defined. [17:48] rogpeppe: Yep. It's well define, works, and it's all good. You're suggesting we change the method name and signature and introduce an interface, because...? I don't know. [17:48] niemeyer: i'm proposing passing the ConfigNode, in some form, to Coerce. [17:48] rogpeppe: Because...? [17:49] niemeyer: so that Coerce can do exactly the same checking that it does when it gets stuff from environments.yaml [17:49] niemeyer: with no code needing to be changed. [17:49] rogpeppe: ConfigCheck can do exactly that, today, with no changes to its signature, and no new interfaces. [17:51] niemeyer: ConfigCheck? [17:51] niemeyer: ConfigChecker, oh yes [17:52] niemeyer: so what happens the other way around? [17:52] niemeyer: i.e. how do we do the marshalling? [17:52] rogpeppe: the other way around we return.. :-) [17:53] niemeyer: do we require that Marshal always return a map[string]interface{} ? [17:53] rogpeppe: env.Config() map[string]interface{} seems easy enough [17:54] niemeyer: ok, so if we return map[string]interface{}, can't we guarantee that Coerce is called with that same type? [17:54] niemeyer: and reflect that in the type signature [17:54] rogpeppe: That sounds fine to me.. I believe it's already called with that type today, right? [17:54] rogpeppe: We just don't enforce it by passing it via an interface{} [17:55] rogpeppe: But we could, and it sounds sane to do it [17:55] niemeyer: to change the type signature? [17:55] rogpeppe: To be explicit that what we're passing in today is a map.. it's already a map [17:56] niemeyer: explicit to the compiler, or just to document it? [17:56] rogpeppe: Explicit to the compiler.. [17:57] niemeyer: ok. so... what we've ended up with there is *almost* the same as what i was proposing. [17:57] niemeyer: the only difference being that if we use Getter and Setter we can pass in the ConfigNode directly. [17:57] rogpeppe: That's my point the whole time.. you're proposing a change that isn't necessary, because what we have already works [17:59] niemeyer: fair enough. it saves some code doing to map copying, but we can use map[string]interface{} throughout if we like. [17:59] s/doing to/doing the/ [17:59] rogpeppe: I don't think it saves any code.. the current scheme needs *less* code, actually [17:59] niemeyer: (what's being passed to Coerce currently isn't actually map[string]interface{} BTW) [17:59] rogpeppe: Because we work natively with maps on both ends [17:59] niemeyer: really? [18:00] niemeyer: one side we've got map[interface{}]interface{}; the other we've got *ConfigNode [18:00] (which already has Get and Set methods) [18:00] rogpeppe: What's below ConfigNode? [18:01] rogpeppe: What does ConfigNode.Map return? [18:01] rogpeppe: It's a map on both ends, really [18:01] rogpeppe: The fact it's a map[interface{}] is also irrelevant.. we'll never have non-strings on that first level [18:02] 1: WOAH!? [18:02] niemeyer: it's not type-compatible with map[string], so we'll have to copy it to pass it in [18:02] :) [18:02] rogpeppe: Why can't we just have map[string]? [18:02] niemeyer: because that's not what goyaml.Unmarshal returns.... or maybe we could make it... [18:02] rogpeppe: Coerce.. [18:02] * rogpeppe has a look [18:04] niemeyer: maybe ReadEnvironsBytes could unmarshal into map[string]map[string]interface{} [18:04] rogpeppe: Coerce is what has to manage it [18:04] niemeyer: not necessarily, i think [18:05] * niemeyer waits for the light bulb to show up [18:05] niemeyer: the problem currently is that ReadEnvironsBytes produces a map[interface{}]interface{} which is then passed to Coerce [18:06] niemeyer: but i *think* we can unmarshal into map[string]interface{} at the top level and save the Coerce checking [18:06] niemeyer: (of course Coerce would still need to check other things, but we could make its signature map[string] and avoid the map copying. [18:06] ) [18:07] rogpeppe: We can't.. [18:07] niemeyer: oh. no? [18:07] rogpeppe: Coerce validates the values, and transforms them onto expected types [18:07] niemeyer: go on [18:07] That's it.. [18:08] niemeyer: what if the signature of Coerce was Coerce(map[string]interface{}) (interface{}, error) ? [18:08] rogpeppe: It would still not help.. coerce coerces [18:08] niemeyer: i.e. that Coerce took the exact output of Marshal as input [18:08] niemeyer: that's fine. [18:08] Ok then :) [18:08] I'll stop arguing and let you read the code [18:09] niemeyer: ok, so i'm ok with using map[string]interface{} throughout rather than Getter/Setter, i think. [18:10] rogpeppe: Sounds great, thanks [18:12] niemeyer: hmm, might not work very well with the schema package, which uses map[interface{}]interface{} throughout. [18:12] I see a light bulb starting to show up :-) [18:14] niemeyer: i'm not convinced we gain much from using the schema package tbh [18:14] rogpeppe: Let's not throw the baby out with the bath please.. we have to walk forward [18:14] niemeyer: it's higher-order code, but just a few type checks would be equivalent. [18:15] rogpeppe: There's zero reason to do by hand what the schema package does elegantly [18:15] rogpeppe: It's ready, works [18:15] rogpeppe: I believe FieldMap can return a map[string]interface{}, though [18:15] niemeyer: nope. [18:15] rogpeppe: FieldMap is supposed to work with strings already.. we can enforce it in its return value I believe [18:15] niemeyer: hence my v.(schema.MapType) conversion [18:16] rogpeppe: Don't know what you mean [18:16] niemeyer: in fieldMapC.Coerce: out := make(MapType, l) [18:17] rogpeppe: can != does today [18:17] niemeyer: that would make for a very different schema package. (one that i'd like to see, i agree, but not the one we have today, which outputs a small set of known types, rather than coercing to a specified type) [18:18] rogpeppe: Do you want me to code on that *very* different schema package? [18:18] rogpeppe: I bet the patch is less than 10 lines long [18:18] niemeyer: all we're using schema for currently is the equivalent of: x, ok := m["field"].(string) [18:18] rogpeppe: and consists of removals [18:18] and a couple of replacements [18:19] niemeyer: really? [18:19] * niemeyer writes it [18:20] niemeyer: but still, we've got all this higher-order machinery, but we're not using any of it in any particularly useful way. [18:20] rogpeppe: We are, it works, today, let's *please* move on! [18:20] rogpeppe: I really don't want to be moving backwards and doing checks by hand when we have that nice mechanism in place already [18:21] niemeyer: it's because it was making it awkward that i was considering avoiding its use. changing its use is about 10 minutes work. [18:21] rogpeppe: I don't want to be checking whether it's int32 or int64 [18:21] rogpeppe: Or whether it's something else entirely [18:21] niemeyer: will we actually have any int-valued keys? [18:21] values i mean [18:22] rogpeppe: No, it's impossible.. [18:22] :-/ [18:22] niemeyer: i mean, are there any int values that we actually *want*? [18:23] niemeyer: because that's the only time that int32 vs int64 makes a difference. [18:23] rogpeppe: Please try to ponder about your question for a moment [18:23] rogpeppe: This is getting non-productive [19:02] niemeyer: this is the kind of thing i was thinking of. i think it compares favourably to the current code. it actually reduces the overall line count (by 30 lines) and easier to understand IMHO, because you don't need to understand how schema works to follow the logic. i'll leave things as they are, but i think ewe should at least consider this possibility. [19:02] http://paste.ubuntu.com/991155/ [19:03] all tests pass BTW [19:03] s/ewe/we/ [19:05] right, i really should go now. [19:05] rogpeppe: How does it reduce the line count? Seems to have the same number of lines [19:05] niemeyer: sorry for the distraction [19:05] niemeyer: the line count goes down in other places (the schema helpers in ec2/util.go for example) [19:07] rogpeppe: The errors are bogus, though [19:07] niemeyer: it could be more compact with a little table [19:07] rogpeppe: That's one important benefit from the schema package [19:08] niemeyer: as always, i think it's a trade-off. the higher order stuff is worth it when it really makes things easier to understand and reduces the line count by lots. [19:08] niemeyer: in this case, i'm not convinced of its worth. [19:08] rogpeppe: It think it's worth based on these factors [19:08] s/worth/worse/ ? [19:09]