asciilifeform: meanwhile in the analogue room -- asciilifeform already found a logical boojum in sync demo -- will not fetch tails for chans where nuffin was proposed to drop. ( easy to fix, but i've not enuff wake-hours atm to do it just nao )
asciilifeform: lobbes i'ma mirror your sigs when i wake up
asciilifeform: this is all that asciilifeform presently has to say on the subj.
asciilifeform: folx having a few spare min and a logotron staging box, are invited to experiment (oughta be safe even on a production box, this proggy does not write to db.)
asciilifeform: ( a 'tail', if this is not clear from thread, refers to a set of lines offered by a given peer for a given chan from a particular starting index, to the present time. )
asciilifeform: no attempt is yet made to determine if two peers offer same tail (they will differ, guaranteed, in timestamps, but ought not elsewise. but this is not touched yet.)
asciilifeform: if two peers offer the same length of tail, the peer with the higher priority (indicated by order of mention in config) is chosen.
asciilifeform: to stdio is written the progress of loads from peers (incl. how many lines of 'tail' obtained from each.)
asciilifeform: output also contains comments to show where begin blocks of proposed discards ; where -- imports (and from what peer, to what chan.)
asciilifeform: output seems to behave correctly in re uniturds but this again needs careful test.
asciilifeform: instead picked a reasonable format where 'DEL;chan;idx;' proposes the removal of a line; 'ADD;chan;...' (with ... as in traditional raw dumps currently) proposes an import ; and # signifies comment until newline.
asciilifeform: i considered to make it shit out edible sql dump; but then realized that i have nfi how to guarantee sanity re uniturdism in these.
asciilifeform: absolutely NOT ready for battlefield, requires tests (using eyes and hands.)
asciilifeform: lobbes: if you want to emphasize that it's a mp-endorsed castle, put the deed in the chan subjline like in #a.
asciilifeform: lobbes: #lobbes is imho preferable to the other. (seems to be the de-facto standard presently)
asciilifeform: even the 6, i found will spill on some very small screens
asciilifeform: sumthing clever ~will~ have to be done w/ the header , 7 might even fit right nao, but 8 defo won't..
asciilifeform: lobbes: i dun have any problem w/ including your castle ( is it properly proclaimed castle via mp yet ? btw ? ) -- tho may have to fiddle w/ the htmlism so all 7 actually fit in the header . lemme know when yer ready to deed a signed copy of the archival log for it, to be eaten.
asciilifeform: lobbes do you want it logged by the orchestra ?
asciilifeform: incidentally, lobbes seems to have made a 7th ?
asciilifeform: atm the hand-operated sync only feels practical because there is very little traffic in most of the chans. if all 6 were burning hot 24/7 , could take many hrs of frustrated cranking to actually sync'em all.
asciilifeform: diana_coman: if one or more of the peers contains the truthful record of the interval, the 'longest' algo will select that peer.
asciilifeform: diana_coman: entirely correct, re disconnected bot ; though someone may speak ~as it reconnects~
asciilifeform: (a) may be violated if one of the loggers is not merely missing lines but is in some way broken .
asciilifeform: (b) may potentially be violated during any given shot .
asciilifeform: (c) in particular may be violated if there are recently imported (from peer loggers) lines in the db .
asciilifeform: so, to complete the picture, this algo is guaranteed to work correctly if a) one of the peers actually contains the complete log segment for time T .. present b) no one speaks in the interval while it operates c) the timestamp T correctly represents the cutoff
asciilifeform: diana_coman: idea is to sync all chans , rather than having to fire per-chan.
asciilifeform: et of loggers that returned valid outputs 7) eats.
asciilifeform: diana_coman: aite. proposed algo , is a manually-triggered item that 1) takes a 'breakage point', i.e. last known correctly logged line represented by tuple [chan, index] . 2) finds its timestamp 3) drops errything in db postdating said timestamp 4) walks list of peer loggers, fetches for each enabled chan, errything from last-known-idx i to i+500 5) 4 is repeated until returns <500 6) then takes the ~longest~ such result, from the s
asciilifeform: there's of course a set of much later converts there, via the usa conquest, but these have sumthing like proper translations.
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-10-03#1939710 << funnily enuff, the crypto-christians left behind in jp after missionaries expelled, mutated into such a bizarre fork chain that modern church does not recognize'em as anyffin at all ( they mutter unrecognizable chants , which at some pt in 17th c were latin , from phonetic crib sheets to this day... but elsewise resemble 'insular buddhist sect' very closely )
asciilifeform: ( and chix, but from designated breeding grounds which afaik at no pt included wallachia & co )
asciilifeform reminds readers that he is not in any capacity in tbf and cannot formally nominate anyone . matter is entirely in hands of mod6 , tho he'd be wise to consult mp re wat-do imho.
asciilifeform wonders whether bvt , trinque , hanbot, or spyked might want the job
asciilifeform: !Qlater tell trinque do you think you can get ben to reappear for long enuff to properly appoint tbf successor ? cuz imho a heavy bag o'coin attached to a beheaded tbf is unseemly and the orig charter offers no gc mechanism for it
