tynet-lichat/shirakumo - IRC Chatlog
Search
Saturday, 15th of January 2022, 14:44:09 UTC
14:45:55
shinmera
Ugh, github odesn't render html pages
14:47:08
shinmera
eh, gonna take care of a nice rendering of the spec pages some other time.
14:47:24
SAL9000-
fix is ready, committing+pushing :)
14:48:04
shinmera
Feel free to merge into master if things work
14:48:55
SAL9000-
I'm guessing we have to keep the shirakumo==lichat workaround for now?
14:49:39
SAL9000-
pushed to branch -- please test and take a look. I'm not happy with *how* that workaround is done, tbh, hacking up the wire.py reader...
14:49:43
shinmera
the idea is to update all clients to use the correct naming with the alias first
14:49:49
shinmera
and then later remove the alias on everything at once.
14:51:15
shinmera
uuh oh boy, I guess I hadn't pushed everything yet somehow
14:51:35
SAL9000-
...that would explain the brokenness
14:52:45
shinmera
Well part of it anyhow.
14:53:07
shinmera
I also have the subtree merge in here
14:53:20
SAL9000-
that was already pushed tho?
14:53:39
SAL9000-
push to another branch, I'll take a look
14:53:49
shinmera
Nah i'll just throw my shit
14:54:18
shinmera
Oooh, wait, rebase was set to master by default
14:54:23
shinmera
that was what was trippin'
14:54:37
SAL9000-
are you using git cli or...?
14:54:50
shinmera
but my fingers are fast and loose
14:55:03
SAL9000-
ah. I was gonna say, magit handles pushRemote vs upstream very nicely
14:56:33
shinmera
Re workaround, I would have just done package_table['shirakumo'] = find_package('lichat') in symbol.py
14:57:13
SAL9000-
symbols still get ('shirakumo', 'foo') because intern doesn't know about your aliasing
14:58:04
SAL9000-
if we wanted to get fancy we could have package_table['lichat'].__name__ = 'lichat' then intern can look *that* up and obey the alias but it felt like a bit much for this hack
15:03:49
SAL9000-
shinmera: so wdyt, parsed-protocol ready for merge?
15:04:05
shinmera
I pushed a minor cleanup
15:04:39
shinmera
but yeah, otherwise looks good imo
15:04:46
SAL9000-
uhhh you want everything inheriting directly from LichatObject?
15:04:51
SAL9000-
not sure what the point of that would be
15:04:58
shinmera
It was that way before.
15:12:59
SAL9000-
shinmera: LichatObject already inherits from object (because everything eventually inherits from object), so no need to duplicate that
15:16:15
Colleen
huh, looks like the MRO already "does the right thing" despite us throwing "duplicate" inheritance into the mix
15:16:15
SAL9000
huh, looks like the MRO already "does the right thing" despite us throwing "duplicate" inheritance into the mix
15:17:41
SAL9000-
shinmera: pushed. anything else before we merge?
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, 2:44:09 UTC