| wallyworld | davecheney: are you able to take one more look at https://codereview.appspot.com/6867073/ and see if it's now good to go? | 00:05 |
|---|---|---|
| davecheney | wallyworld: surethign | 00:15 |
| wallyworld | thanks | 00:15 |
| wallyworld | davecheney: the current config schema works for ec2, but for OpenStack username, tenantname, authorisation url, (and even region) should be supported to allow these things to go in the environment YAML file rather than having to be set via env vars. is this a reasonable assumption? | 00:55 |
| davecheney | wallyworld: sounds reasonable | 00:56 |
| davecheney | in the ec2 config you can specify your key and stuff in either the environs.yaml, or ENV vars | 00:56 |
| davecheney | wallyworld: am I talking about the same thing ? | 00:56 |
| wallyworld | yes | 00:57 |
| wallyworld | in config/config.go the schema is defined | 00:57 |
| wallyworld | but it only has ec2 things | 00:57 |
| wallyworld | meaning the only way to connect to openstack is to use env vars for the required parameters | 00:57 |
| wallyworld | well at least that's how i see it | 00:57 |
| wallyworld | i could be wrong | 00:57 |
| davecheney | wallyworld: will check about ec2 things | 00:58 |
| davecheney | by config/config.go is the generic configuration items | 00:58 |
| davecheney | then each provider has their own */config.go which adds the specific items like region, et al | 00:59 |
| davecheney | wallyworld: please hold, checking | 00:59 |
| wallyworld | ok | 00:59 |
| wallyworld | davecheney: yes you are right, found it | 00:59 |
| wallyworld | each provider does have it's own schema setup | 01:00 |
| wallyworld | i will look at that, thanks | 01:00 |
| davecheney | wallyworld: so the idea is config/config.go is the generic config (it's at the bottom of the file, which is confusing) | 01:00 |
| davecheney | then that struct is embedded in the config struct for each provider | 01:00 |
| davecheney | so they /extend/ (sort of) | 01:00 |
| davecheney | then config with their own attributes | 01:00 |
| davecheney | configuration was *ahem* contenious | 01:00 |
| wallyworld | :-) | 01:01 |
| wallyworld | like error handling :-) | 01:01 |
| davecheney | don't mention the war | 01:01 |
| wallyworld | i don't want to mention it but i am trying to get a code review approved :-) | 01:02 |
| wallyworld | and it has been contentious | 01:02 |
| davecheney | you and me both | 01:05 |
| === tasdomas is now known as domas | ||
| === domas is now known as domasm | ||
| === domasm is now known as tasdomas | ||
| TheMue | Morning all | 08:42 |
| fwereade__ | TheMue, heyhey | 08:46 |
| fwereade__ | TheMue, does that review look roughly sane to you? | 08:46 |
| TheMue | fwereade__: Oh, thought you're not here today. | 08:47 |
| TheMue | fwereade__: Looked good on a first view I've yesterday done on my mobile. Will start with it in a few moments. Still tired a bit from yesterday evening. | 08:48 |
| fwereade__ | TheMue, no worries :) | 08:50 |
| dimitern | TheMue, fwereade__: morning! | 08:51 |
| fwereade__ | dimitern, heyhey | 08:51 |
| TheMue | fwereade__: So you're out tomorrow and Friday? | 08:51 |
| TheMue | dimitern: Hiya | 08:51 |
| fwereade__ | TheMue, yeah, but I'll work a half day one of those days to make up for mon morn | 08:51 |
| TheMue | Ok | 08:52 |
| fwereade__ | dimitern, jam, mgz, TheMue, mramm: I believe that all of you will have some interest in https://codereview.appspot.com/6922051 -- comments would be most welcome | 10:18 |
| TheMue | fwereade__: Will have a look in a few moments. | 10:18 |
| fwereade__ | (it's the doc stuff we were talking about yesterday) | 10:18 |
| dimitern | fwereade__: 10x, I'll have a look | 10:19 |
| mgz | blopom. | 10:23 |
| dimitern | is there a way to stop http.ServeMux from redirecting with 301 when I have /path/ defined, so I can handle both /path/ and /path with the same handler? | 10:42 |
| Aram | yo. | 10:43 |
| dimitern | now i have mux.Handle("/path/", somehandler) and passing "/path" responds with 301 -> /path/ | 10:43 |
| dimitern | Aram: hey | 10:43 |
| TheMue | Aram: Hiya | 10:46 |
| TheMue | fwereade__: Btw, while I'm reading your texts, my CL is back in again. | 10:47 |
| fwereade__ | TheMue, cheers, I'll take a look when I'm done with my bug-capture pass | 10:49 |
| TheMue | fwereade__: Great, thanks. | 10:49 |
| fwereade__ | mramm, when you're around, there's a huge list of new bugs culled from TODOs in the docs -- sorry I didn't get to them yesterday :( | 10:57 |
| mramm | fwereade__: thanks! | 10:57 |
| mramm | fwereade__: no problem, there was no hurry | 10:58 |
| mramm | fwereade__: but it is good to have them so that we can get in on the fancy burn down chart action | 10:58 |
| fwereade__ | mramm, cool | 10:59 |
| dimitern | nevermind, I found a way around :) | 11:00 |
| fwereade__ | Aram, morning | 11:00 |
| fwereade__ | Aram, I would appreciate any comments you might have on https://codereview.appspot.com/6922051 -- I'm particularly concerned that I not propagate misinformation | 11:01 |
| dimitern | fwereade__, TheMue, jam: PTAL https://codereview.appspot.com/6924043 | 11:02 |
| fwereade__ | dimitern, I should get to that shortly | 11:02 |
| dimitern | fwereade__: cheers! | 11:02 |
| TheMue | dimitern: Will do after ending with Wiliams. | 11:02 |
| dimitern | TheMue: thanks | 11:03 |
| Aram | fwereade__: looking. | 11:06 |
| TheMue | fwereade__: Yay *hug* | 11:19 |
| fwereade__ | TheMue, haha, I was just about to say it in chat | 11:19 |
| fwereade__ | TheMue, I imagine you had an alert hooked up to a confetti cannon for that LGTM :) | 11:20 |
| fwereade__ | niemeyer, morning | 11:20 |
| TheMue | fwereade__: My mobile signals the Google mail sent after the review immediately. | 11:20 |
| fwereade__ | TheMue, nice | 11:20 |
| TheMue | fwereade__: Exactly, I'm starting a party now. ;) | 11:21 |
| TheMue | fwereade__: Btw, really like the work you've put into your documents. I'm still reading and it's great so far. Also helping new team members getting into the system. | 11:22 |
| fwereade__ | TheMue, cool, thanks :) | 11:22 |
| fwereade__ | TheMue, they're still very rough | 11:22 |
| TheMue | fwereade__: But written in a good readable way. | 11:23 |
| fwereade__ | TheMue, excellent :D | 11:23 |
| niemeyer | fwereade__: Yo | 11:30 |
| niemeyer | Good morning all | 11:30 |
| fwereade__ | niemeyer, how's it going? | 11:30 |
| niemeyer | fwereade__: Good stuff, still waking up :) | 11:30 |
| TheMue | fwereade__: Could you explain your comment on line 145 a bit more? | 11:33 |
| fwereade__ | TheMue, it's just an extension of what I was saying about the tomb access -- if the underlying Stop fails, watcher.Stop will kill the supplied tomb | 11:35 |
| fwereade__ | TheMue, and that error is actually a consequence of the one you return | 11:35 |
| fwereade__ | TheMue, so we'll get misleading kill reasons if we're unlucky | 11:35 |
| fwereade__ | TheMue, in general I like it when tomb.Kills are not scattered too widely, it makes it hard for me to follow expected shutdown procedures | 11:36 |
| TheMue | fwereade__: To make it more clear, which Stop() do you mean here? The machind isn't running at that point. | 11:36 |
| fwereade__ | TheMue, 145 watcher.Stop(unitw, &fw.tomb) | 11:37 |
| fwereade__ | TheMue, this will call unitw.Stop, and perhaps fw.tomb.Kill | 11:37 |
| TheMue | fwereade__: Ah, now I've got it. | 11:37 |
| rogpeppe1 | morning all | 11:38 |
| fwereade__ | rogpeppe1, heyhey | 11:38 |
| === rogpeppe1 is now known as rogpeppe | ||
| TheMue | fwereade__: I've been confused, becaus e machineData has a stop() too but that could not be used here. | 11:38 |
| TheMue | rogpeppe: Morning | 11:38 |
| fwereade__ | TheMue, yeah, the tombs are an aspect of the FW about which I am not wild | 11:38 |
| fwereade__ | TheMue, but I have no interest in further delaying this work because of them | 11:38 |
| TheMue | fwereade__: OK | 11:39 |
| fwereade__ | TheMue, I can see why they're the way they are, and I'm not sure I have a better suggestion anyway :) | 11:39 |
| TheMue | fwereade__: *lol* | 11:39 |
| rogpeppe | fwereade__, niemeyer: can i run an idea past you for crackfulness? | 11:41 |
| fwereade__ | rogpeppe, btw, your comments on https://codereview.appspot.com/6906046/ have (probably) been addressed | 11:41 |
| fwereade__ | rogpeppe, ofc | 11:41 |
| niemeyer | rogpeppe: Sure | 11:41 |
| rogpeppe | fwereade__: i'm wondering about having the agents use a juju.Conn (without an Environ) instead of always State directly | 11:41 |
| rogpeppe | fwereade__: that way we can put an API connection in there too | 11:42 |
| fwereade__ | rogpeppe, hmm, gut says -1 (mainly because I'm not sure what a Conn without an Environ actually is) | 11:42 |
| fwereade__ | rogpeppe, but I have always been a bit ambivalent about Conn itself anyway | 11:43 |
| niemeyer | That sounds like turning COnn into State, which doesn't sound very appealing on itself | 11:43 |
| rogpeppe | fwereade__: it's a wrapper around the State. (almost nothing that you do on the Conn actually involves the environ, actually) | 11:43 |
| niemeyer | rogpeppe: It's a high-level wrapper for comfortable library-like usage | 11:43 |
| rogpeppe | niemeyer: i'm not suggesting hiding the State completely | 11:43 |
| rogpeppe | niemeyer: just making it so that agents can access functionality through the API when they want | 11:44 |
| niemeyer | rogpeppe: I don't think I get it.. they should use functionality through the API at all times | 11:44 |
| dimitern | rogpeppe: hey :) wanna take a look - https://codereview.appspot.com/6906046/ | 11:44 |
| rogpeppe | niemeyer: agreed, but i was thinking this might be a reasonable transitional step | 11:45 |
| niemeyer | rogpeppe: The idea still scapes me | 11:45 |
| fwereade__ | niemeyer, I think the issue is that that's unworkable until we have a complete API, and that the "Conn" suggestion allows a path there without a big bang change | 11:45 |
| niemeyer | escapes | 11:45 |
| fwereade__ | niemeyer, rogpeppe: suggestion: drop the word "Conn" from the discussion | 11:45 |
| niemeyer | fwereade__: I don't see how it changes the problem | 11:45 |
| niemeyer | fwereade__: Huh.. I think I don't know what we're talking about :) | 11:45 |
| niemeyer | <rogpeppe> fwereade__: i'm wondering about having the agents use a juju.Conn (without an Environ) instead of always State directly | 11:46 |
| niemeyer | How do we drop Conn from that proposal? | 11:46 |
| fwereade__ | niemeyer, rogpeppe: so it becomes "we need to be able to use parts of the API before we have a complete API, and I think we should have a type containing both a State and an ApiState" | 11:46 |
| rogpeppe | fwereade__: yes | 11:46 |
| rogpeppe | fwereade__: Conn was just a place i thought might be reasonable for doing that | 11:46 |
| fwereade__ | rogpeppe, I remain -1 on putting that into Conn, myself | 11:47 |
| niemeyer | fwereade__: Well, sure.. just put add both of them to the function that creates the worker | 11:47 |
| rogpeppe | hmm, i wonder if api.State could just embed state.State | 11:47 |
| fwereade__ | rogpeppe, that's kinda dirty, but I think I like it | 11:48 |
| fwereade__ | rogpeppe, we can get an instant picture of how far we have to go by comenting out the embed and trying to build :) | 11:48 |
| rogpeppe | fwereade__: i'm not entirely sure it'll work though | 11:48 |
| niemeyer | It feels pretty dirty indeed, and it's not clear what the advantage is comparing to doing the obvious and having two values and using each of them when we want to | 11:49 |
| fwereade__ | niemeyer, I am not really keen on having all our client code have to keep track of two "state" things, and transitioning every client over call by call | 11:49 |
| rogpeppe | niemeyer: it means that, potentially, we can add new calls to the api and have them automatically used by all state clients. | 11:49 |
| fwereade__ | niemeyer, not having to do that is the main advantage of the suggestion, I think | 11:49 |
| niemeyer | fwereade__: What would be the problem with doing so? | 11:50 |
| niemeyer | fwereade__: We can also get an instant picture of what is left | 11:51 |
| fwereade__ | niemeyer, busywork, confusion, places we miss | 11:51 |
| dimitern | I'll grab some lunch | 11:51 |
| fwereade__ | niemeyer, in my own personal calculus of nastiness the two approaches are roughly equal, but for different reasons | 11:52 |
| niemeyer | fwereade__: All of those things seem equally applicable to the previous suggestion | 11:52 |
| niemeyer | fwereade__: The difference is that the second one is explicit | 11:52 |
| rogpeppe | in a way, the api *is* a wrapper around state.State, if you want to look at it that way, so embedding it doesn't feel too untoward | 11:52 |
| fwereade__ | niemeyer, isn't just a matter of removing a method from State and adding it to ApiState every time? | 11:53 |
| niemeyer | fwereade__: You know exactly what is going on | 11:53 |
| niemeyer | fwereade__: Which is a surprisingly important property | 11:53 |
| rogpeppe | i'm not sure i want to change everywhere to pass two things around where we're only talking to one state | 11:53 |
| fwereade__ | niemeyer, (huh, yeah, my previous comment applies in both places) | 11:53 |
| niemeyer | rogpeppe: That's great.. let's try to avoid that by actually finishing that work :) | 11:54 |
| rogpeppe | perhaps we could just pass around api.State and have a state.State member | 11:54 |
| rogpeppe | so all existing code calls apiState.State.Foo | 11:54 |
| niemeyer | rogpeppe: This seems much more hackish to me | 11:55 |
| rogpeppe | hmm, but that doesn't work | 11:55 |
| niemeyer | rogpeppe: It's pretty much impossible to tell if things you're passing apiState in actually are ported or not, without investigating all calls | 11:55 |
| niemeyer | rogpeppe: In general, when something is ported we can actually *port* it | 11:56 |
| niemeyer | rogpeppe: Take State out, put api.State in | 11:56 |
| niemeyer | (or whatever the name is) | 11:56 |
| niemeyer | rogpeppe: and that's it | 11:56 |
| niemeyer | rogpeppe: No two states | 11:56 |
| niemeyer | rogpeppe: If that's hard to do and there is value in doing it gradually, it seems rather sane to have the two values around | 11:57 |
| niemeyer | rogpeppe: so the one variable isn't a big deal | 11:57 |
| rogpeppe | niemeyer: ok. in practice, i think that means one big change all at once, but that's probably inevitable really | 11:57 |
| niemeyer | rogpeppe: There's no reason for that to be the case | 11:57 |
| rogpeppe | niemeyer: because once you start talking to, say, api.Machine, then api.Machine must implement all the relevant state.Machine methods | 11:58 |
| niemeyer | rogpeppe: That seems rather orthogonal | 11:58 |
| niemeyer | rogpeppe: It's not like any of these approaches would solve it | 11:58 |
| rogpeppe | niemeyer: the embedding approach *could*, i think. but it might end up hackish, yeah. | 11:59 |
| niemeyer | rogpeppe: That's a great reason not to even try it | 11:59 |
| rogpeppe | niemeyer: the hacks would eventually go :-) | 11:59 |
| niemeyer | rogpeppe: If we don't put them there, they are already gone right now.. magic! :) | 12:00 |
| rogpeppe | niemeyer: ok fair enough, it was just a thought. | 12:01 |
| niemeyer | rogpeppe: Sure, always happy to brainstorm | 12:01 |
| * fwereade__ lunches | 12:01 | |
| dimitern | rogpeppe: ping | 13:58 |
| rogpeppe | dimitern: pong | 13:58 |
| dimitern | rogpeppe: PTAL https://codereview.appspot.com/6906046/ | 13:58 |
| dimitern | :) | 13:58 |
| rogpeppe | dimitern: ah, sorry, looking now. | 13:59 |
| rogpeppe | dimitern: um, are you sure that's the right CL? | 14:00 |
| dimitern | rogpeppe: whoops :) no sorry https://codereview.appspot.com/6924043/ | 14:01 |
| niemeyer | rogpeppe: Hopefully that's the end of the default-series fix: https://codereview.appspot.com/6868070 | 14:08 |
| rogpeppe | niemeyer: will look after i'm done with dimitern's review | 14:09 |
| niemeyer | Super, thanks | 14:09 |
| niemeyer | Someone else's review would be appreciated too | 14:09 |
| niemeyer | I'll step out for lunch and move to review mode in the afternoon | 14:09 |
| jcastro_ | niemeyer: heya, whens your next core team call? I have a sort of plan to tackle the docs | 14:35 |
| dimitern | jcastro_: I think it's every tuesday at 13 UTC and 22 UTC | 14:41 |
| jcastro_ | thanks! | 14:42 |
| fwereade | jcastro_, fwiw, I have some *very* rough docs in review -- they weren't even really intended as documentation in anything but the loosest sense | 14:47 |
| jcastro_ | yeah | 14:48 |
| fwereade | jcastro_, but if you can see past the crappy aspects, then they are hopefully clear and current, and should be considered a provisional source of truth for (parts of) juju-core | 14:48 |
| jcastro_ | so right off the bat when reorging them, I think we should have them be in 2 major sections, user docs, and developer docs. | 14:48 |
| fwereade | jcastro_, https://codereview.appspot.com/6922051/ | 14:48 |
| jcastro_ | right now they're kind of jumbled together | 14:48 |
| fwereade | jcastro_, indeed -- and I'm afraid that the above suffers similarly to a degree | 14:49 |
| jcastro_ | it's like having to read a physics book to learn how to light your stove, don't care about the guts, I just need fire, and so on. | 14:49 |
| fwereade | jcastro_, those who have read the glossary have been generally positive though | 14:49 |
| fwereade | jcastro_, it's not super-fluffy but it should be clear | 14:49 |
| jcastro_ | fwereade: lifecycles.txt is awesome | 14:51 |
| fwereade | jcastro_, ty :D | 14:51 |
| rogpeppe | niemeyer: LGTM | 14:56 |
| jcastro_ | fwereade: I think our ecosystem team can easily handle the "using juju" and charm parts. And then have you guys handle the core sections. | 14:56 |
| jcastro_ | fwereade: it might make us more focused instead of "hey everyone, try to fix the docs." | 14:56 |
| fwereade | jcastro_, the trouble is I'm not *really* trying to fix the docs | 14:57 |
| fwereade | jcastro_, I wrote a few in-case-I-die braindumps that are pretty useful -- almost documentation -- and they are sliding in that direction almost by accident | 14:58 |
| jcastro_ | heh | 15:00 |
| fwereade | jcastro_, the other problem is that the charm parts in particular have changed in some ways -- which I have tried to capture in charms-in-action -- but that document is not comprehensive | 15:00 |
| fwereade | jcastro_, this is less of a big deal than you might think, because AFAWCT charms do tend to work | 15:01 |
| jcastro_ | that's ok, as long as one of us on ~charmers understands it we can massage it | 15:01 |
| rogpeppe | dimitern: replied | 15:02 |
| dimitern | rogpeppe: cheers! | 15:03 |
| fwereade | jcastro_, jolly good -- I just have to tell you about it somehow then :) | 15:04 |
| niemeyer | jcastro_: Team calls are on Tuesday generally | 15:42 |
| niemeyer | rogpeppe: Thanks! | 15:42 |
| niemeyer | // Note that ... this comment shouldn't be here! | 15:44 |
| fwereade | niemeyer, haha :) | 15:44 |
| niemeyer | ;-) | 15:44 |
| fwereade | niemeyer, btw, sorry -- I responded to this ancient CL but apparently failed to, er, repropose it | 15:45 |
| fwereade | niemeyer, the bug's been marked invalid as failed to repro but I don't see any harm to a laxer timeout anyway | 15:45 |
| niemeyer | fwereade: Where's that? | 15:46 |
| fwereade | niemeyer, waiting for unit public address to be set on uniter startup | 15:46 |
| fwereade | niemeyer, you commented "shouldn't there be a StartSync here" | 15:46 |
| niemeyer | fwereade: Ah, indeed | 15:46 |
| fwereade | niemeyer, I said "no but yes" and went offf to fix it and decided the answer was actually just "no" | 15:46 |
| niemeyer | fwereade: I also failed there.. I recall about a fix I should have sent to make one of those tests more resilient a century ago | 15:47 |
| fwereade | niemeyer, at least I'm not alone then, cheers :) | 15:47 |
| niemeyer | fwereade: So, why is the answer no, out of curiosity? | 15:47 |
| fwereade | niemeyer, because we could use a watcher to detect the change, but we'd have to keep spamming syncs at it | 15:47 |
| fwereade | niemeyer, so "watcher + spam syncs" seemed more complex than "poll" and I resolved thatit was better as it was | 15:48 |
| niemeyer | fwereade: Ah, sure, I wasn't suggesting that specific change originally | 15:48 |
| niemeyer | fwereade: I was suggesting just the StartSync | 15:49 |
| niemeyer | fwereade: Which shall reduce the timeout necessary, hopefully | 15:49 |
| fwereade | niemeyer, ah, ok -- I think that's not necessary because the uniter's not waiting for anything to set it | 15:49 |
| fwereade | niemeyer, it's just about the first thing it does | 15:49 |
| fwereade | niemeyer, so, indeed, 5s is generous | 15:50 |
| fwereade | niemeyer, but the theory we developed was that it was possibly a rogue canonistack pause and we may as well be resilient to such things | 15:50 |
| niemeyer | fwereade: Imagine E is an event we're waiting for, SS in StartSync, R is the time we read the state to see if it's what we expect, and dot (.) is time passing.. if we just loop, it may go like: | 15:50 |
| fwereade | niemeyer, (I'm 80% sure it was exposed in one of davecheney's canonistack runs) | 15:51 |
| niemeyer | fwereade: E . R . . . . . . E | 15:51 |
| niemeyer | fwereade: With SS, it becomes: E . SS . E . R | 15:51 |
| niemeyer | fwereade: So the global timeout may be shorter.. | 15:52 |
| niemeyer | fwereade: Actually, it's more clear as | 15:52 |
| niemeyer | fwereade: R .. R .. R .. R .. R .. E | 15:52 |
| niemeyer | vs. | 15:52 |
| niemeyer | fwereade: SS R .. SS E | 15:53 |
| niemeyer | Or something like that | 15:53 |
| fwereade | niemeyer, ok, I see a nicer way to do it than I had before, just a mo | 15:55 |
| niemeyer | Hmm | 16:11 |
| niemeyer | Got a failure on | 16:11 |
| fwereade | niemeyer, huh, perhaps not | 16:12 |
| niemeyer | provisioner_test.go:103: | 16:12 |
| niemeyer | c.Errorf("provisioner did not start an instance") | 16:12 |
| niemeyer | ... Error: provisioner did not start an instance | 16:12 |
| niemeyer | Anyone seen this before? | 16:12 |
| fwereade | niemeyer, does SS do this: | 16:12 |
| fwereade | niemeyer, sorry, restate: how long after a call to StartSync will a change not send of a watch channel? | 16:13 |
| fwereade | niemeyer, *on* a watch channel | 16:14 |
| fwereade | niemeyer, hm, I'm not sure that question makes sense even, bother | 16:14 |
| niemeyer | fwereade: Yeah, there doesn't seem to be a definitive answer to it | 16:18 |
| fwereade | niemeyer, so, that is my problem | 16:18 |
| niemeyer | fwereade: Why does it matter in this case? | 16:18 |
| fwereade | niemeyer, I know an event will occur at some future time | 16:18 |
| fwereade | niemeyer, butthat any given StartSync's sync may not happen to complete in time to see that change | 16:18 |
| niemeyer | fwereade: There's not even a "completion" of StartSync so to speak | 16:19 |
| niemeyer | fwereade: (that's the "Start" in it) | 16:19 |
| fwereade | niemeyer, ok, so a StartSync causes a sync to occur | 16:19 |
| fwereade | niemeyer, and at some stage in the future that sync will complete | 16:19 |
| niemeyer | fwereade: Right, it schedules a sync to occur | 16:19 |
| niemeyer | fwereade: Yes, in the near future | 16:19 |
| fwereade | niemeyer, and after that sync is complete it is unhelpful re detecting future events | 16:20 |
| niemeyer | fwereade: Hmm.. that seems to lack context | 16:20 |
| niemeyer | fwereade: It may be helpful or not | 16:20 |
| fwereade | niemeyer, 5 minutes from now, I will change a unit that you are watching: is it helpful for you to call StartSync now and expect it to deliver the event faster when it does come? | 16:21 |
| fwereade | niemeyer, I believe it is not | 16:21 |
| niemeyer | fwereade: That's the graph above | 16:21 |
| niemeyer | fwereade: Compare this: | 16:21 |
| niemeyer | fwereade: R . . . . . . . . . R . E . . . . . . . R | 16:23 |
| niemeyer | fwereade: With this: | 16:23 |
| niemeyer | fwereade: SS R . . E . . . . . . R | 16:23 |
| niemeyer | fwereade: Makes sense? | 16:25 |
| fwereade | niemeyer, I'm sorry, I'm not taking your point :( | 16:25 |
| niemeyer | fwereade: Sorry.. hmm | 16:25 |
| fwereade | niemeyer, as a point of common ground, would you confirm or deny my previous statement re 5-minute waits? | 16:25 |
| niemeyer | fwereade: It's false | 16:26 |
| niemeyer | fwereade: StartSync is unrelated to the time of the event | 16:26 |
| niemeyer | fwereade: It's related to the time of the watch loop instead | 16:26 |
| niemeyer | fwereade: We dont' call it to make the event happen faster.. we call it to observe its occurrence faster | 16:26 |
| fwereade | niemeyer, yes, I am well aware of this | 16:26 |
| niemeyer | fwereade: Okay.. the problem is I think you understand everything I'm saying, so I'm unsure about which piece is missing there or here | 16:28 |
| fwereade | niemeyer, I was trying to ask whether the observation delay in an event 5 minutes in the future will be reduced by a call to StartSync now | 16:28 |
| fwereade | niemeyer, my understanding is that it will not | 16:28 |
| niemeyer | fwereade: It will not, and that's unrelated to the reason why StartSync is suggested | 16:28 |
| niemeyer | fwereade: Which is why it's unclear | 16:28 |
| fwereade | niemeyer, ok, what do you believe StartSync will speed up? | 16:29 |
| niemeyer | fwereade: It speeds up the observation of events when you're polling repeatedly | 16:29 |
| niemeyer | fwereade: It makes the time of the poll rule the time of the watcher refreshing | 16:30 |
| niemeyer | fwereade: This is all unrelated to how long it will take for the event to actually happen | 16:30 |
| fwereade | niemeyer, sorry, phone | 16:33 |
| fwereade | niemeyer, ok | 16:34 |
| fwereade | niemeyer, I think we may be talking at cross purposes | 16:34 |
| niemeyer | fwereade: I'm pretty sure about it :) | 16:34 |
| fwereade | niemeyer, when I "poll", I refresh the unit every 50ms and see if it has the address I want | 16:34 |
| fwereade | niemeyer, I do not see how startsync factors in here | 16:34 |
| fwereade | niemeyer, because none of the events that lead the unit's address to be set are waiting for any watchers | 16:35 |
| fwereade | niemeyer, *if* I were to use a unit watcher, then I could maybe avoid any sort of polling -- but actually, if I want events to arrive in a timely way, I need to call StartSync repeatedly | 16:36 |
| fwereade | niemeyer, because the sync might complete before the change I'm waiting for actually happens | 16:36 |
| fwereade | niemeyer, so I need to start a new sync every, say, 50ms | 16:36 |
| fwereade | niemeyer, ...or am I on crack? | 16:37 |
| niemeyer | fwereade: No, quite possibly I'm the one off | 16:38 |
| niemeyer | fwereade: So is there no watcher in the pipeline towards the expected point? | 16:39 |
| fwereade | niemeyer, I'm pretty sure not | 16:39 |
| niemeyer | fwereade: Okay, so surely there is no need to refresh the watcher :) | 16:39 |
| niemeyer | fwereade: Phew, sorry | 16:39 |
| fwereade | niemeyer, no worries, it's a pretty unexpected situation for juju ;) | 16:40 |
| niemeyer | fwereade: Yeah :-) | 16:40 |
| niemeyer | fwereade: LGTM | 16:40 |
| niemeyer | fwereade: Sorry for the confusion | 16:40 |
| niemeyer | YouTube is the new radio | 16:41 |
| fwereade | niemeyer, np :) | 16:41 |
| niemeyer | One of these days I'll make a small app that allows one to type a search statement, and it'll just pick entries out of the list for playing | 16:42 |
| niemeyer | It'd also be nice to have a no-video mode to save bandwidth | 16:42 |
| * Aram can't listen to lossily compressed audio. | 16:44 | |
| niemeyer | Aram: Having less hearing accuracy has its advantages :-D | 16:49 |
| Aram | I suppose. | 16:50 |
| * Aram bought tickets to The Hobbit. | 16:50 | |
| Aram | I was undecided between IMAX 3D and regular 3D. | 16:50 |
| Aram | but I had to chose regular since the IMAX is not available in English. | 16:50 |
| rogpeppe | i'm done for the day | 18:18 |
| rogpeppe | g'night all | 18:18 |
| niemeyer | rogpeppe: Nighty night | 18:21 |
| * niemeyer => exercising | 20:49 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!