[07:06] <davecheney> soooo much better
[07:07] <davecheney> http://paste.ubuntu.com/1433970/
[07:57] <TheMue> Morning
[07:58] <fwereade> TheMue, heyhey
[07:58] <TheMue> fwereade: Can't see you, you are not here. ;)
[07:58] <TheMue> fwereade: Morning. :)
[07:58] <TheMue> fwereade: Thought you're on vacation today?
[07:59] <fwereade> TheMue, kinda sorta -- I need to do a half day today to catch up with monday when I took an uncheduled one
[08:00] <fwereade> TheMue, I haven't quite decied whether I'm "really" working this morning yet though
[08:00] <fwereade> ;)
[08:00] <TheMue> fwereade: Hehe, here sometimes typical office jobs have more clear constraints.
[08:17] <fwereade> TheMue, ok, just popping out, sent another comment on the FW
[08:18] <TheMue> fwereade: Just seen it, thanks. Enjoy your day.
[11:03] <dimitern> mgz: ping
[11:03] <wallyworld_> dimitern: can you hear me?
[11:03] <dimitern> wallyworld_: no
[11:09] <TheMue> *lol*
[11:09] <mgz> dimitern: hey
[11:10] <dimitern> mgz: mumble?
[11:11] <mgz> I'm on.
[11:32] <Aram> hello.
[11:34] <TheMue> Aram: Hi
[11:43] <niemeyer> Mornings!
[11:47] <dimitern> niemeyer: morning
[11:51] <TheMue> niemeyer: Hiya
[12:04] <TheMue> So, lunchtime. BIAB
[12:35] <fwereade> morning everyone
[13:07] <niemeyer> TheMue: ping
[13:08] <fwereade> niemeyer, in case TheMue's still at lunch, I was wondering a bit about EnsureSubordinate naming
[13:08] <niemeyer> fwereade: Heya
[13:08] <niemeyer> fwereade: Are you working or on holiday today?
[13:08] <fwereade> niemeyer, catching up a half day I took off unscheduled on monday
[13:08] <niemeyer> fwereade: Just to see how much I can bother you ;_)
[13:09] <fwereade> niemeyer, I am eminently botherable :)
[13:09] <niemeyer> ROTFL
[13:09] <niemeyer> fwereade: Cool, let's see naming first then :)
[13:09] <fwereade> niemeyer, EnsureSubordinate is, in my mind, a sensible contraction of EnsureHasSubordinateIfThatIsSensible
[13:10] <niemeyer> fwereade: Agreed, not trying to explain it all there
[13:11] <fwereade> niemeyer, for some reason EnsureHasSubordinate feels, er, a bit different
[13:11] <niemeyer> fwereade: The clarity I was aming for is that foo.EnsureBarer generally ensures that foo is a barer
[13:11] <niemeyer> fwereade: It feels awkward to call out ru.EnsureSubordinate() when ru must necessarily not be a subordinate
[13:12] <fwereade> niemeyer, yeah, that makes sense -- I was also pondering EnsureSubordinateState at one point, but that didn't seem quite clear either
[13:13] <niemeyer> fwereade: To be honest, I think ru.CreateSubordinate would be best
[13:13] <niemeyer> fwereade: Returning ErrSubordinateExists or ErrSubordinateInvalid
[13:13] <fwereade> niemeyer, I was just about to suggest those :)
[13:14] <niemeyer> fwereade: Hah, jinx then :)
[13:14] <TheMue> niemeyer: Pong, just had to bring my daughter to her voluntary work.
[13:14] <fwereade> niemeyer, that's great then -- grab me when you're done with TheMue then?
[13:14] <niemeyer> TheMue: Nice.. does she work voluntarily on the voluntary work? :-)
[13:15] <niemeyer> TheMue: I'll need some extra time to look over the logic on the branch actually
[13:15] <fwereade> niemeyer, hah, when I was at school, there was an institution called "voluntary tea" on friday afternoons
[13:15] <fwereade> niemeyer, no, it was not voluntary :/
[13:15] <niemeyer> TheMue: I'm just going over the firewaller change
[13:15] <TheMue> niemeyer: Hehe, yes, it's for bridging the time until her education as occupational therapist.
[13:16] <niemeyer> fwereade: Hehe, that's how it generally goes :-)
[13:16] <TheMue> niemeyer: Ah, fine, has been a lot of discussion by fwereade and me in there.
[13:17]  * fwereade hopes he hasn't been leading TheMue up the garden path
[13:31] <fwereade> niemeyer, a thought is squatting toadlike in my brain, and while I don't like it very much it will not leave peacefully
[13:32] <fwereade> niemeyer, I don't think that CreateSubordinate actually deserves an independent existence -- it'd only ever be called just after EnterScope, and it depends on basically the same things... I can't think of a good reason not to roll CS into ES
[13:32] <niemeyer> fwereade: Sounds good as well.
[13:34] <fwereade> niemeyer, ok, great, I'll have a go at that -- and that then means the errors collapse back down to ErrCannotEnterScope, I think
[13:35] <fwereade> niemeyer, it will also demand a RelationUnit.Subordinate method, I think, but I don't need that quite yet (in fact I will only want it for testing)
[13:35] <fwereade> niemeyer, anyway I will try it out and let you know how it goes
[13:36] <fwereade> niemeyer, oh: crack check: I shouldn't bother to check related service life state because, if the relation is alive, both its services must also be alive
[13:38] <niemeyer> fwereade: Hmm.. good point
[13:38] <fwereade> niemeyer, (and, yay, that is a statement of truth not just of intent)
[13:38] <fwereade> niemeyer, cool, cheers
[14:21] <fwereade> niemeyer, just in case, do you know if anyone knows what next spring's UDS dates will be?
[14:21] <niemeyer> fwereade: Not yet.. have you checked the UDS website?
[14:22] <fwereade> niemeyer, all it seems to have is copenhagen
[14:23] <niemeyer> TheMue: Review sent
[14:24] <TheMue> niemeyer: Great, thanks.
[14:27] <niemeyer> TheMue: np, please let me know if it makes sense
[14:28] <niemeyer> Heading to lunch now
[14:29] <TheMue> niemeyer: Yes, first look is fine, just started to adopt it. For the approach we have to thank William and his steadiness. It has been a great help.
[14:29] <TheMue> niemeyer: Enjoy your luch.
[14:32] <fwereade> TheMue, a pleasure, thanks for your patience, I'm not sure I was always very clear :)
[14:34] <TheMue> fwereade: It has been fine to tame this pretty nice beast, a good experience.
[14:43] <mgz> is there a neat way to run a single live test? I'm failing at finding the right go test spelling.
[14:47] <Aram> -gocheck.f <regexp>
[14:47] <Aram> where regexp matches the test function name.
[14:48] <Aram> mgz: ^ ^
[14:49] <mgz> ah, that was it, need to remember -gocheck not -test flags
[14:49] <mgz> thanks Aram
[14:49] <Aram> cheers.
[14:54] <mgz> okay, fixing this bug the way I would like will be annoying
[14:55] <mgz> ideally I'd write a way in the goamz fake server thing that reproduced this behaviour, so running the problematic live test failed in the correct manner, then fix the live test itself
[14:56] <mgz> but that's two different projects and custom behaviour for a specific test...
[15:12] <TheMue> So, AFK again.
[15:40] <fwereade> niemeyer, rolled subordinate creation into EnterScope in https://codereview.appspot.com/6906046/
[15:41] <fwereade> niemeyer, (I also addressed your comments in https://codereview.appspot.com/6845120/ -- I would love it if you had a moment to take a look before you depart...)
[15:41] <fwereade> TheMue, a second look at https://codereview.appspot.com/6906046/ would be appreciated: it's changed pretty significantly since you saw it last
[15:46] <niemeyer> fwereade: Yo
[15:47] <niemeyer> fwereade: Will look at both
[15:47] <niemeyer> Now
[15:48] <niemeyer> fwereade: "This'd be Unit.EnsureDead's job, but it doesn't do it."
[15:48] <niemeyer> fwereade: Should we adapt comments in the respective places so they reflect what we want to happen then?
[15:48] <fwereade> niemeyer, yeah, that's a good idea
[15:49] <fwereade> niemeyer, I thought of that just after I submitted :/
[15:49] <niemeyer> fwereade: Super
[15:49] <niemeyer> fwereade: "Nothing -- but it was a single-use method that I factored back into the single
[15:49] <niemeyer> caller... and then forgot to delete."
[15:49] <niemeyer> fwereade: So the method is now unused?
[15:49] <fwereade> niemeyer, isn't it gone in that CL?
[15:50] <fwereade> niemeyer, ah, yes, it is deleted now
[15:50] <fwereade> niemeyer, yeah
[15:51] <niemeyer> fwereade: Cool, sounds good then
[15:52] <niemeyer> fwereade: I think there was some misunderstanding regarding the name
[15:52] <niemeyer> fwereade: I was suggesting isAliveDoc for the bson.D document
[15:52] <fwereade> niemeyer, oh, sorry?
[15:52] <fwereade> niemeyer, ha!
[15:52] <fwereade> sorry
[15:52] <niemeyer> fwereade: np
[15:54] <niemeyer> fwereade: and isDeadDoc, respectively
[15:54] <fwereade> niemeyer, notDeadDoc I presume
[15:54] <niemeyer> fwereade: Ugh, yes
[15:54] <fwereade> niemeyer, sgtm
[15:54] <niemeyer> fwereade: Nice to see how much simpler the logic is since we don't have to consider errors
[15:55] <niemeyer> fwereade: I mean, we don't have to figure what happened to return the proper error
[15:55] <fwereade> niemeyer, isn't it-- although EnterScope is some where near the edge my comfortable-complexity limit
[15:55] <niemeyer> fwereade: Indeed, it's probably the most complex function we have in state ATM
[15:56] <fwereade> niemeyer, at least I can't think of any others that'll be that bad
[15:57] <niemeyer> fwereade: Agreed. And the logic is also readable, I think
[15:57] <niemeyer> fwereade: Perhaps requiring some context, though
[15:57] <fwereade> niemeyer, ah, I tried to do that :(
[15:58] <niemeyer> fwereade: Should LeaveScope kill the subordinate unit?
[15:58] <fwereade> niemeyer, nope, don't think so -- it has an independent existence and agent and its own shutdown sequence
[15:59] <fwereade> niemeyer, setting the prinicpal to dying should do the same to its subordinates, and then we should just sit back and wait
[15:59] <niemeyer> fwereade: Hmm..
[15:59] <niemeyer> fwereade: What kills the unit when the relation is departed then?
[16:01] <fwereade> niemeyer, good point
[16:01] <fwereade> niemeyer, I still don't think it's LeaveScope's job
[16:02] <fwereade> niemeyer, I think if anything that a subordinate unit should also be watching for its relation's death
[16:02] <fwereade> niemeyer, s/death/Dying/
[16:02] <fwereade> niemeyer, just as all units do with their services
[16:02] <niemeyer> fwereade: Sounds sensible, but isn't LeaveScope precisely the final cue that the relation is gone?
[16:03] <niemeyer> fwereade: Perhaps the action should take in the subordinate, though, rather than the principal
[16:03] <niemeyer> s/take/be taken/
[16:04] <niemeyer> fwereade: Perhaps not.. if the relation is removed earlier the subordinate will never enter it
[16:04] <fwereade> niemeyer, yeah, I'm still thinking it through
[16:04] <fwereade> niemeyer, in general LeaveScope happens pretty late though
[16:05] <fwereade> niemeyer, I think I'd like the subordinate agents to start clearing themselves up at the right point independently of what the principal does
[16:05] <niemeyer> fwereade: Sure, but let's think about a worse case scenario
[16:05] <niemeyer> fwereade: It's entirely possible that by the time the subordinate unit runs, the relation doesn't even exist anymore
[16:05] <niemeyer> s/worse/worst/
[16:06] <niemeyer> fwereade: Right?
[16:06] <niemeyer> fwereade: +1 on your last comment
[16:06] <fwereade> niemeyer, yeah, you're right
[16:08] <fwereade> niemeyer, this is a dependency I had not hitherto considered :/
[16:09] <niemeyer> fwereade: I think it's all good, though.. we just need specific logic in the subordinate unit agent that observes the right moment to suicide
[16:10] <fwereade> niemeyer, yeah, indeed -- it's just that there's no very obvious way to be sure which relation the subordinate exists as a consequence of
[16:11] <fwereade> niemeyer, I *think* the easiest way to handle that is to tag subordinate units with the relation ID they exist because of
[16:11] <fwereade> niemeyer, but that has not been thought through with any rigour
[16:11] <niemeyer> fwereade: Every subordinate unit has a principal field
[16:12] <niemeyer> fwereade: Either there must be a relation with that unit, or its life is compromised
[16:12] <niemeyer> A container relation, specifically
[16:12] <fwereade> niemeyer, true -- so we *can* figure out the two services involved, and thereby figure out the relation, maybe-probably, because I am suspicious of what happens if that relation is discarded and recreated
[16:13] <fwereade> niemeyer, IMO an additional field meaning "this unit's life is also contingent on that of this relation" feels like a more certain way to do it
[16:13] <niemeyer> fwereade: That'd probably be a situation in which it'd be fine for the unit to stay around
[16:14] <niemeyer> fwereade: That'd open the potential for other races, though
[16:14] <niemeyer> fwereade: Such as having two subordinate units
[16:14] <fwereade> niemeyer, *probably*, yeah, but it's the sort of chain of suppositions that I am suspicious of
[16:14] <niemeyer> fwereade: For the same service
[16:14] <fwereade> niemeyer, I don't *think* that can happen
[16:15] <fwereade> niemeyer, but I am not willing to swear that there will be no surprising consequences
[16:15] <fwereade> niemeyer, I would prefer to keep the chains of logic as short as possible
[16:16] <niemeyer> fwereade: Sounds good, but I'm not sure of what you mean by that
[16:17] <fwereade> niemeyer, principal -> principal's service -> figure out the relation
[16:17] <fwereade> niemeyer, vs
[16:17] <fwereade> niemeyer, relation
[16:17] <fwereade> niemeyer, there are a lot more opportunities for bugs in the former
[16:19] <fwereade> niemeyer, given two services we cannot necessarily uniquely determine the relation between them
[16:19] <fwereade> niemeyer, but, ha, that's enough to sink my proposal
[16:20] <fwereade> niemeyer, there's nothing stopping us having two distinct container relations between the same two services, is there?
[16:20] <fwereade> niemeyer, not that that's a *nice* thing to do
[16:20] <niemeyer> fwereade: Nope
[16:20] <niemeyer> fwereade: I think it's a fine thing to do
[16:21] <niemeyer> fwereade: For the same reason that it's fine to have more than one relation between arbitrary services
[16:21] <fwereade> niemeyer, indeed so
[16:21] <fwereade> niemeyer, ok, maybe you're right
[16:21] <niemeyer> fwereade: Either way, I'm vaguely convinced that being able to ask whether two named units are part of a common relation must not be a hard question
[16:22] <fwereade> niemeyer, if *any* Alive container relation exists between the subordinate's service and its principal, the subordinate should be Alive
[16:22] <niemeyer> fwereade: Given that a uniter already maintains tight control of remote participant units on any given relation
[16:22] <niemeyer> fwereade: That's right
[16:22] <fwereade> niemeyer, I think that's a subtly different question
[16:23] <niemeyer> fwereade: Ah, you're right, yes
[16:23] <niemeyer> fwereade: It doesn't really matter whether the relation is established or not
[16:23] <niemeyer> fwereade: It matters if it exists
[16:23] <fwereade> niemeyer, yeah, exactly
[16:24] <fwereade> niemeyer, but, still, I think it's less hard than I feared two minutes ago
[16:25] <niemeyer> fwereade: Yeah, thinking in terms of a database query, it's "foo:.* bar:.*" || "bar:.* foo:.*" exist and is alive
[16:25] <fwereade> niemeyer, (and, fwiw, this CL is very firmly focused on creation rather than removal -- subordinates we can't delete are suboptimal but (?) on par with python)
[16:25] <niemeyer> exists
[16:25] <fwereade> niemeyer, yep, exactly
[16:25] <niemeyer> fwereade: I know.. it's approved already
[16:25] <fwereade> niemeyer, ah, nice :)
[16:25]  * fwereade can be slow at times
[16:25] <niemeyer> fwereade: I just raised the issue as a brainstorm for future steps
[16:25] <fwereade> niemeyer, yeah, much appreciated
[16:27] <fwereade> niemeyer, but we're agreed that it's not LeaveScope then? (the only bug I am aware of in LeaveScope is that it doesn't delete services when it needs to)
[16:31] <niemeyer> fwereade: Yeah, agreed
[16:32] <fwereade> niemeyer, perfect
[16:51] <niemeyer> fwereade: next one is good to go too
[16:54] <fwereade> niemeyer, sweet :D
[16:57] <niemeyer> TheMue: https://codereview.appspot.com/6875053/ reviewed too
[17:05] <fwereade> niemeyer, would you expand a little on "deploying agent" vs "deploying unit" -- my heart still favours the first
[17:05] <fwereade> niemeyer, (I'm fine changing it, I'm just not sure why :))
[17:05] <niemeyer> fwereade: DeployUnit does significantly more than deploying an agent
[17:05] <niemeyer> fwereade: An agent is jujud process running
[17:05] <niemeyer> fwereade: DeployUnit can do whatever it pleases to put the agent to run
[17:06] <fwereade> niemeyer, bingo, thanks
[17:06] <niemeyer> fwereade: Including creating a container, downloading an image, running a container, etc
[17:09] <TheMue> niemeyer: Thx for review.
[17:19] <fwereade> niemeyer, ok, well, now that deployer's in, the how-to-merge-question comes up: I'm still not convincer that a MachinerWorker is a good reason to start a Deployer worker
[17:19] <fwereade> niemeyer, it feels a bit off to me
[17:19] <niemeyer> fwereade: So let's do the change we discussed the other day and have flags there instead
[17:19] <fwereade> niemeyer, task-per-flag? <3
[17:20] <fwereade> niemeyer, upgrader I presume remains implicit?
[17:20] <niemeyer> fwereade: Not task per flag.. flag per flag :).. the idea is precisely to avoid the 1-to-1 relationship between code and run mode
[17:21] <niemeyer> fwereade: Flags can possibly change the way that code run, instead of adding a new task
[17:22] <fwereade> niemeyer, ah, ok, I wasn't really quite expecting you to have changed your mind there
[17:22] <niemeyer> fwereade: We had already gotten to that point in our last conversation IIRC
[17:22] <fwereade> niemeyer, but the idea has not quite clicked with me, I'm afraid, and I'm a little nervous that I will do something completely unlike what you expect
[17:23] <fwereade> niemeyer, yeah, but I did some independent thinking last weekend and accidentally dragged my comprehension of the problem back towards my initial viewpoint
[17:23] <niemeyer> fwereade: Okay, so how does it stand now?
[17:25] <fwereade> niemeyer, basically I've confused myself -- I ran with an Agent idea for a bit and I think it's nice but I can't really justify it yet :(
[17:26] <fwereade> niemeyer, or, at least, I don't have the time or emotional fortitude necessary to convince you before you go on holiday even if I am right ;p
[17:26] <niemeyer> fwereade: Hehe :)
[17:26] <fwereade> niemeyer, and I am reluctant to sneak it past you while you're away
[17:26] <fwereade> niemeyer, because I doubt you would appreciatethat too much ;)_
[17:26] <niemeyer> fwereade: So let's try to reach some quick agreement.. feel free to sneak it in as we go
[17:27] <fwereade> niemeyer, haha
[17:27] <niemeyer> fwereade: What we have now is a document in the database representing the machine
[17:27] <niemeyer> fwereade: That document has a field with a few names that we map 1-to-1 to what we call workers, which are really packages under the worker directory which tend to do relevant and mostly independent tasks within an agent
[17:28] <niemeyer> fwereade: agent being the name we give to a jujud process that we run to control stuff up in situations where one or more workers are necessary
[17:28] <niemeyer> fwereade: So far so good?
[17:28] <fwereade> niemeyer, yep
[17:29] <niemeyer> fwereade: Cool.. so the discomfort we're sitting in happens because we rightfully renamed one of our workers to adapt the code
[17:30] <fwereade> niemeyer, indeed
[17:30] <niemeyer> fwereade: and the fact we have fields which are tied to code name rather than the intended semantics for the running logic means we're forced to swallow a mismatch, or fix it, or change the way we refer to that kind of semantics so that we avoid future mismatches
[17:30] <niemeyer> fwereade: I'm suggesting the latter
[17:30] <niemeyer> fwereade: and part of my motivation is that I think the 1-to-1 mapping between package name and semantics is too artificial to survive over time
[17:31] <fwereade> niemeyer, ok -- I guess my own discomfort here is that I'm not clear on what the intended semantics are
[17:31] <niemeyer> fwereade: Understood. That's easy to solve, I think.
[17:31] <fwereade> niemeyer, you have stated the problem helpfully though
[17:31]  * fwereade is all ears
[17:31] <niemeyer> fwereade: We have three different flags today:
[17:32] <niemeyer> fwereade: Flag 1) "I want this agent to manage the firewall for the environment"
[17:32] <niemeyer> fwereade: Flag 2) "I want this agent to manage the provisioning of machines for the environment"
[17:32] <niemeyer> fwereade: Flag 2) "I want this agent to manage the hosting of units for that machine"
[17:32] <niemeyer> s/2/3/ on the last, of course
[17:33] <fwereade> niemeyer, right, yes, agreed
[17:33]  * niemeyer holds off a bit
[17:34] <niemeyer> fwereade: Welcome back
[17:35] <niemeyer> fwereade: So
[17:35] <fwereade> grar, sorry
[17:35] <niemeyer> LOL
[17:35] <fwereade> sorry, that time the actual client crashed :/
[17:36] <niemeyer> fwereade: No worries
[17:36] <niemeyer> fwereade: So!
[17:36] <niemeyer> :)
[17:36] <niemeyer> fwereade: We have these three stated semantics
[17:36]  * fwereade sits very still
[17:36] <niemeyer> fwereade: My proposal was to find a way to name the intended semantics without actually referring to worker, or task
[17:37] <niemeyer> fwereade: But rather as a property of the machine itself
[17:37] <niemeyer> fwereade: and at the agent side, we map these flags to workers, tasks, or whatever we please
[17:38] <fwereade> niemeyer, ok, that SGTM -- and that reduces the current problem to a naming question really, just a different one to that I had previously imagined
[17:40] <niemeyer> fwereade: Cool.. so how do we name those flags? Hmmm
[17:41]  * fwereade is still a touch baffled by this question
[17:41] <niemeyer> fwereade: Hm?
[17:42] <niemeyer> fwereade: I'm baffled by your baffledness :-D
[17:42] <fwereade> niemeyer, I don't know what we should name them
[17:43] <fwereade> niemeyer, well, Firewaller and Provisioner are a bit too close to the worker names for comfort -- the implication is that flags *do* map onto workers
[17:43] <fwereade> niemeyer, and I really don't like "machiner"
[17:44] <niemeyer> fwereade: Strawman: HostProvisioner, HostFirewaller, HostUnits
[17:45] <fwereade> niemeyer, ok, I think I can work with those :)
[17:45] <niemeyer> fwereade: Although HostFirewaller is still not great
[17:45] <niemeyer> fwereade: Because we'll likely have local firewall management soonish
[17:45] <fwereade> niemeyer, I think the big issue there is ... exactly
[17:46] <fwereade> niemeyer, I'm almost tempted to roll firewalling into provisioning again
[17:46] <niemeyer> fwereade: ManageEnvironFirewall, ManageEnvironProvisioning, HostUnits
[17:46] <fwereade> niemeyer, ie if HostProvisioner, we run both P and FW workers
[17:47] <niemeyer> fwereade: Hmm
[17:47] <niemeyer> fwereade: Interesting
[17:47] <fwereade> niemeyer, or HostEnvironStuff ;p
[17:47] <fwereade> niemeyer, (bad name, just saying I'm not attached ot the specific chars that make it up)
[17:48] <niemeyer> fwereade: Sounds like a good idea.. there's no great reason to separate those
[17:49] <fwereade> niemeyer, ok, fantastic -- that feels like enough to be going on with
[17:50] <fwereade> niemeyer, I am being encouraged to be a monster, and I think I should be off
[17:50] <fwereade> niemeyer, have a very happy christmas with much joy and adequate sleep -- see you in the new year, I expect :)
[17:50] <niemeyer> fwereade: UnitsMachine and ControlMachine?
[17:51] <fwereade> niemeyer, ...ambivalent, I will take those under consideration :)
[17:51] <niemeyer> fwereade: With int flags, so we can tweak names over time as we see fit
[17:51] <niemeyer> fwereade: Thanks a lot man :-)
[17:51] <fwereade> niemeyer, ok, sounds sensible
[17:51] <niemeyer> fwereade: Have a great break as wel
[17:51] <niemeyer> l
[17:51] <fwereade> niemeyer, always a pleasure, take care :)
[17:52] <niemeyer> fwereade: Tell Laura there's a little friend coming
[17:52] <niemeyer> fwereade: ;_)
[17:52] <fwereade> niemeyer, will do :)
[17:52] <niemeyer> fwereade: I'll just have to make an effort for them to be able to communicate :_0
[17:52] <niemeyer> :-)