billymg: test2
billymg: ok, that's back
billymg: the one (luckily) dropped line, right after this line: <asciilifeform>: signpost: actually last asciilifeform knew, kernel used 0 gcc5isms or anyffin of the kind. would actually be surprised if didn't build w/ tcc even nao w/out heavy massage.
bitbot: Logged on 2022-01-30 04:05:17 signpost[asciilifeform]: afk
asciilifeform: ty billymg !
signpost[asciilifeform]: asciilifeform: interesting, that might be worth an experiment
asciilifeform: signpost: pretty sure all of my current kernels built w/ 4.9. not tried tcc tho
signpost[asciilifeform]: they did add a requirement for gcc-5.1.0 very recently, but before that 4.9 works
signpost[asciilifeform]: https://github.com/torvalds/linux/commit/76ae847497bc5207c479de5e2ac487270008b19b
signpost[asciilifeform] has been collecting these for an eventual pentacle poast
signpost[asciilifeform]: 5.14 is recent enough that backporting drivers wouldn't be nightmare, though.
awt[billymg|asciilifeform]: asciilifeform: in the common prologue there is perhaps a missing case: that of the first direct or broadcast message received, which will have no antecedent. These messages should not be added to the order buffer.
asciilifeform: indeed
awt[asciilifeform|billymg]: I believe this requires that we check for and reject any subsequent messages from a handle with a 0x00 self chain value that has already been seen.
asciilifeform: awt: why would this require a special case?
asciilifeform: if you've been seen, there's a handle chain for you
asciilifeform: and subsequent appearance of same handle 'as if born' are obv. bogus.
awt[billymg]: So assume we have received first message from alice. Alice sends a second message with selfchain = 0x00. Antecedent check by selfchain is pointless since 0x00. Then we have to check ... long buffer? for any previous messages from Alice. If there are, reject.
asciilifeform: awt: which variant of algo are we discussing ? cuz under this one, it's trivial
asciilifeform: i.e. we know whether we've already seen a speaker 'alice', at all times
awt[asciilifeform]: this one: http://www.loper-os.org/pub/pest/pest_draft.html#431-common-prologue-for-all-packets
asciilifeform: imho that one oughta go, and replace w/ above
asciilifeform: on acct of this and other gnarl cases
asciilifeform sadly not had chance to write variant of draft w/ the algo proposed above just yet, hands 100% full
awt[billymg|asciilifeform] will perhaps skip this case for now then
awt[asciilifeform] is eager to release some working version of GetData for the sake of log integrity
asciilifeform: awt: imho the Right Thing re getdata is to search the in-memory buffers 1st, followed by disk log (down to a time T set by operator)
asciilifeform: the handling of getdata's i dun expect will change much in following revs of spec
awt[asciilifeform]: yeah currently implementing LongBuffer
awt[billymg]: released blatta stores it all in the log table - pretty messy
asciilifeform: if you 1) received a getdata 2) have $msg 3) have spare cpu cycles -- you send the msg to the requester.