tynet-lichat/shirakumo - IRC Chatlog
Search
Saturday, 15th of January 2022, 1:23:10 UTC
6:43:46
shinmera
Yes, almost. I had to make two particular hacks in the lichat one
6:43:57
shinmera
1) it needs a mode where it'll intern symbols instead of replacing them with unknowns
6:44:20
shinmera
2) it needs a temporary hack to alias the shirakumo package with the lichat package, since currently all clients and servers do that
6:50:19
shinmera
err, in the lisp one
8:06:01
shinmera
Oh and I forgot to mention but in my sleep addled brain I could not figure out how to implement define-object-extension
8:06:09
shinmera
(I still can't without complicated mop fuckery)
8:35:38
shinmera
Also just noticed the lichat server is eating 200% CPU? what in the fuck
8:44:09
shinmera
Anyway, guess I have to restart that server
8:46:30
shinmera
The patches for backfill etc. are in now at least
8:46:41
shinmera
and I have a thing I can use to debug performance problems like this in the future
8:47:02
shinmera
Or, not performance, but likely some bad recursion?
10:57:36
shinmera
Aight, changed the js client to auto-gen the objects.
10:57:42
shinmera
Still kludgy on that end, too, though.
13:02:25
shinmera
SAL9000-: https://github.com/Shirakumo/py-lichat/tree/parsed-protocol
13:03:18
shinmera
That's 3/4 clients (beta) updated
13:03:37
SAL9000-
shinmera: the sexpr files should *probably* be a submodule instead though?
13:08:59
shinmera
I kinda want to separate the lichat protocol definition from the CL lichat package, but not sure yet if I should.
13:09:10
shinmera
err, repo, not package
13:10:29
SAL9000-
having the reference implementation in the same repo as the machine-readable spec *kinda* makes sense?
13:11:08
shinmera
It long ceased being that though and has some peculiarities that don't translate well
13:11:25
shinmera
Like using native packages and symbols
13:11:47
SAL9000-
in that case, moving the CL implementation out would leave a repo with the human-readable spec + the machine-readable spec, which is also a good combination
13:11:50
shinmera
I also just don't really like a spec being associated with code.
13:12:24
SAL9000-
then the spec can be a submodule (or subtree) in each of the implementations, representing the version of the spec that the implementation supports
13:12:39
shinmera
Subtree would be my preference
13:13:13
SAL9000-
afaik this *is* one of the use-cases where submodules actually make sense for once :P
13:13:28
SAL9000-
(but then you have to git clone --recursive or similar)
13:14:00
shinmera
kinda, but subtree works better imo
13:16:49
SAL9000-
would you be squashing the history of the subtree or not?
13:17:35
shinmera
We'll figure that out once the repos are separated
13:17:44
shinmera
My problem is I don't know what to call the pure-spec one
13:18:06
SAL9000-
well, you currently have lichat = the website, lichat-protocol = the spec + CL impl
13:18:18
SAL9000-
maybe lichat-cl = CL impl, lichat-protocol = the spec ?
13:19:27
shinmera
Renaming the cl part would create a kerfuffle
13:20:07
SAL9000-
as in you'd want to rename the packages as well as the repo?
13:20:22
shinmera
ideally yes, which would break code
13:20:28
shinmera
but even if not, it would require changing ql
13:21:07
shinmera
I wouldn't mind changing lichat/master to lichat/web or whatever, and then making master be the spec
13:21:55
SAL9000-
hm... that makes subtree more of a requirement to avoid pulling in web along with spec I guess
Saturday, 15th of January 2022, 13:23:10 UTC