tynet-lichat/shirakumo - IRC Chatlog
Search
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: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: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: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:13:13
SAL9000-
afaik this *is* one of the use-cases where submodules actually make sense for once :P
13:18:06
SAL9000-
well, you currently have lichat = the website, lichat-protocol = the spec + CL impl
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
14:00:41
shinmera
Now that we have a separate repo for the spec, I can also finally tear the shirakumo extensions out of the core document.
14:03:23
Colleen
Shinmera: fyi parsed-protocol pylichat is broken; trying to figure out how to fix it
14:03:23
SAL9000
Shinmera: fyi parsed-protocol pylichat is broken; trying to figure out how to fix it
14:07:49
Colleen
it doesn't get through the defclass step because it ends up giving arguments to Object.__init__ which it doesn't like
14:07:49
SAL9000
it doesn't get through the defclass step because it ends up giving arguments to Object.__init__ which it doesn't like
14:11:12
Colleen
I think the real problem is that the inheritance chain doesn't go through the Update class (as defined manually in Python) anymore
14:11:12
SAL9000
I think the real problem is that the inheritance chain doesn't go through the Update class (as defined manually in Python) anymore
14:13:07
Colleen
we either need to special case the update base class, or make it inherit from "baseupdate" or something that defines the fundamental behaviors but not any fields
14:13:07
SAL9000
we either need to special case the update base class, or make it inherit from "baseupdate" or something that defines the fundamental behaviors but not any fields
14:14:20
shinmera
So I think we need to rename the base class we have and move the defaulting of the id and clock fields to the client
14:15:05
Colleen
My changes to fix __init__ might be worth keeping -- I tried "consuming" the keyword arguments before passing them down
14:15:05
SAL9000
My changes to fix __init__ might be worth keeping -- I tried "consuming" the keyword arguments before passing them down
14:22:10
Colleen
Shinmera: Unsupported update type: %Symbol{name: "CHANNEL-INFO", package: "SHIRAKUMO"}
14:22:10
SAL9000
Shinmera: Unsupported update type: %Symbol{name: "CHANNEL-INFO", package: "SHIRAKUMO"}
14:32:30
SAL9000-
shinmera: seems to be OK although something is screwy with backfill... does tynet send the backfill echo update yet?
14:41:00
SAL9000-
I found the issue -- I was aliasing in output but not input, so the client gets "lichat:backfill" and doesn't grok it.
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: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: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
16:27:03
SAL9000-
I'm guessing there still haven't been any further disconnects on your test client?
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: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: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
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