libera/#shirakumo - IRC Chatlog
Search
6:43:57
Colleen
<shinmera> 1) it needs a mode where it'll intern symbols instead of replacing them with unknowns
6:44:20
Colleen
<shinmera> 2) it needs a temporary hack to alias the shirakumo package with the lichat package, since currently all clients and servers do that
8:06:01
Colleen
<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:46:41
Colleen
<shinmera> and I have a thing I can use to debug performance problems like this in the future
13:03:37
Colleen
<SAL9000-> shinmera: the sexpr files should *probably* be a submodule instead though?
13:08:59
Colleen
<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
Colleen
<SAL9000-> having the reference implementation in the same repo as the machine-readable spec *kinda* makes sense?
13:11:08
Colleen
<shinmera> It long ceased being that though and has some peculiarities that don't translate well
13:11:47
Colleen
<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
Colleen
<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
Colleen
<SAL9000-> afaik this *is* one of the use-cases where submodules actually make sense for once :P
13:18:06
Colleen
<SAL9000-> well, you currently have lichat = the website, lichat-protocol = the spec + CL impl
13:21:07
Colleen
<shinmera> I wouldn't mind changing lichat/master to lichat/web or whatever, and then making master be the spec
13:21:55
Colleen
<SAL9000-> hm... that makes subtree more of a requirement to avoid pulling in web along with spec I guess
14:00:42
Colleen
<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
SAL9000
Shinmera: fyi parsed-protocol pylichat is broken; trying to figure out how to fix it
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:10:22
Colleen
<shinmera> Still odd that it complains? it should do the same thing as it did before
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
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:13:45
Colleen
<shinmera> you could define an object that's not an update, and doesn't carry id/clock/from
14:14:20
Colleen
<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
SAL9000
My changes to fix __init__ might be worth keeping -- I tried "consuming" the keyword arguments before passing them down
14:22:10
SAL9000
Shinmera: Unsupported update type: %Symbol{name: "CHANNEL-INFO", package: "SHIRAKUMO"}
14:32:30
Colleen
<SAL9000-> shinmera: seems to be OK although something is screwy with backfill... does tynet send the backfill echo update yet?
14:41:00
Colleen
<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:47:08
Colleen
<shinmera> eh, gonna take care of a nice rendering of the spec pages some other time.
14:49:39
Colleen
<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
Colleen
<shinmera> the idea is to update all clients to use the correct naming with the alias first
14:56:33
Colleen
<shinmera> Re workaround, I would have just done package_table['shirakumo'] = find_package('lichat') in symbol.py
14:57:13
Colleen
<SAL9000-> symbols still get ('shirakumo', 'foo') because intern doesn't know about your aliasing
14:58:04
Colleen
<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
Colleen
<SAL9000-> shinmera: LichatObject already inherits from object (because everything eventually inherits from object), so no need to duplicate that
15:16:15
SAL9000
huh, looks like the MRO already "does the right thing" despite us throwing "duplicate" inheritance into the mix