Show Idle (>14 d.) Chans


← 2022-12-04 | 2022-12-06 →
08:10 whaack howdy
08:10 whaack anyone here have some good Spanish reading material?
~ 1 hours 42 minutes ~
09:52 asciilifeform whaack: e.g. g. g. marquez if you haven't yet.
09:55 signpost woke up loving the sexpr message format even more; harkens back to threads about building a proper www.
09:56 signpost can have for example proper transclusion without worrying about referenced material disappearing.
09:59 signpost extension mechanism's also obvious and tidy, can import packages of symbols like any respectable little lisp.
~ 49 minutes ~
10:48 awt phf: key for a111 http://paste.deedbot.org/?id=39_H
~ 28 minutes ~
11:16 phf a ty awt
11:18 phf we had a thread on sexps as interchange format, http://btcbase.org/log/2017-11-21#1741761
11:20 phf 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.
11:22 phf 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)
11:23 phf or rather
11:23 signpost 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" ?
11:23 signpost and this leaves aside things like efficient wire protocol packing
11:23 phf yah, basically
11:23 signpost reasonable imho
11:24 * signpost likes "here's this little space with tidy structures and symbolic reference" and isn't married to the representation
11:24 phf once you start restricting sexps for practical serialization use, you end up either with something like json or something close to ASN
11:26 phf out of the box lisp sexps are a turing complete set of human computer interaction conventions
11:27 phf so you necessarily have to narrow it down to "this, here, is our sexp". at which point the question becomes, why sexp?
11:27 phf and the fact that it's human readable/writable first also becomes a hindrence
11:28 signpost is it the space-waste? or other problems?
11:29 signpost what'd be an alternate way to wrap some text with being a link, bold, etc?
11:31 phf 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
11:32 signpost right, so alternative would be encountering $opcode$length$content fields for example?
11:33 phf you have two different approaches to packing annotated texts: inband markup and structured data encoding
11:34 phf e.g. <b> foo bar</> vs (b " foo bar")
11:35 phf 􏿽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
11:35 phf 􏿽mplicitly string, and the whitespace is significant
11:37 phf 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
11:39 phf something like escape codes (or the informal [BOLD]foo[/BOLD] of forums/wp) are a special case of the first
11:39 * signpost sees that directives like ~these *are* the exception rather than rule in pest messages
11:39 phf i would first decide if we're doing markup or serialization
11:41 phf and they both have obvious drawbacks or cans of worm
11:44 phf 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
11:45 phf or as ascii said "sexps all the way", (mediamessage :filename "foo" :annotation (span "here's " (b "your") " file") :hash 123)
11:48 phf 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
11:49 signpost does having outer structure (the serialization case) thwart display of partial multi-chunk messages? (and do we care?)
11:50 phf 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
11:52 phf http://logs.bitdash.io/pest/2022-12-05#1017439 << i guess it depends on where you place your layer boundaries
11:52 bitbot 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?)
11:53 phf 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
11:59 phf 􏿽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
11:59 phf 􏿽z</>, but how do you know to merge the p's.
~ 18 minutes ~
12:17 phf naggum has /a lot/ on the subject, i started re-reading some of it, https://www.xach.com/naggum/articles/3250033735497397@naggum.no.html
12:18 phf 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
12:20 phf 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")
12:24 phf i think naggum's idea of a markup is something like <p hello <b world> this is a bracket: \>. >
12:24 phf he wrote about it in some other rant of his
12:26 * 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
12:26 * asciilifeform if never again has to write by hand <b>foo</b>, won't be soon enuff
12:26 phf i use a civilized language, don't need to "write by hand" :>
12:27 asciilifeform rright but prolly for rather long time can expect pestrons to eat input by hand
12:27 phf what about the rest of the wall of text!
12:27 asciilifeform which rest of ?
12:27 phf e.g. the difference between markup and structured data
12:28 asciilifeform e.g. (image \x01\x02\x03\x04...) ? wats wrong with that?
12:28 asciilifeform if client not knows how to display -- degrades gracefully, simply prints
12:29 phf 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.")
12:29 phf that's not what i'm talking about though
12:29 * 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
12:29 asciilifeform phf: hm?
12:30 phf markup is of text /annotation/, whitespace is significant, more text by weight than markup, "strings" are first class, etc.
12:30 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
12:30 bitbot 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
12:31 asciilifeform whitespace is significant (outside of "") only in that need at least 1 b/w tokens, neh
12:31 phf you're not groking what i'm saying at all
12:32 * asciilifeform will have to think
12:32 phf 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
12:33 phf the question that needs to be answere is "what is our payload and why" first, before we reach for a particular solution
12:33 * asciilifeform suspects that payload will be largely text, with occasional links/emphasis
12:36 * asciilifeform possibly grasps phf's observation -- imposing (text "hello world") instead of hello world on erry msg is annoying
12:37 phf but then to combine your point with mine, is something like (text "hello world " (image #x02#x01)) something that should be supported?
12:37 asciilifeform possibly signpost's idea from yes. makes sense, and msg oughta have a prefix to indicate whether structured or raw text
12:37 asciilifeform from yest.
12:37 asciilifeform likely nobody will want to write these by hand.
12:38 phf unless markup is trivial enough..
12:38 asciilifeform even getting folx to remember, in classical logotron, that [link][legend], was tricky
12:38 phf hello, <b world>! the <i point> that i'm making is illustrated by the picture of a cat <img images-hash>
12:40 asciilifeform aha
12:40 phf (we have better mechanisms, imho, than inline binary blobs. if you see <img foo> can simply request for foo using signpost technology)
12:41 asciilifeform phf: lubytron only practical for direct msgs
12:41 asciilifeform (no amt of bw would be enuff if were used in broadcasts)
12:41 phf 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>
12:44 * 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
12:50 phf the attribute problem exists in general, (link :url "http…" :title "xxx" "ye old logs") vs ((link (url "http…") (title "…")) …) vs (link "http…" nil …) etc.
12:51 phf oh also (link ((url …) (title …)) …) is popular. i've encountered all four in sexp<->html common lisp packages
12:52 asciilifeform very difficult to beat [link][legend] for hand-writability
12:52 asciilifeform but no obv. way to generalize the compactness to all possib. payloads
12:52 signpost http://logs.bitdash.io/pest/2022-12-05#1017483 << I can imagine a case where you request direct message streams from multiple parties though.
12:52 bitbot Logged on 2022-12-05 12:41:21 asciilifeform[5]: phf: lubytron only practical for direct msgs
12:53 signpost unless I'm dense
12:53 asciilifeform signpost: you could. conundrum is re wat-do if none of yer direct peers have the object with $hash
12:54 phf 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
12:54 signpost ah yep. will leave that for now and stay on serialization vs markup
12:54 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
12:54 phf as opposed to franz's xmlutils (link ((attr value) …) body…) which is easily operated on with a destructuring-bind
12:57 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)
12:58 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.. )
12:59 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
13:01 asciilifeform this is where we end up 'paying for sins of the fathers' and the lack of standardized bolix-style sane gui knobs.
13:04 signpost can still use the irc adapter as sin-firewall while there isn't a pest-specific UI.
13:04 asciilifeform 'can haz sane gui' is what led asciilifeform in '07 down the 'need new os' -> 'need new iron' manhole
13:04 phf 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
13:04 phf 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.
13:04 phf “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.”
13:04 signpost just got a replay on my end
13:04 asciilifeform signpost: right but then stuck with raw text and ~0 annotations and certainly can't link to old msgs inside text etc
13:05 asciilifeform signpost: also got replay aha
13:05 phf yeah, that was sitting in buffer for about 5 minutes
13:05 phf and now i'm back to realtime
13:05 * signpost needs to bake phf a peering key anyway, sec
13:06 asciilifeform phf: per pre-draft spec, no buffers, and nuffing sits, oughta improve things considerably
13:06 asciilifeform ( will wreak havoc with append-only console like irc's tho )
13:06 asciilifeform 99% of the point of gui-pestron is so can 'append the past'
13:07 asciilifeform ( ^ in re this )
13:07 bitbot 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.
13:08 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
13:10 phf http://logs.bitdash.io/pest/2022-12-05#1017506 << http://glyf.org/screenshots/pest-stuck.png
13:10 bitbot 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.
13:10 * signpost would humbly suggest smallest step that leaves the future degrees of freedom, even if shit's hanky until a GUI is built.
13:11 asciilifeform signpost: is the angle asciilifeform approaches the problem from, aha
13:11 asciilifeform presently in spec did not discuss markup at all
13:12 asciilifeform however the abolition of the reordering buffers does heavily pressure in direction of 'need gui'
13:12 asciilifeform w/out buffering, irc frontend will be of very questionable use
13:13 asciilifeform (of course could move the buffering mechanisms to irc frontend per se. but ugh)
13:17 * 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
13:18 asciilifeform afaik there simply aint any way to bake 'sane gui' other than 'from atoms'
13:18 signpost looks like phf's got bespoke UI going, no?
13:18 asciilifeform signpost: he used tk, which aint visible on asciilifeform's displays w/out a microscope lol
13:18 asciilifeform ( see thrd )
13:18 bitbot 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
13:19 signpost yup I know. gotta trade problems sometimes. I'd happily tilt at the dpi thing a while.
13:19 signpost but not as if tinylib for shitting to X wouldn't be great
13:19 asciilifeform great, except nao need to recreate 40yrs of graphics coad
13:20 * signpost wagers "build to throw away" is going to happen a few more times. has happened a few times already.
13:21 signpost just saying ain't nothin wrong with that.
13:21 asciilifeform is rather wai ~0 meaningful progress in the field in 3+ decades -- errything gets thrown away
13:22 asciilifeform even ye olde x11 is 'being thrown' by saboteurs, will soon (if not yet) have to be maintained trb-style
13:22 signpost build something complicated, then ratchet simpler, has happened right here with pest spec and implementations.
13:22 * signpost 100% agrees with asciilifeform's broader statement.
13:23 asciilifeform signpost: rright, but pestron is an 'easy' system in that uses ~0 external coad
13:23 asciilifeform atm as soon as you add graphics, end up 'unhappily marrying the os'
13:23 signpost yep
13:26 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
13:27 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.
13:28 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
13:38 phf asciilifeform doesn't believe in tk
13:38 phf … aaand i'm in a buffer again
13:39 phf i don't understand how awt's buffer works
13:40 phf 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?
13:43 phf 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
13:44 phf or i guess not, the packet was lost, and now i'm going to get spooled in all kinds of random ways
13:46 phf and i'm in the buffer again. wtf
13:48 asciilifeform phf: what's the canonical way to set the scaling for tk (and test) ?
13:48 * asciilifeform looked, found only python examples
13:49 * signpost fixing paste.deedbot.org sec
13:51 signpost fixed
13:54 asciilifeform phf: fwiw it appears to entirely ignore x11's dpi setting
13:54 asciilifeform (unlike e.g. qt)
13:55 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.
13:56 phf http://logs.bitdash.io/pest/2022-12-05#1017556 << https://www.tcl.tk/man/tcl8.5/TkCmd/tk.html#M7
13:56 bitbot Logged on 2022-12-05 13:48:41 asciilifeform[5]: phf: what's the canonical way to set the scaling for tk (and test) ?
13:56 asciilifeform hmm on asciilifeform's box tk 'command not found' lol
13:56 phf
13:56 * asciilifeform defo has the lib...
13:56 phf have you written any tk code before?
13:56 asciilifeform but apparently not the configurator ?
13:57 asciilifeform phf: not for yrs. but thing's supposedly installed on the box
13:57 * asciilifeform will have to look with magnifying glass
13:57 phf that's not a configurator, lol. that's a tk object in the tcl namespace
13:57 asciilifeform a hm
13:57 asciilifeform a, tcl command, right
14:01 phf you can start wish, and do for example tk scaling 10; button .foo -text "hello, world"; pack .foo -fill both
14:01 phf and see what it does
14:02 phf ftr it doesn't do shit on mac
14:03 asciilifeform oh hm but looked entirely edible in phf's mac screenshit
14:03 asciilifeform (how's that work? and maybe could replicate elsewhere)
14:07 signpost phf: http://paste.deedbot.org/?id=RUKq
14:10 phf i think mac build just does the right thing™
14:10 phf you're trying to get tk's x11 widgets to scale. so the hope is that maybe scaling on tk x11 actually does something
14:10 phf you could try doing something like this, and just see if it behaves http://glyf.org/screenshots/mac-tk.png
14:10 phf test
14:10 phf no, why would you be able to? mac build uses entirely different mac native widget set
14:11 phf and when it gets to logs it's in an entirely random jank order
14:12 signpost probably helps if I actually add the key on my end.
14:13 phf 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
14:13 bitbot Logged on 2022-12-05 14:03:07 asciilifeform[5]: oh hm but looked entirely edible in phf's mac screenshit
14:13 phf test
14:13 phf 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
14:14 phf and one of the packets is outright lost _even though it was the one that triggered getdata_
14:14 phf wtf
14:14 signpost I am seeing these messages via awt
14:14 signpost last was "wtf"
14:14 signpost oh, these are replays, lol
14:14 signpost oof
14:15 phf here's the order of messages as i see them, notice the "
14:15 phf err
14:15 phf 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
14:15 bitbot Logged on 2022-12-05 14:03:07 asciilifeform[5]: oh hm but looked entirely edible in phf's mac screenshit
14:16 phf and it looks like i'm back to realtime
14:18 phf 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
~ 1 hours 13 minutes ~
15:31 * phf test
~ 16 minutes ~
15:48 asciilifeform http://logs.bitdash.io/pest/2022-12-05#1017585 << aa makes sense
15:48 bitbot 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
15:49 asciilifeform http://logs.bitdash.io/pest/2022-12-05#1017603 << prolly the reordering delay. and yes
15:49 bitbot 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
~ 37 minutes ~
16:26 awt phf: is your netchain up to date?
~ 1 hours 8 minutes ~
17:34 awt 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.
17:36 awt Messages within dumps should be ordered by timestamp, iirc.
17:38 awt 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.
~ 1 hours 3 minutes ~
18:41 crtdaydreams 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
18:41 bitbot 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
18:41 crtdaydreams wrap it in a macro, but I see
18:41 bitbot 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
18:42 crtdaydreams your point that it's pyrite.
18:56 shinohai 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
18:56 shinohai .
~ 40 minutes ~
19:37 crtdaydreams shinohai: if you need to rekey, send a smoke signal on #asciilifeform and I'll shoot some peering info your way
19:42 shinohai my db intact just don't wanna lose touch with my peeps :)
19:47 crtdaydreams shinohai: currently hearing you as hearsay, if you got a minute mebbe we can fix that
19:51 crtdaydreams shinohai: http://paste.deedbot.org/?id=oSVV
19:57 crtdaydreams http://paste.deedbot.org/?id=Vzh9 this is just %at; valid for PeterL, asciilifeform, unpx and shinohai
20:01 shinohai crtdaydreams: Don't rekey for me just yet but ack on ur pgpgram
20:01 crtdaydreams shinohai: wasn't rekey, just ip:port
20:05 shinohai 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.
20:07 crtdaydreams 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
20:07 shinohai kk
20:08 shinohai just an /at entonces
20:08 shinohai (But as I understand client should take care of that?)
20:08 crtdaydreams believe it's nat config
20:09 crtdaydreams possib. on my end
~ 47 minutes ~
20:56 phf 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
20:56 bitbot Logged on 2022-12-05 16:26:33 awt: phf: is your netchain up to date?
20:57 phf 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
20:58 phf 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
21:00 phf 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
21:01 phf as you can see on bitdash, if you compare it against corresponding paste of my input
21:01 phf http://logs.bitdash.io/pest/2022-12-05#1017588 and http://logs.bitdash.io/pest/2022-12-05#1017600
21:01 bitbot 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
21:01 bitbot 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
21:02 phf 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
21:08 phf 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?
21:08 bitbot 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
~ 15 minutes ~
21:23 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)
21:25 phf fuck it, i tried
21:25 asciilifeform iirc awt's 1st pestron also not ate netchains (or even selfchains)
21:26 phf where does even remotely in what i said i said that i don't eat netchains?
21:26 asciilifeform here ?
21:26 bitbot 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 off that, and selfchain of 0
21:26 asciilifeform or hm, yours eats'em but not stores ?
21:27 asciilifeform then -- mystery
21:27 asciilifeform ( given as iirc phf did not mention restarting his proggy when saw the 'hole' )
21:27 phf i don't know how i can make it any clearer.
21:28 asciilifeform no, makes sense nao
21:29 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
21:30 phf _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
21:31 phf 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?
21:32 phf 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
21:34 phf http://logs.bitdash.io/pest/2022-12-05#1017657 << fair. the behavior of the state machine in this case is all kinds of magical
21:34 bitbot 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 expect
← 2022-12-04 | 2022-12-06 →