todo.txt


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


discord and quaddle hard-depend on the configured url ending with a /
note that http does not conflate // into / in the path.

at least for nanochat, multiple coros interact with the socket.  a little work has been done to lower the chances of one yielding and then another trying to do things and reading stuff meant for the other one, but it's a race condition.  there is no way to do a write() then read() without a potential race condition, or magically knowing how much to read exactly.  so, the socket should be directly controlled by a single thread of execution, then the recv and send coros should interact with that via *>An Interface<* (robotic voice) (i.e. wrap the protocol away into a protocoller and the pylon only deals with the messages and not lower details)


2026-09-15 13:47:16+0100 error [xmpp-olive] ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
2026-09-15 13:47:16+0100 error [(toplevel)] 👉xmpp-olive ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
stack traceback:
	./xmpp/pylon.lua:98: in function 'xmpp.pylon.recving'
lua5.4: 👉(toplevel) 👉xmpp-olive ./xmpp/pylon.lua:98: attempt to call a string value (local 'x')
stack traceback:
	./xmpp/pylon.lua:98: in function 'xmpp.pylon.recving'
stack traceback:
	[C]: in function 'error'
	./log.lua:42: in function 'log.loop'
	./pylon.lua:30: in function 'pylon.run'
stack traceback:
	[C]: in function 'error'
	./log.lua:42: in function 'log.loop'
	main.lua:71: in method 'run'
	main.lua:78: in main chunk
	[C]: in ?

yielding() iterator inside of cqueues where the iterator uses cqueues read inside of itself mayyy be causing issues??  rebecca says no it's using the proper cqueues coro wrapper.