libera/#shirakumo - IRC Chatlog
Search
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
16:27:03
Colleen
<SAL9000-> I'm guessing there still haven't been any further disconnects on your test client?
16:27:29
Colleen
<SAL9000-> Please do so; I'd love to be able to say that the bug is probably gone...
16:30:46
Colleen
<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
Colleen
<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:49:43
Colleen
<SAL9000-> so... either special-casing in the codegen, or a "post-processing" layer?
16:50:56
Colleen
<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
Colleen
<SAL9000-> "error: handwritten class Message needs to be updated due to changes in the spec" etc.
17:25:35
Colleen
<shinmera> SAL9000-: :shepface: https://github.com/Shirakumo/jLichat/blob/master/src/main/java/org/shirakumo/lichat/CL.java#L30
17:38:15
Colleen
<shinmera> :cripes: why is it so hard to get a ref to the java source file path augh.
18:50:04
Colleen
<shinmera> Emacs really does not like having java source-code-like stuff inside strings
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
SAL9000
I thought I was going nuts for a while there, seeing Python seemingly failing at comparing numbers :D
18:58:19
Colleen
<shinmera> though at this point I'd be fine with specifying ID to be a subtype of integer.