freenode/#shirakumo - IRC Chatlog
Search
12:08:56
Shinmera
Did some fixes to reduce allocations in trial/kandria today. Some pretty easy targets.
12:09:21
Shinmera
Also seems like, as expected, the most amount of time is spenti in SCAN (collision handling), so optimising that should give a big boon.
12:12:00
Shinmera
Predictably also, 3dv/m are also big allocation targets. Really need to figure out how to reduce intermediary products and allow stack allocation in the next version of those.
12:12:55
Shinmera
A big problem in DX is that in order to declare DX the binding needs to be assigned the allocation form, rather than some form that returns the allocated object.
12:13:23
Shinmera
won't work, because the allocation form of the v+ product is not first assigned to foo.
12:14:50
Shinmera
The only solution I can see is to have a special let that can do some code walking and rewrite it into proper form for you
12:22:19
Shinmera
I use it for marketing and community management these days, so losing it would be a bigger problem for me.
12:24:33
mfiano
The closest that makes sense is attempting to join a server that has engaged in spam in the past
12:32:57
Shinmera
That's such a weird policy. You could honeypot people you don't like that way and get them banned.
12:34:08
mfiano
Yeah, apparently they keep honeyp[ot servers up to lessen their load with unsuspecting users. I'll add that to the long list of shady practices
14:23:22
SAL9000
mfiano: good to know... I've gotten suckered deep into the discord ecosystem due to friends who ONLY communicate that way. Guess it's time to set up alternative channels for when we all get banned for talking too much Lisp or something :-)
14:28:27
selwyn
i play a text based game which used to have its own irc server with a huge following up until fairly recently
14:39:12
Shinmera
I really hate that discord calls what are essentially groups 'servers'. Creates so much unnecessary confusion.
14:41:53
Shinmera
Also Lichat has the same kinda thing with the channel trees extension, though in the form of (imo) a much nicer generalisation.
14:59:19
SAL9000
discord 'servers' were originally referred to as 'guilds', before their pivot from game-oriented communication
15:00:43
SAL9000
unless you want to pipe it through the server, welcome to NAT hole-punching, STUN, TURN etc. etc.
15:06:23
Shinmera
also wrt e2e group chat, it seems signal just multicasts your message by encrypting it for each member in turn.
15:08:18
Shinmera
https://security.stackexchange.com/questions/126768/which-protocols-exist-for-end-to-end-encrypted-group-chat
15:08:18
Colleen
security.stackexchange.com/... Website (HTML), Title: encryption - Which protocols exist for end-to-end encrypted group chat? - Information Security Stack
15:14:08
Shinmera
reading this and the linked post on the signal blog I'm gonna deem E2E in lichat "infeasible"
18:07:38
SAL9000
Shinmera: let's start shoving all the data into a class -- maybe a subclass of pylichat.Client -- so we're ready for multi-server
18:09:04
Shinmera
I'd go with composition. We're not really extending the client with anything here.
18:10:12
SAL9000
OK, so a "server" class representing one Lichat connection. Maybe a buffer class representing per-buffer state as well.
18:11:05
SAL9000
yeah, except for an unstaged my_buffers = CaseInsensitiveDict() but that'd be refactored anyway
18:11:35
SAL9000
buffer-to-Buffer mapping should *not* be case insensitive, but channel-to-Buffer should be.
18:13:08
SAL9000
if we want to be fancy, Python's "descriptors" let us make instance.foo = bar become a method call
18:14:14
SAL9000
If it wasn't expressly "forbidden" by a message on the script site, I'd suggest a py-weechat wrapper lib to hide away the C crap
18:17:51
SAL9000
while you're refactoring, you can dike out the redir_id_to_buffer mechanism now that we have that in py-lichat
18:19:13
SAL9000
also, I think we should store sent ids whether they have a callback or no -- for tracking lag in Client
18:19:43
SAL9000
the API can still be relatively clean if we delete the data *after* running the normal update callbacks
18:20:33
SAL9000
i.e. inside the handle-callback for a given update type, client.relatedUpdate(update) => the one you sent, or the one the failure is about
18:21:38
SAL9000
Currently, the library user has to explicitly request to be notified about the response to an update, right?
18:22:20
SAL9000
I'm suggesting a different API contract, where the library always tracks sent updates, and the library user can request that information up until it's deleted; which would occur at the very end of Client.handle
18:22:58
SAL9000
then, the library user can add a handler to Update, where the sent and received timestamps are compared -- thus giving lag estimates