[09:35] hi rogpeppe: I am fixing the branch, and I was thinking about the AuthName method you suggested. [09:35] frankban: ok [09:35] rogpeppe: especially in relation to bug 1156715 [09:35] <_mup_> Bug #1156715: Replace EntityName() with something else.

< https://launchpad.net/bugs/1156715 > [09:36] frankban: was it william's suggestion to report that bug? [09:36] (out of interest) [09:36] rogpeppe: if we are going to replace EntityName with something better (e.g. GlobalName, APIName, ExternalName...), maybe it's worth making that change contextually [09:37] frankban: i'm not sure [09:37] rogpeppe: I proposed to work on that once the annotations stuff is ready. IIRC, he suggested to find a better name for that method [09:41] frankban: the problem is that now we've got two methods now: State.Entity and State.Authenticator, and we can't just assume that the names are the same for each [09:42] frankban: ah, we've lost State.Entity, i see [09:42] rogpeppe: you mean State.Annotator and State.Authenticator [09:42] frankban: yeah [09:43] frankban: the problem is that the same "get name" method isn't necessarily appropriate for both [09:44] fwereade: what are your thoughts here? [09:45] fwereade: i'm suggesting that entities that can be returned from State.Authenticator have an AuthName method; and (if needed) entities that can be returned by State.Annotator have an AnnotatorName method. both methods would simply return the entity name as it is currently. i *think* this is what you might have suggested before. [09:46] rogpeppe, +1 [09:47] rogpeppe, I think it's better to have the two clear names for the two distinct contexts -- they can still directly share an implementation [09:49] rogpeppe, fwereade: ok. in this branch the AnnotatorName is not defined or required. We just include the EntityName() method in ad-hoc interfaced for tests. No problem in introducing an AuthName for authenticators, and no problem in closing that bug as invalid or wontfix. Sound good? [09:50] frankban, I'd like to be consistent across Auth and Annotate, and ideally to drop the string EntityName across the board, but I'm not sure if that's a reasonable request in this context [09:51] frankban, are there lots of clients using EntityName that aren't clearly asking in either an auth or an annotate context? [09:53] fwereade: I'd have to take a look, I don't think so, I guess EntityName is only used in the API context, and in the API we just have annotators and authenticators. Maybe rogpeppe can confirm. [09:54] fwereade, frankban: actually EntityName is used in other contexts too [09:54] frankban, hmm, I think it might be too big [09:55] fwereade: in particular, it's used in the original way that it was created (to talk about a state entity in general, that might be a unit or a machine) [09:55] frankban, rogpeppe: I think that if we're adding AuthName, though, I rather feel we should fix the instances of EntityName that are really AuthNames [09:55] fwereade: sure [09:56] rogpeppe, I may be changing my mind here [09:56] * rogpeppe still thinks that a single EntityName method makes sense (and saves us code) [09:57] rogpeppe, I think your motivation is sane but the name "EntityName" is not helpful [09:58] rogpeppe, can we reconsider the list of possibly-sane alternatives? [09:58] fwereade: ok [09:58] fwereade, rogpeppe: so, bug 1156715 is still valid [09:58] <_mup_> Bug #1156715: Replace EntityName() with something else.

< https://launchpad.net/bugs/1156715 > [09:58] rogpeppe, I am feeling a gentle pull towards GlobalName but this opinion is not held strongly [09:59] fwereade: i don't like GlobalName because it's not global - it's only "global" with respect to a given state. [09:59] fwereade: and in the future it's quite possible we might have *real* global (including uuid) names [10:03] fwereade: how about ExtName ? [10:03] rogpeppe, true; hmm. LongName? :) [10:04] fwereade: it's not too long, and abstract enough that it doesn't have any significant unwanted connotations [10:04] fwereade: TaggedName ? [10:04] rogpeppe, I could live with that :) [10:05] fwereade: not that keen on LongName, i don't think [10:05] nor on TaggedName really [10:05] rogpeppe, fair enough, but ExtName is too unclear IMO [10:06] rogpeppe, Nametag() :) [10:06] fwereade: it's only unclear if it's documented unclearly IMHO [10:06] fwereade: Tag() :-) [10:06] rogpeppe, hum, yeah, that's not bad, is it? [10:07] State.Authenticator(tag string) (Authenticator, error) [10:07] rogpeppe, we'll want to fix a couple of things like DeployerName to DeployerTag but I think it works nicely [10:08] fwereade: yeah, i could live with that [10:08] type Tagger interface {Tag() string} [10:08] rogpeppe, that SGTM, if you can live with it [10:09] fwereade, rogpeppe: so, should the Tagger interface be embedded in Authenticator and Annotator? [10:09] frankban, yeah, it seems sensible I think [10:09] frankban: i don't think so, otherwise you won't be able to do interface { Authenticator; Annotator } [10:10] rogpeppe, oh, blast [10:10] rogpeppe, well [10:10] rogpeppe: so TaggedAuthenticator, TaggedAnnotator? [10:10] fwereade: but i have no problem with type TaggedAnnotator interface { Tagger; Annotator} [10:10] rogpeppe, how often do we want both features in play at the same time? [10:10] fwereade: i don't want to preclude i [10:10] t [10:11] frankban, rogpeppe: ok, fair enough [10:11] fwereade: in general, other than at leaf level, you want either all-embedded or all-method interface types, i think. [10:12] rogpeppe, yeah, sounds sane, ++composability [10:12] fwereade: exactly [10:12] rogpeppe: i.e. in the API layer, we will always use Tagged(Authenticator|Annotator) [10:12] ? [10:12] frankban: yes, and i think that the State.Authenticator should return TaggedAuthenticator [10:13] rogpeppe: cool [10:13] rogpeppe: and the same for State.Annotator i guess [10:13] frankban: yup [10:15] rogpeppe, fwereade: what do you think about: 1) I land my current branch as is, with minor fixes (it's well over 1000 lines of diff) 2) I change that bug to be this Tag() and Tagger refactoring 3) I start working on that new bug, also replacing all the NamedAuthenticators and Annotators used in tests [10:16] frankban, +1 [10:16] frankban: i think that's a reasonable approach, except i'd like to see the entityName field go [10:17] frankban: and i think that's an easier fix than making the code access it safely. [10:17] frankban: (so it would use EntityName as i suggested in the review) [10:18] frankban: and then it would change to use Tag in the later branch [10:18] rogpeppe: you mean in apiserver.go? so do you want me to temporarily add the EntityName to the Authenticator interface> [10:18] frankban: i think that would be fine [10:18] rogpeppe, fwereade: thanks, I think we have a plan. [10:19] frankban: wonderful [10:22] frankban, sgtm [10:51] rogpeppe: could you confirm those notes are correct? https://bugs.launchpad.net/juju-gui/+bug/1156715/comments/1 [10:51] <_mup_> Bug #1156715: Replace EntityName() with something else.

< https://launchpad.net/bugs/1156715 > [10:53] frankban: yup, seems good. there are other knock on effects of changing EntityName - various places use it and will need to change [10:59] rogpeppe: isn't enough s/EntityName/Tag for these cases? [11:00] frankban: more or less - there are some variable and field names that will want renaming too [11:00] rogpeppe: maybe we'll need to take care of this case by case, with your help [11:01] frankban: it should be fairly obvious, i hope - recursive grep -i entityname, and fix [11:02] rogpeppe: sounds good [11:19] rogpeppe: reproposed, would you like to take another look? [11:19] frankban: will do [11:21] thanks === teknico__ is now known as teknico [12:32] guihelp: in go, what is the relationship between packages and directories? in apiserver there is "package apiserver" and "package apiserver_test" and that is a-ok. if i add another package in that directory it complains. anyone here know? [12:33] I thought there was no connection, so obviously I'm no help [12:33] gah, my stupid nick === BradCrittenden is now known as bac === bcsaller__ is now known as bcsaller === teknico_ is now known as teknico [12:39] bac, if your adding another test i suggest reusing apiserver_test [12:42] in general my understand is that its 1 to 1 directory containing src to pkg with dirname == pkg at least by convention, and that splitting out tests basically allows for stripping it from the binary and is specially handled by the test runner conventions. [12:47] hazmat: i understand all of that from a hygiene perspective. i'm trying to understand the rules. it clearly isn't 1:1 so i'm confused why i cannot create a separate package, even if it is a bad idea. [12:48] bac i think _test is handled distinctly [12:48] by the same convention that _test.go is [12:48] ok [12:50] but that's guess work on my part.. [13:03] teknico: did you run go test in your recent branch before submitting? [13:04] teknico: because it broke trunk and i'm can't see how the tests could ever have passed... :-) [13:04] rogpeppe, any comments on bac's question above re package naming [13:05] hatch: what sort of thing should i be looking for if tests pass under test-debug but fail under test-prod in the beforeAll with an apparent dependencies problem? [13:05] e.g. "extend failed; check dependencies." [13:05] i can't find anything missing in a requires, nor in the yui.use [13:05] bac: hazmat is right. there can only be x and x_test in a given directory [13:05] jcsackett: make sure you've pulled from trunk recently. [13:05] rogpeppe, I did run tests, and I plead guilty of insufficient scrutiny, because I did see failures that I interpreted as intermittent and unrelated [13:07] rick_h_: just merged, no difference. [13:07] rogpeppe, what's the overall tests status? are all of them supposed to pass all of the time, currently? [13:07] jcsackett: make sure you make clean-all and rebuild as well. I guess it was a problem fixed on monday. [13:07] teknico: yes [13:08] jcsackett: and verify that tests pass on trunk if they still fail [13:08] teknico: but with your branch as submitted, it cannot have passed the tests even once :-) [13:08] the age-old story of untrusted tests; this is one of the reasons that tests need to be absolutely rock-solid [13:08] jcsackett: I had a mess around tests like this yesterday I was going to bring up the on the stand up [13:08] teknico: if you see a test failure, we want to know about it! [13:08] thanks rogpeppe [13:09] rogpeppe, right, I will make a point to let you know :-) [13:09] (not about the failures in my code, though ;-) ) [13:10] or rather, in my changes [13:10] teknico: BTW ISTM that both opClientAddRelation and opClientDestroyRelation are bogus, because neither of them undo the operation that they've performed. [13:10] rogpeppe, uhm. bac might be interested too ^^ [13:10] teknico: i'm not sure when DestroyRelation came in. i should've been reviewing more branches, sorry! [13:11] rogpeppe, very recently too [13:11] rogpeppe: oopsie [13:11] rogpeppe: that one had lots of eyes on it. sorry you didn't get a chance to weigh in and catch that omission [13:12] it'll teach me landing changes right before lunch, ttyl :-) [13:12] bac, teknico: in general, the func return from the op* functions is to reset the state back to the original. so if you make a successful change, you need to return a function to undo that change. [13:13] i know it's awkward, and it would be nicer just to reset the whole thing each time, but unfortunately that's prohibitively slow. [13:13] rogpeppe, ISTR you mentioning that most op* functions could go away anyway [13:13] rick_h_: ok, i'll deal with email till standup. [13:13] teknico: i discussed it with fwereade_ and he reckoned that it was worthwhile keeping them in [13:14] rogpeppe, good to know, thanks [14:00] jcsackett: get the problem fixed? [14:00] hatch: not yet. i'm double checking that the right modules are in my require [14:05] ok what you want to do is `make clean-all` `sh test-server.sh prod true` [14:05] then if you have dependency issues they will show up right away in those tests [14:07] frankban am I supposed to know what your email is about? Or did you sent it to the wrong person? :) [14:08] hatch: what email? [14:08] William and Roger agreed on using Tag(). .... [14:09] hatch: that's a comment on a bug [14:09] odd...it just came through as an email from you [14:09] heh [14:09] ok no problem :D [14:11] bcsaller: did you end up checking out my branch last night? [14:12] hatch: I did, but I haven't written anything up [14:12] oh ok - well we can chat in a hangout to save you the typing if you like [14:14] hatch: the way you assign _nsRouter to juju isn't how we typically do things though, you'd pass that down as an attribute. Its ok to attach constructors to the namespaces but usually not instances [14:14] Yeah I didn't like that either but that fn is being used in so many places that it's quite a lot of passing around for a single fn [14:15] I was almost thinking that we need a Y.juju.utils object [14:16] rick_h_: you see anything this file is missing for its require? http://bazaar.launchpad.net/~jcsackett/juju-gui/tab-widget/view/head:/app/widgets/tabview.js [14:16] rick_h_: this is the testfile, as well: http://bazaar.launchpad.net/~jcsackett/juju-gui/tab-widget/view/head:/test/test_tabview.js === frankban_ is now known as frankban [14:17] jcsackett: does it actually say 'verrify dependencies' ? [14:17] hatch: Error: extend failed, verify dependencies [14:17] it's dying in the before() method in my test. [14:17] ok that means the Y.Base failed because it can't extend Y.Tab [14:17] Y.Base.create [14:18] there is no 'tab' module [14:18] hatch: i can't find any docs of where Y.Tab is defined--that's based on one blogpost i found about extending tab. [14:18] what should i include? [14:19] hmmmmmm [14:19] cause i can't find anything; it would be nice if TabView had a require, but alas. [14:20] ok I'm just getting to the tabview source [14:24] you need base-build and tabview [14:24] hatch: nope, same problem. [14:25] hehe _callbackMaybe 'call me maybe' ;) [14:26] hatch: that wasn't intentional, but once i realized the joke i became fond of the method. :-P [14:26] ok and does this happen only in the tests? [14:26] haha [14:28] jujugui call in 2 [14:29] hatch: i only get this in test-prod [14:29] * benji struggles with the Google Talk plugin again. [14:30] * benji gives up and just reboots. [14:31] ohh - whatabout make clean-all; make prod; ? [14:32] rick_h_ starting without you [14:32] gary_poster: k, sec [14:40] jcsackett: the reason I'm hoping it happens with make prod is because then you can test to see if Y.Tab and Y.TabView are defined at the top of your closure [14:45] hatch: i'm not seeing anything. that could be because the tabview's not wired into anything else though. [14:45] hmm this sounds very odd [14:48] hatch: do you have that nodejs bug handy from the npm issues? [14:50] hatch: nvm, found it [14:58] I tweeted it [14:58] oh ok [15:01] hatch: could Y.Tab simply not be exposed in a way that it can be extended? [15:01] https://github.com/yui/yui3/blob/master/build/tabview/tabview-debug.js [15:01] there is the source [15:01] you'll see that it's exposed on Y.Tab [15:01] well, i suppose if that were the case my tests would die in test-debug as well. [15:01] ok here is what you can do [15:02] remove your tabview code from the app, open up the network tab in debug mode and look to see what files are being requested from yahooapis.com [15:02] then add it back in, and compare [15:02] our yui dep script doesn't catch all deps I've found [15:02] hatch: not sure what you mean by "open up the network tab in debug mode" [15:03] network tab in chrome = app built with make devel [15:03] s/=/0 [15:03] blah [15:03] I can't type [15:03] s/=/- [15:03] :) [15:03] basically you want to see if it's pulling in extra modules from yahooapis.com which it can't do under make prod [15:03] ah, ok. [15:04] FYI it pulls in some right now so you will need to compare [15:04] that will work even though tabview isn't wired in, so opening the app doesn't create any tabviews? [15:04] if it's in the 'use' then it'll pull in the code [15:09] I'm also assuming that you have linted this code :) [15:10] juuuuuuust to be sure ;) [15:10] hatch: yeah. [15:11] jcsackett: is the latest pushed? [15:11] rick_h_: yes. [15:11] I'll pull it down and try it out here localy [15:15] jcsackett: so all tests pass for me. test-server and test-prod [15:15] ... [15:15] well, wtf. [15:16] http://paste.mitechie.com/show/908/ [15:16] ^^ is from test-prod [15:16] ima kill my branch and check it out again. [15:16] jcsackett: yea, I just grabbed trunk, created a branch, merged yours in, and make test-prod [15:17] lol [15:17] man I hate it when that happens [15:20] this is maddening. [15:20] a completely clean checkout of mine fails. [15:20] evidently only on my machien. [15:20] *machine [15:21] welp, that's it. time to burn my computers and turn to a life of goatherding. [15:21] :-P [15:21] 2 review requested of https://codereview.appspot.com/7621048 [15:22] card is in high-priority maintenance review lane [15:23] gary_poster: I'll take one [15:23] ty [15:23] while I'm doing that - is there a way I can flatten commits with bzr? [15:23] I'll take one. [15:23] aka like a rebase with git [15:24] hatch, rebase was frowned upon within bzr, because commits are hierarchical [15:24] I think there's a way to do it but I've never done it [15:25] ahh - I just did a number of small commits and looking at the branch now it's hard to tell what the diff is [15:25] no biggy I guess :) [15:25] hatch, instead you can simply branch trunk again, and then merge in your old branch [15:25] oh that will do one commit? [15:25] not merge all of the commits? [15:25] hatch, that will give you what you want, while maintaining history hierarchically [15:26] imagine a big commit, which, if you really look at it, can be subdivided into your old smaller commits [15:26] rick_h_: any notion what might be busted that would let it pass for you not for me? surely YUI require doesn't vary b/c of an lxc... [15:26] but the default view will be what you want [15:26] ahh ok perfect thanks [15:26] and a little OT - what [15:26] 's a spike? [15:26] you mention it in your branch [15:27] hatch, XP term (as if we do XP): http://www.extremeprogramming.org/rules/spike.html . Short translation: code that you write to figure something out and prove it works, and then expect to throw away [15:28] jcsackett: not sure tbh. What's npm --version? [15:28] 1.2.11 [15:28] gary_poster: ohh ok - I just call those prototypes ;) [15:29] rick_h_: ^ [15:29] jcsackett: node version? [15:29] jcsackett: yea, not sure. I'm .14 but as long as you're not newer you're ok [15:29] there's a known issue with node 1.0 and the npm with it [15:29] hatch, +1 [15:30] hatch: v0.8.20 [15:30] hehe [15:30] jcsackett: but at this point, I cna't say since it doesn't break for me. Only thing I can think is to try a new lxc from scratch and if it works a diff directory v directory [15:30] jcsackett: odd - after this review I'll also check it out to see [15:34] hatch: ok. ping me with results. i'm going to go have some lunch. [15:36] hatch, you'll be happy to know that I ran my tests on IE 10 as well :-) [15:37] (and they passed) [15:37] haha awesome [15:47] jcsackett: good news - make test-prod fails for your branch here as well [15:50] hatch: huh. so what's magical about rick_h_'s setup... [15:50] he probably lied and ran make test-debug :P [16:04] jcsackett: ok for some reason in your tests Y.Tab() isn't a constructor [16:07] neither is TabView for that matter [16:09] so you'll need to evaluate why there is no tabview on prod [16:11] orly? I pasted my test results :P [16:12] rick_h_ was that make test-prod? [16:12] hatch: yea [16:12] well how odd is that [16:12] .zshhistory http://paste.mitechie.com/show/909/ [16:12] :) [16:13] merge? [16:13] yea, merged his changes into a local branch [16:13] oh - well that's not a clean checkout then is it? ;) [16:14] oh...well no...but it is test-prod with success [16:15] lol [16:15] ok diff those two branches and we might find the missing link [16:15] which two? This is jcsackett's branch. [16:16] whatever your local branch was [16:17] http://paste.mitechie.com/show/910/ here, that's more complete. It was just trunk [16:18] ohh ok [16:18] I'll try merging into trunk [16:20] hatch, rick_h_: i did the same steps i see in rick_h_'s paste but no dice. [16:21] jcsackett: also no luck here [16:21] so rick_h_ is magical. [16:22] for whatever reason it doesn't appear that the tabview files are being loaded into the prod rollup [16:22] lol, YUI auto loads to my commands because I rule [16:28] lol [16:30] jcsackett: i'd try to manually include the tabview files in the rollup [16:30] see if that solves the issue [16:30] see the merge-files script [16:30] hatch: ok. [16:31] sorry I'm just trying to do this namespace routing stuff at the same time [16:31] :) [16:35] hatch: success! [16:36] werd up! [16:36] what was it? [16:36] adding to merge-files [16:37] manually pushing 'tabview' into reqs fixed it. [16:37] ugh - that's the second time that script has failed us this week [16:37] and as several other modules are in there, i think this is not the first time someone has encountered this. [16:37] it's GOTA GO! [16:39] jcsackett: how I got to that point was to ack Y.TabView in the rollup [16:39] and when it wasn't found that was a big red flag [16:40] hatch: dig. i'll remember that if i hit this again. [16:40] hatch, rick_h_: can you fine folks take a look at https://codereview.appspot.com/7663050 when you have a moment and see what else might be wrong with this code? :-P [16:41] jcsackett: what's wrong now? [16:41] jcsackett: or you just mean general review [16:42] rick_h_: the latter. i was just being self-deprecating. [16:42] which, admittedly, is misleading in this instance. [16:42] jcsackett: heh, ok will peek in a minute [16:42] jcsackett: yea, nothing to get down about. I spent half of yesterday debugging stuff just as well [16:42] poor hatch gets brought into them with no hope :) [16:42] rick_h_: not down at all. quite pleased in fact to have sorted it. :-) [16:43] as long as i'm eventually getting stuff done, i'm happy/ [16:43] jcsackett: heh, and I think I see your issue. http://yuilibrary.com/yui/docs/tabview/ [16:44] you used a name already in the YUI namespace [16:44] nvm, I guess it is 'browser-tabview' [16:44] one of these days I'll have to look into that script [16:44] to see why it misses things [16:44] yeah, the file is the same, but the ns is different because our browser prefix. [16:45] jcsackett: right [16:47] review done [16:47] now if I can get back to MY OWN WORK!! [16:47] :P [16:47] lol [16:47] "16 conflicts encountered." This branch may never end. I always thought my life's work would be something more substantial than adding a single command to an API. [16:47] gary_poster: ping [16:48] hey rogpeppe [16:48] benji: lol [16:48] :) [16:48] gary_poster: so... the most significant allWatcher branch has just landed. [16:48] gary_poster: and you *might* be able to see something actually working [16:49] gary_poster: i wondered if you wanted a chat about where we want to go from here [16:49] rogpeppe, I saw the one earlier today that had the machinery. now we have the one that actually hooks it up too? [16:49] gary_poster: yup [16:49] awesome! [16:49] yay! [16:50] gary_poster: i'll believe it when i see the black triangle :-) [16:50] rogpeppe, sure, we can chat. http://tinyurl.com/guichat [16:51] gary_poster: i'm there... [16:57] jcsackett: review heading your way. I think there might be some more to clear up though on the way it works [16:57] honestly, now that I look closely I think a tabview that allows vertical was all we need. [16:58] jcsackett: sec, heading home from coffee shop and we can do a hangout in 10 [16:59] bcsaller: is the best way to get data into topology/service.js to pass the options in via the addModule() call in views/environment.js ? [17:00] hatch: we typically pass data to the env view and then from that to the topology. All modules will have access to their topology. === deryck is now known as deryck[lunch] [17:03] gotcha [17:03] damn you dependency injection [17:03] global variables for everyone! [17:19] benji, quick call in guichat? [17:20] benji, re https://code.launchpad.net/~gary/juju-gui/megawatcher [17:20] you are probably lunching, as I should be [17:20] lunch smunch [17:20] :-) [17:21] bcsaller: ok I pushed my changes to use dep injection, now I'm still trying to track down why this test is failing [17:22] I REALLY wish mocha would stop squashing console.log [17:23] hatch: mocha or the console handler in app? on a prod build the console is off by default [17:23] mocha shouldn't touch it [17:24] hatch, we have a fake console now...I bet we could make the tests turn off the console (i.e., switch to the no-op console) if we are running in mocha [17:24] that way we can log whatever we want [17:24] bcsaller: well when you run sh test-server.sh debug true no console.logs() are output to the console [17:25] gary_poster: ahh [17:25] sounds like you are encountering a different issue than what I thought you were talking about though...maybe related [17:25] when you run the tests in the browser do you get any logs in the devtools? [17:26] I think so. looking (I usually use breakpoints instead) [17:26] odd - debugger; also doesn't trigger it to stop [17:26] for me [17:27] hatch I have lots of "loader: has Skin?" things [17:27] that's it [17:27] yeah I don't even get those in the tests [17:27] wierd!!! [17:27] huh, weird [17:27] weird even [17:27] :P [17:28] Maybe we turn our fake console on? Looking... [17:31] hatch, our console manager is set to noop for our tests somewhere...finding where === matsubara is now known as matsubara-lunch [17:33] hatch, heh [17:33] I see why [17:33] we are running app tests [17:33] the app, when instantiated, defaults to turning the console off [17:34] unless you explicitly tell it to turn on [17:34] so hatch, the easy small solution is, in your test that you want to see console output in, call consoleManager.native() [17:35] (consoleManager is stuffed on window) [17:35] oh :) awesome thanks [17:36] to fix this generally...we'd have to do something in app to be more conditional about this somehow [17:36]