Show Idle (>14 d.) Chans
← 2022-12-04 | 2022-12-06 → ↓
whaack[asciilifeform]: anyone here have some good Spanish reading material?
asciilifeform: whaack: e.g. g. g. marquez if you haven't yet.
signpost[asciilifeform]: woke up loving the sexpr message format even more; harkens back to threads about building a proper www.
signpost[asciilifeform]: can have for example proper transclusion without worrying about referenced material disappearing.
signpost[asciilifeform]: extension mechanism's also obvious and tidy, can import packages of symbols like any respectable little lisp.
phf[asciilifeform]: we had a thread on sexps as interchange format, http://btcbase.org/log/2017-11-21#1741761
phf[asciilifeform]: well, it was a very brief thread, and everyone came out thinking exactly as they did before. the conclusion was that only "tits" were the acceptable interface out of the box, and that mp even patches those.
phf[asciilifeform]: i maybe wasn't articulate on the point, but i still think that sexps make for a poor interchange format (and neither bolix nor cadr used them for that)
signpost[asciilifeform]: phf could you restate your critique? I'll attempt badly. "one would have to constrain their definition of sexpr so much that it approaches or even exceeds bothering to design a proper interchange format" ?
signpost[asciilifeform]: and this leaves aside things like efficient wire protocol packing
phf[asciilifeform]: yah, basically
signpost[asciilifeform]: reasonable imho
signpost[asciilifeform] likes "here's this little space with tidy structures and symbolic reference" and isn't married to the representation
phf[asciilifeform]: once you start restricting sexps for practical serialization use, you end up either with something like json or something close to ASN
phf[asciilifeform]: out of the box lisp sexps are a turing complete set of human computer interaction conventions
phf[asciilifeform]: so you necessarily have to narrow it down to "this, here, is our sexp". at which point the question becomes, why sexp?
phf[asciilifeform]: and the fact that it's human readable/writable first also becomes a hindrence
signpost[asciilifeform]: is it the space-waste? or other problems?
signpost[asciilifeform]: what'd be an alternate way to wrap some text with being a link, bold, etc?
phf[asciilifeform]: space waste, superflous operations (like necessary implicit tokenization, which manifests in e.g. eating arbitrary whitespace) and the fact that you don't know the size of structures until you're done parsing them
signpost[asciilifeform]: right, so alternative would be encountering $opcode$length$content fields for example?
phf[asciilifeform]: you have two different approaches to packing annotated texts: inband markup and structured data encoding
phf[asciilifeform]: e.g. <b> foo bar</> vs (b " foo bar")
phf[asciilifeform]: 􏿽in first case you assume that your text is in special markup format, when you encounter special characters you treat them special, and the authoring (which better be a machine) needs to ensure that the literals get encoded, the markup is valid. in this case your structure is also i
phf[asciilifeform]: 􏿽mplicitly string, and the whitespace is significant
phf[asciilifeform]: and in the second case you don't have text you always have serialization format, which you more or less deserialize into you document object structure, and it is to some extent universal rather than specific to document object structure
phf[asciilifeform]: something like escape codes (or the informal [BOLD]foo[/BOLD] of forums/wp) are a special case of the first
signpost[asciilifeform] sees that directives like ~these *are* the exception rather than rule in pest messages
phf[asciilifeform]: i would first decide if we're doing markup or serialization
phf[asciilifeform]: and they both have obvious drawbacks or cans of worm
phf[asciilifeform]: modern™ protocols use serialization, but that's because they stick everything into their serialization format, and that's how they have message types to begin with
phf[asciilifeform]: or as ascii said "sexps all the way", (mediamessage :filename "foo" :annotation (span "here's " (b "your") " file") :hash 123)
phf[asciilifeform]: but you can put the same datastructure into something like bencode (or the whole can of worms ASN.1, hipster buffers, whatever), and get a much more compact, faster to parse on the wire object
signpost[asciilifeform]: does having outer structure (the serialization case) thwart display of partial multi-chunk messages? (and do we care?)
phf[asciilifeform]: which is your difference between e.g. jabber where it's all xml <mediamessage filename="foo" hash="123"><annotation>here's <b>your</b> file</mediamessage> versus something like telegram, where they have in house binary serialization format
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-05#1017439 << i guess it depends on where you place your layer boundaries
bitbot[asciilifeform]: Logged on 2022-12-05 11:49:41 signpost: does having outer structure (the serialization case) thwart display of partial multi-chunk messages? (and do we care?)
phf[asciilifeform]: in our case the ship has sailed, so to speak, the outer container, is binary format, with its own rules of reassembling the content, so your preferred strategy is: reassemble the multi-chunk, then deserialize the whole payload
phf[asciilifeform]: 􏿽you technically have the same problem with markup, i don't think it matters: if you have <p>fooo <b>qux</> buzz</> and your split is in qux, you necessarily either wait for the whole thing to reassemble, or you have some splitting conventions <p>fooo <b>q</></> and <p><b>ux</> buz
phf[asciilifeform]: 􏿽z</>, but how do you know to merge the p's.
phf[asciilifeform]: naggum has /a lot/ on the subject, i started re-reading some of it, https://www.xach.com/naggum/articles/3250033735497397@naggum.no.html
phf[asciilifeform]: there are some useful points there, which apply immediately to what we are discussing. “SGML is a good idea when the markup overhead is less than 2%.” is a good one
phf[asciilifeform]: from this perspective when you choose general purpose structure data encoding, your messages immediately pay the price. so all the text becomes at least "foobar", if not (p "foobar")
phf[asciilifeform]: i think naggum's idea of a markup is something like <p hello <b world> this is a bracket: \>. >
phf[asciilifeform]: he wrote about it in some other rant of his
asciilifeform likes sexpr not simply because familiar but a) writable by hand b) easily readable with naked eye c) not imposes idiotic superfluous terminating tags, as html does
asciilifeform if never again has to write by hand <b>foo</b>, won't be soon enuff
phf[asciilifeform]: i use a civilized language, don't need to "write by hand" :>
asciilifeform: rright but prolly for rather long time can expect pestrons to eat input by hand
phf[asciilifeform]: what about the rest of the wall of text!
asciilifeform: which rest of ?
phf[asciilifeform]: e.g. the difference between markup and structured data
asciilifeform: e.g. (image \x01\x02\x03\x04...) ? wats wrong with that?
asciilifeform: if client not knows how to display -- degrades gracefully, simply prints
phf[asciilifeform]: i don't know if you're written much cl-who, but i have, and i'd rather not have to juggle whitespace vs closing strings all over the place. (p "foo " (b " bar ") (i " dog ") " close.")
phf[asciilifeform]: that's not what i'm talking about though
asciilifeform would rather write by hand above than <p>...</p>. obv. would prefer not by hand, but likely for a while will be by hand
asciilifeform: phf: hm?
phf[asciilifeform]: markup is of text /annotation/, whitespace is significant, more text by weight than markup, "strings" are first class, etc.
asciilifeform: http://logs.bitdash.io/pest/2022-12-05#1017438 << imho 'parse fast' is a false god, and in particular in context of pestron, which eats over9000 cpu for decoding packets
bitbot[asciilifeform]: Logged on 2022-12-05 11:48:00 phf[awt]: but you can put the same datastructure into something like bencode (or the whole can of worms ASN.1, hipster buffers, whatever), and get a much more compact, faster to parse on the wire object
asciilifeform: whitespace is significant (outside of "") only in that need at least 1 b/w tokens, neh
phf[asciilifeform]: you're not groking what i'm saying at all
asciilifeform will have to think
phf[asciilifeform]: i'm not making an argument above, i'm setting a context. the things that i'm saying simply _are_, rather then some kind of pro or against position
phf[asciilifeform]: the question that needs to be answere is "what is our payload and why" first, before we reach for a particular solution
asciilifeform suspects that payload will be largely text, with occasional links/emphasis
asciilifeform possibly grasps phf's observation -- imposing (text "hello world") instead of hello world on erry msg is annoying
phf[asciilifeform]: but then to combine your point with mine, is something like (text "hello world " (image #x02#x01)) something that should be supported?
asciilifeform: possibly signpost's idea from yes. makes sense, and msg oughta have a prefix to indicate whether structured or raw text
asciilifeform: from yest.
asciilifeform: likely nobody will want to write these by hand.
phf[asciilifeform]: unless markup is trivial enough..
asciilifeform: even getting folx to remember, in classical logotron, that [link][legend], was tricky
phf[asciilifeform]: hello, <b world>! the <i point> that i'm making is illustrated by the picture of a cat <img images-hash>
phf[asciilifeform]: (we have better mechanisms, imho, than inline binary blobs. if you see <img foo> can simply request for foo using signpost technology)
asciilifeform: phf: lubytron only practical for direct msgs
asciilifeform: (no amt of bw would be enuff if were used in broadcasts)
phf[asciilifeform]: i'm not sure how naggum would support links, since he's anti-attribute. is it positional, or nested. can probably do <link <url http://btcbase.org> ye old logs>
asciilifeform suspects that there's no 100% satisfactory way to inband markup, will be ugly in some obvious way no matter how it is done
phf[asciilifeform]: the attribute problem exists in general, (link :url "http…" :title "xxx" "ye old logs") vs ((link (url "http…") (title "…")) …) vs (link "http…" nil …) etc.
phf[asciilifeform]: oh also (link ((url …) (title …)) …) is popular. i've encountered all four in sexp<->html common lisp packages
asciilifeform: very difficult to beat [link][legend] for hand-writability
asciilifeform: but no obv. way to generalize the compactness to all possib. payloads
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-05#1017483 << I can imagine a case where you request direct message streams from multiple parties though.
bitbot[asciilifeform]: Logged on 2022-12-05 12:41:21 asciilifeform[5]: phf: lubytron only practical for direct msgs
signpost[asciilifeform]: unless I'm dense
asciilifeform: signpost: you could. conundrum is re wat-do if none of yer direct peers have the object with $hash
phf[asciilifeform]: cl-who's (tag :attr value body…) looks the most elegant, but it's the ugliest on the code side, since your attribute collection is a state machine
signpost[asciilifeform]: ah yep. will leave that for now and stay on serialization vs markup
asciilifeform: signpost: this is likely 1 of those cases where the overhead of lubyism wins for GB+ warez, but loses for a 200kB lolcat.gif
phf[asciilifeform]: as opposed to franz's xmlutils (link ((attr value) …) body…) which is easily operated on with a destructuring-bind
asciilifeform: ( rather like phf's observation that a sexpr notation general enuff to 'encode anyffin and errything' will weigh roughly what xml weighs and be no moar hand-writable than it)
asciilifeform: would be imho a less tricky q if it were reasonably easy to bake a gui pestron and declare 'we dun need hand-writability or eye-readability', and use compact binary encoding. but it aint.. )
asciilifeform: atm seems to asciilifeform that even simple gui pestron (such that actually worx on asciilifeform's box) is a problem of a scale that dwarfs pestron per se, and even a monster like e.g. trb, in complexity
asciilifeform: this is where we end up 'paying for sins of the fathers' and the lack of standardized bolix-style sane gui knobs.
signpost[asciilifeform]: can still use the irc adapter as sin-firewall while there isn't a pest-specific UI.
asciilifeform: 'can haz sane gui' is what led asciilifeform in '07 down the 'need new os' -> 'need new iron' manhole
phf[asciilifeform]: i think we shouldn't xml, even if we're going to markup. at the very least taking naggum's suggestions is a good start
phf[asciilifeform]: hmm, so one of my packets got lost. and the immediately next packet triggered a getdata. it's since been sitting in awt's buffer, so none of my shit is coming through. i guess i should start multipeering, but still no reason for this behavior to manifest.
phf[asciilifeform]: “Remove the syntactic mess that is attributes. (You will then find that you do not need them at all.) Enclose the /element/ in matching delimiters, not the tag. These simple things makes people think differently about how they use the language.”
asciilifeform: signpost: right but then stuck with raw text and ~0 annotations and certainly can't link to old msgs inside text etc
asciilifeform: signpost: also got replay aha
phf[asciilifeform]: yeah, that was sitting in buffer for about 5 minutes
phf[asciilifeform]: and now i'm back to realtime
signpost[asciilifeform]: just got a replay on my end
signpost[asciilifeform] needs to bake phf a peering key anyway, sec
asciilifeform: phf: per pre-draft spec, no buffers, and nuffing sits, oughta improve things considerably
asciilifeform: ( will wreak havoc with append-only console like irc's tho )
asciilifeform: 99% of the point of gui-pestron is so can 'append the past'
asciilifeform: ( ^ in re this )
asciilifeform: the gui is direly needed not , imho, so can display italic text (tho would be nice) but so can dispense with the reordering delays
bitbot[asciilifeform]: Logged on 2022-12-05 13:04:00 signpost: can still use the irc adapter as sin-firewall while there isn't a pest-specific UI.
bitbot[asciilifeform]: Logged on 2022-12-05 13:04:35 phf[signpost]: hmm, so one of my packets got lost. and the immediately next packet triggered a getdata. it's since been sitting in awt's buffer, so none of my shit is coming through. i guess i should start multipeering, but still no reason for this behavior to manifest.
signpost[asciilifeform] would humbly suggest smallest step that leaves the future degrees of freedom, even if shit's hanky until a GUI is built.
asciilifeform: signpost: is the angle asciilifeform approaches the problem from, aha
asciilifeform: presently in spec did not discuss markup at all
asciilifeform: however the abolition of the reordering buffers does heavily pressure in direction of 'need gui'
asciilifeform: w/out buffering, irc frontend will be of very questionable use
asciilifeform: (of course could move the buffering mechanisms to irc frontend per se. but ugh)
asciilifeform realizes that his current approach to gui question is unpleasantly close to a 'mars mission' that won't be completed in anybody's lifetime; but presently not thought of anyffin substantially better
asciilifeform: afaik there simply aint any way to bake 'sane gui' other than 'from atoms'
signpost[asciilifeform]: looks like phf's got bespoke UI going, no?
asciilifeform: signpost: he used tk, which aint visible on asciilifeform's displays w/out a microscope lol
bitbot[asciilifeform]: Logged on 2022-11-14 13:59:57 asciilifeform[6]: signpost: neither fltk nor tk appear to have any provisions for scaling up fonts for menu, buttons, etc. i.e. hard-baked for ancient lcd
signpost[asciilifeform]: yup I know. gotta trade problems sometimes. I'd happily tilt at the dpi thing a while.
signpost[asciilifeform]: but not as if tinylib for shitting to X wouldn't be great
asciilifeform: great, except nao need to recreate 40yrs of graphics coad
signpost[asciilifeform] wagers "build to throw away" is going to happen a few more times. has happened a few times already.
signpost[asciilifeform]: just saying ain't nothin wrong with that.
asciilifeform: is rather wai ~0 meaningful progress in the field in 3+ decades -- errything gets thrown away
asciilifeform: even ye olde x11 is 'being thrown' by saboteurs, will soon (if not yet) have to be maintained trb-style
signpost[asciilifeform]: build something complicated, then ratchet simpler, has happened right here with pest spec and implementations.
signpost[asciilifeform] 100% agrees with asciilifeform's broader statement.
asciilifeform: signpost: rright, but pestron is an 'easy' system in that uses ~0 external coad
asciilifeform: atm as soon as you add graphics, end up 'unhappily marrying the os'
asciilifeform: there may be some yet-undiscovered way to cut the gui knot; but asciilifeform strongly suspects that 'patch ancient lib, past 10y of which won't even build on dulap-gentoo' aint it
asciilifeform: 'display a scrollable pane of scalable-lettered txt' ~shouldn't~ be a problem on the scale of 'design own cpu' but apparently, due to half century of cumulative retardation -- is.
asciilifeform: rather how railroad was known, as concept, long before actually took off en masse, because making rails by hand in a smithy dun scale worth a shit
phf[asciilifeform]: asciilifeform doesn't believe in tk
phf[asciilifeform]: … aaand i'm in a buffer again
phf[asciilifeform]: asciilifeform, in your workbench sample did you try setting scaling explicitly? i'm curious what was the result. uneven application? or just didn't work at all?
phf[asciilifeform]: i don't understand how awt's buffer works
phf[asciilifeform]: because the message that triggered getdata, is still not in the log. the message that it was referencing appeared already, and so did the immediate next message
phf[asciilifeform]: and i'm in the buffer again. wtf
phf[asciilifeform]: or i guess not, the packet was lost, and now i'm going to get spooled in all kinds of random ways
asciilifeform: phf: what's the canonical way to set the scaling for tk (and test) ?
asciilifeform looked, found only python examples
signpost[asciilifeform] fixing paste.deedbot.org sec
asciilifeform: phf: fwiw it appears to entirely ignore x11's dpi setting
asciilifeform: (unlike e.g. qt)
asciilifeform: by all appearances, the 'good old' parts of linux graphics stack, which actually work, seem to have been designed by '1024x768 on trinitron 4evah!' folx.
bitbot[asciilifeform]: Logged on 2022-12-05 13:48:41 asciilifeform[5]: phf: what's the canonical way to set the scaling for tk (and test) ?
asciilifeform: hmm on asciilifeform's box tk 'command not found' lol
asciilifeform defo has the lib...
phf[asciilifeform]: have you written any tk code before?
asciilifeform: but apparently not the configurator ?
asciilifeform: phf: not for yrs. but thing's supposedly installed on the box
asciilifeform will have to look with magnifying glass
phf[asciilifeform]: that's not a configurator, lol. that's a tk object in the tcl namespace
asciilifeform: a, tcl command, right
phf[asciilifeform]: you can start wish, and do for example tk scaling 10; button .foo -text "hello, world"; pack .foo -fill both
phf[asciilifeform]: and see what it does
phf[asciilifeform]: ftr it doesn't do shit on mac
asciilifeform: oh hm but looked entirely edible in phf's mac screenshit
asciilifeform: (how's that work? and maybe could replicate elsewhere)
phf[asciilifeform]: i think mac build just does the right thing™
phf[asciilifeform]: and when it gets to logs it's in an entirely random jank order
signpost[asciilifeform]: probably helps if I actually add the key on my end.
phf[asciilifeform]: no, why would you be able to? mac build uses entirely different mac native widget set
phf[asciilifeform]: how the fuck did awt's packet reordering logic went from this http://paste.deedbot.org/?id=_dg1 to this http://logs.bitdash.io/pest/2022-12-05#1017578
bitbot[asciilifeform]: Logged on 2022-12-05 14:03:07 asciilifeform[5]: oh hm but looked entirely edible in phf's mac screenshit
phf[asciilifeform]: and one of the packets is outright lost _even though it was the one that triggered getdata_
phf[asciilifeform]: so my internet is clearly working, but somehow my pest is dead. awt's station, or the path to it might be unstable, and pest is entirely unusable at the moment. i get getdata requests, and then i don't see anything in logs
phf[asciilifeform]: you're trying to get tk's x11 widgets to scale. so the hope is that maybe scaling on tk x11 actually does something
signpost[asciilifeform]: I am seeing these messages via awt
phf[asciilifeform]: you could try doing something like this, and just see if it behaves http://glyf.org/screenshots/mac-tk.png
phf[asciilifeform|asciilifeform]: here's the order of messages as i see them, notice the "
phf[asciilifeform]: notice the "getdata from awt, spooling" http://paste.deedbot.org/?id=HJMK and here's how that same log arrives to readers http://logs.bitdash.io/pest/2022-12-05#1017578
bitbot[asciilifeform]: Logged on 2022-12-05 14:03:07 asciilifeform[5]: oh hm but looked entirely edible in phf's mac screenshit
phf[asciilifeform]: and it looks like i'm back to realtime
phf[asciilifeform]: it almost like it would make sense for station operators to make the packet getdata wait time or whatever it is 0, because the mechanism is quite clearly not working
bitbot[asciilifeform]: Logged on 2022-12-05 14:10:58 phf[awt]: no, why would you be able to? mac build uses entirely different mac native widget set
asciilifeform: http://logs.bitdash.io/pest/2022-12-05#1017603 << prolly the reordering delay. and yes
bitbot[asciilifeform]: Logged on 2022-12-05 14:18:05 phf[awt]: it almost like it would make sense for station operators to make the packet getdata wait time or whatever it is 0, because the mechanism is quite clearly not working
awt[asciilifeform]: phf: is your netchain up to date?
awt[asciilifeform]: As noted previously in the logs, the order buffer is dumped to the client periodically. I set the timout high with initial sync in mind - hoping to get the largest chunks of contiguous messages.
awt[asciilifeform]: Messages within dumps should be ordered by timestamp, iirc.
awt[asciilifeform]: As also discussed previously in the logs, it might be better just to dump all contiguous messages once the missing message arrives. For an initial sync, this would mean no messages would be displayed for quite some time.
crtdaydreams[asciilifeform]: my 5c on serialization & markup. we also have to take into account e.g. whitespace between split messages, incl. potential tabulation. I tend to agree with asciilifeform, although my twist on his words is that bandwidth usage should take priority. My first thought was also
bitbot[asciilifeform]: Logged on 2022-12-05 12:30:51 asciilifeform[5]: http://logs.bitdash.io/pest/2022-12-05#1017438 << imho 'parse fast' is a false god, and in particular in context of pestron, which eats over9000 cpu for decoding packets
bitbot[asciilifeform]: Logged on 2022-12-05 12:54:08 phf[awt]: cl-who's (tag :attr value body…) looks the most elegant, but it's the ugliest on the code side, since your attribute collection is a state machine
crtdaydreams[asciilifeform]: your point that it's pyrite.
shinohai[busybot]: ATTN peers (especially d4, who complained about missing peers) I have tried testing running awt's pest on pogoplug last few weeks, and it *does work* but it has unexplained behaviour, like messages missing that appear in logs. Ran better on armv7 machine (as far as 32bit things go) so imma switch back to that in a few days
crtdaydreams[asciilifeform]: shinohai: if you need to rekey, send a smoke signal on #asciilifeform and I'll shoot some peering info your way
shinohai[asciilifeform]: my db intact just don't wanna lose touch with my peeps :)
crtdaydreams[asciilifeform]: shinohai: currently hearing you as hearsay, if you got a minute mebbe we can fix that
crtdaydreams[asciilifeform]: http://paste.deedbot.org/?id=Vzh9 this is just %at; valid for PeterL, asciilifeform, unpx and shinohai
shinohai[busybot]: crtdaydreams: Don't rekey for me just yet but ack on ur pgpgram
crtdaydreams[asciilifeform]: shinohai: wasn't rekey, just ip:port
shinohai[asciilifeform]: So far it seems common to occasionally see peers as hearsay, I had confusion over that point with awt at first but seems to work proper.
crtdaydreams[asciilifeform]: not so sure on that, mebbe a glitch with your arm issues, but running smalpest here, everytime I've had hearsay it's because my IP has changed and it hasn't auto magically updated for other peers
shinohai[busybot]: just an /at entonces
shinohai[busybot]: (But as I understand client should take care of that?)
crtdaydreams[asciilifeform]: believe it's nat config
crtdaydreams[asciilifeform]: possib. on my end
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-05#1017609 << this is not the anywhere near the initial sync. for one i don't keep netchain. i start (in violation of the spec, that's otherwise ignored) each new launch of pest with sending prod, getting latest message, and then linking my nechain off that, and selfchain of 0
bitbot[asciilifeform]: Logged on 2022-12-05 16:26:33 awt: phf: is your netchain up to date?
phf[asciilifeform]: at which point things always work, no problem. this particular situation happen when there was a packet loss on the network, and your station was trying to reconstruct missing holes
phf[asciilifeform]: so e.g. there's A *B C D E, where B didn't go through for some reason, i'll get a getdata request for a missing packet from you immediately when you get C, which is the correct behavior. things turn into a mess immediately after
phf[asciilifeform]: i'll send messages after, and _all my consequitive_ messages will be stuck in order buffer for something like 2-6 minutes, and when they are spooled form the order buffer, they won't even be remotely in the correct order
phf[asciilifeform]: as you can see on bitdash, if you compare it against corresponding paste of my input
bitbot[asciilifeform]: Logged on 2022-12-05 14:13:25 phf[awt]: how the fuck did awt's packet reordering logic went from this http://paste.deedbot.org/?id=_dg1 to this http://logs.bitdash.io/pest/2022-12-05#1017578
bitbot[asciilifeform]: Logged on 2022-12-05 14:15:55 phf[awt]: notice the "getdata from awt, spooling" http://paste.deedbot.org/?id=HJMK and here's how that same log arrives to readers http://logs.bitdash.io/pest/2022-12-05#1017578
phf[asciilifeform]: what i'm sending is A B C D E, i'll get a packet loss on B, will get a getdata for B on C, and then things get weird. some many minutes ago, what actually get spooled is some variotion of A C E D B
phf[asciilifeform]: i think that http://logs.bitdash.io/pest/2022-12-05#1017636 was a novel situation, as opposed to a prior chain rebuild on an otherwise stable network, an attempt to error correct a live chain on an unstable one, which might've revealed some bugs?
bitbot[asciilifeform]: Logged on 2022-12-05 20:57:15 phf[awt]: at which point things always work, no problem. this particular situation happen when there was a packet loss on the network, and your station was trying to reconstruct missing holes
asciilifeform: phf: if yer thing doesn't eat netchains yet, may entirely explain 'hole' (missed packet, from sumbody who didn't proceed to say anyffin moar in next 10min, say, so no selfchain trigger for hole backfill)
phf[asciilifeform]: fuck it, i tried
asciilifeform: iirc awt's 1st pestron also not ate netchains (or even selfchains)
phf[asciilifeform]: where does even remotely in what i said i said that i don't eat netchains?
bitbot[asciilifeform]: Logged on 2022-12-05 20:56:07 phf[awt]: http://logs.bitdash.io/pest/2022-12-05#1017609 << this is not the anywhere near the initial sync. for one i don't keep netchain. i start (in violation of the spec, that's otherwise ignored) each new launch of pest with sending prod, getting latest message, and then linking my nechain
asciilifeform: or hm, yours eats'em but not stores ?
asciilifeform: then -- mystery
asciilifeform: ( given as iirc phf did not mention restarting his proggy when saw the 'hole' )
phf[asciilifeform]: i don't know how i can make it any clearer.
asciilifeform: no, makes sense nao
asciilifeform: 1 of the reasons 1st thing asciilifeform did when rewriting spec, was to throw out the reorder mechanism -- it not only slows propagation simply to satisfy irc frontends, but creates unholy wtf semantics that will prolly never entirely behave as anyone would expect
phf[asciilifeform]: _i_ sent a sequence of messages A *B C D E F. message B got lost, message C triggered getdata, messages D E F went into order buffer along with C. many minutes later the message get spooled, but their order is entirely random, e.g. A D E B F C
phf[asciilifeform]: lets say they all arrived out of order, but how did C end at the end of the spool, if it was the one that triggered getdata?
phf[asciilifeform]: i know that C is the one that triggered getdata, because looking at my own log that's where "getdata from awt" debug message comes up, and because there aren't any timestamp in my paste, it's not obvious that those getdata's followed C immediately
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-05#1017657 << fair. the behavior of the state machine in this case is all kinds of magical
bitbot[asciilifeform]: Logged on 2022-12-05 21:29:00 asciilifeform[jonsykkel|awt]: 1 of the reasons 1st thing asciilifeform did when rewriting spec, was to throw out the reorder mechanism -- it not only slows propagation simply to satisfy irc frontends, but creates unholy wtf semantics that will prolly never entirely behave as anyone would expec
← 2022-12-04 | 2022-12-06 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code