tynet-lichat/shirakumo - IRC Chatlog
Search
Saturday, 15th of January 2022, 15:39:30 UTC
16:26:44
SAL9000-
shinmera: merged & pushed
16:27:03
SAL9000-
I'm guessing there still haven't been any further disconnects on your test client?
16:27:29
SAL9000-
Please do so; I'd love to be able to say that the bug is probably gone...
16:28:04
shinmera
Doesn't look like it. Only DC is that one time the server rebooted
16:28:34
SAL9000-
Any messages in the debug logs matching "timeout, sending ping" ?
16:29:56
shinmera
Yes, one time, though I think that's the server DC.
16:30:46
SAL9000-
Hm. So, either the external circumstances haven't reoccurred, or the bug is truly gone and not because of the client-ping workaround.
16:45:34
shinmera
ugh, don't really want to figure out the Java library
16:46:53
shinmera
Gonna have to do codegen
16:47:24
SAL9000-
for parsed-spec in the Android app?
16:47:29
SAL9000-
uh... good luck with that.
16:47:43
shinmera
Gonna write a Lisp script to spit out Java code probably.
16:47:53
SAL9000-
probably the easiest way, yeah
16:48:23
shinmera
Only issue is that the current library took some extra steps to parse update data structures into maps and other things that are more pleasant for general use
16:48:39
shinmera
which I can't codegen without significant effort
16:49:43
SAL9000-
so... either special-casing in the codegen, or a "post-processing" layer?
16:49:58
shinmera
I'm thinking ignoring certain classes when codegenning.
16:50:08
SAL9000-
and having those be handwritten instead?
16:50:56
SAL9000-
that'd work too... maybe have a "handwritten.sexpr" representing the state of those classes, which gets compared to spec/*.sexpr?
16:51:22
SAL9000-
"error: handwritten class Message needs to be updated due to changes in the spec" etc.
17:25:34
shinmera
SAL9000-: :shepface: https://github.com/Shirakumo/jLichat/blob/master/src/main/java/org/shirakumo/lichat/CL.java#L30
17:26:31
shinmera
Yeah. I had a nice self-contained solution but no
17:38:15
shinmera
:cripes: why is it so hard to get a ref to the java source file path augh.
18:04:54
Colleen
sorry. i wanted to see how :cripes: renders in the js client
18:04:54
scymtym
sorry. i wanted to see how :cripes: renders in the js client
18:15:27
shinmera
I forgot about another issue
18:15:31
shinmera
Java doesn't have multiple inheritance
18:50:04
shinmera
Emacs really does not like having java source-code-like stuff inside strings
18:54:59
Colleen
Shinmera: looks like there's a bug in the backfill implementation -- it sends updates with :id "123" rather than :id 123
18:54:59
SAL9000
Shinmera: looks like there's a bug in the backfill implementation -- it sends updates with :id "123" rather than :id 123
18:55:51
Colleen
I thought I was going nuts for a while there, seeing Python seemingly failing at comparing numbers :D
18:55:51
SAL9000
I thought I was going nuts for a while there, seeing Python seemingly failing at comparing numbers :D
18:56:12
shinmera
Iirc strings are allowed as IDs.
18:56:32
Colleen
yes but it's casting existing updates' IDs to strings when backfilling them
18:56:32
SAL9000
yes but it's casting existing updates' IDs to strings when backfilling them
18:57:35
shinmera
It does so on purpose, since it needs to stuff things into a table
18:58:13
Colleen
so... ids should always be string-compared rather than type-aware-compared, then?
18:58:13
SAL9000
so... ids should always be string-compared rather than type-aware-compared, then?
18:58:19
shinmera
though at this point I'd be fine with specifying ID to be a subtype of integer.
18:58:32
Colleen
you could serialize the wire representation rather than the value
18:58:32
SAL9000
you could serialize the wire representation rather than the value
18:58:32
shinmera
no client currently uses strings
18:59:02
Colleen
current workaround: I cast both ids to str for comparison
18:59:02
SAL9000
current workaround: I cast both ids to str for comparison
18:59:29
shinmera
I'm tending towards the subtype.
Sunday, 16th of January 2022, 3:39:30 UTC