[08:47] <Chipaca> morning!
[09:16] <niemeyer> Hallo!
[10:15] <Chipaca> there's so much neat code in charmhelpers
[11:00] <Facu> Muy buenos días a todos!
[11:32] <Chipaca> Facu: heyy
[11:33] <Facu> Chipaca, holas
[12:07] <Chipaca> niemeyer: could you take another pass at the testing pr? it seems good to go from where i stand
[12:07] <Chipaca> Facu: ditto, wrt docstrings pr
[12:08] <Facu> Chipaca, sure
[12:55]  * Facu is fighting juju error units... not in his charm, but in postgresql!!
[12:57] <Facu> stupid postgresql
[12:57]  * Facu kills the unit and re-deploy
[13:07] <Chipaca> $ make
[13:07] <Chipaca> Please add copyright headers to the following files:
[13:07] <Chipaca> ./.git/logs/refs/remotes/jameinel/document-charm.py
[13:07] <Chipaca> (and so it goes on)
[13:07] <Chipaca> sigh
[13:09] <Facu> Chipaca, not with my branch ;)
[13:31] <Chipaca> late late late late
[14:14] <Chipaca> Facu: 2020-03-12 12:33:05 <Chipaca> Facu: wrt PrefixedEvent (and thanks to Dmitrii-Sh for pointing this out) means you do self.on["dumper"] and you get a PrefixedEvent that has non-prefixed events on it
[14:32] <Chipaca> Facu: that's local time for me, ie GMT
[14:35] <Chipaca> Facu: https://irclogs.ubuntu.com/2020/03/12/%23smooth-operator.html#t12:23 FWIW
[14:42] <Facu> Chipaca, I missed that, thanks
[15:09] <Facu> Chipaca, so, regarding the change of what an Interface could do to hook into the events through the charm...
[15:09] <Facu> we brought from Frankfurt the idea of doing...
[15:09] <Facu>     mysql_relation_events = charm.on.relation_events_for(mysql_relation_name)
[15:09] <Facu>     self.framework.observe(mysql_relation_events.joined, self._client_joined)
[15:09] <Facu> I changed it a little to be able to not have different methods for the different event types...
[15:09] <Facu>     mysql_relation_events = charm.on.events_for(relation=mysql_relation_name)
[15:09] <Facu>     self.framework.observe(mysql_relation_events.joined, self._client_joined)
[15:09] <Facu> But we really can do this *now*...
[15:09] <Facu>     mysql_events = charm.on[mysql_relation_name]
[15:09] <Facu>     self.framework.observe(mysql_events.relation_joined, self._client_joined)
[15:09] <Facu> So don't know if the change is worthwhile...
[15:10] <Facu> it looks a little weird accesing 'on' as a dictionary
[15:10] <Facu> we totally could add a method 'get_events_for' which is really __getitem__
[15:10] <Facu>     mysql_events = charm.on.get_events_for(mysql_relation_name)
[15:11] <Facu>     self.framework.observe(mysql_events.relation_joined, self._client_joined)
[15:13]  * Facu wonders if he should open an issue about this
[15:20] <Chipaca> Facu: the on being a dictionary-ish thing was a surprise, indeed
[15:20] <Chipaca> sorry, was getting coffee :-)
[15:20] <Chipaca> Facu: how does that appear in documentation?
[15:20] <Chipaca> i'd expect an explicit method to be more obvious
[15:21] <Chipaca> it's also unclear what .keys() or .values() would be used for in this dictionary :-)
[15:22] <Facu> Chipaca, right, it's interesting to define if we *really* want to present it as a proper dict
[15:23] <Chipaca> it has that cool-look-what-i-can-do feeling :-)
[15:24] <Chipaca> Facu: but it'd be interesting to see it in use
[15:29] <Chipaca> Beret: see? it works :-D
[18:13] <Chipaca> whole computer feels sluggish, and on closer inspection the freq is stuck at 800MHz or under
[18:39] <Chipaca> brb going to reboot into an older kernel to see if it's #22 that's breaking the freq
[20:22]  * Facu eods