awt[asciilifeform]: !!ticker btc usd
deedbot[asciilifeform]: $27,357
phf: jonsykkel, just fyi, i'm getting a getdata for 0 from you
jonsykkel[asciilifeform]: inded
jonsykkel[asciilifeform]: fixed, i belive
phf: ayo
phf: Never before had Brother Francis actually seen a pilgrim with girded loins, but that this one was the bona fide article he was convinced as soon as he had recovered from the spine-chilling effect of the pilgrim’s advent on the far horizon, as a wiggling iota of black caught in a
phf: shimmering haze of heat. Legless, but wearing a tiny head, the iota materialized out of the mirror glaze on the broken roadway and seemed more to writhe than to walk into view, causing Brother Francis to clutch the crucifix of his rosary and mutter an Ave or two. The iota suggested
phf: a tiny apparition spawned by the heat demons who tortured the land at high noon, when any creature capable of motion on the desert (except the buzzards and a few monastic hermits such as Francis) lay motionless in its burrow
phf: appologies, porting pest between lisps again
phf: my conclusion about tk/ltk is that it's just too brittle and half baked to do live development with. you end up writing new tcl code, writing lisp code for product and while trying to improve corner case behavior of ltk itself. when things crash the whole system goes down, often to
phf: kill -9 state. so i'm going to try and implement things in lispworks, and i guess make gui modular, so that eventually it can be ported out, once the general ideas and algorithms have been settled
awt[asciilifeform]: phf: I have lispworks and can test if you ever need it.
awt[asciilifeform]: Would also be interested in what corner cases you ran into with tcl/tk, as I'm currently using tkinter.
asciilifeform has an ancient lispworks sumwhere
asciilifeform still, sloowly, plugging along with wx. where, hilariously, cppism per se, rather than the gui lib, turned out to be the chief torment
phf: awt, well you're hacking from python, so you do lots of restarts. i'm running it in lisp, so it's a long running instance that i don't want to lock or crash, because it brings down the context
phf: and the way ltk talks to tcl/tk is basically using a kind of swank, sending strings with commands around
phf: meanwhile i'm trying to use the text widget in a way where i can update and replace large chunks based the updates of the khan sorting order. so it's a lot of like "delete a region for hash X, insert a new region after hash Y". it works on tcl/tk side great, but the interop is less
phf: than ideal, because the ops i'm trying to do are not built in, so i'm writing lots of tcl to do non-trivial things, etc.
phf: and the only reason i was using tk is because i was thinking in terms of how it can run on other people's machines, but that requirement ended up adding friction to dev process, and then i remembered that it's a hobby hacking project.
asciilifeform: in re: 'simplest that runs on just this-here box' -- iirc phf even had 1 on bolix ?
awt[asciilifeform]: https://imgur.com/a/G1AeCll << Alas - I've just discovered that Tkinter does not support multiline rows.
awt[asciilifeform]: You have to increase the row height and then add newlines to the text. Gross.
phf: awt, i gave up on the idea of list based log, which complicated things significantly. can you even do styling in rows?
phf: you can't style rows, can't do inline images, can't do multiline. sometimes it's supported, but you need to do liek "feature matrix". multiline rows in qt, but no images. images in tk, but no multline.
asciilifeform: fwiw asciilifeform found that in wx, similarly , gotta 'hand draw' the screen on scroll to get anyffin like the ui one would want (inline images, variable-height blocks of text)
asciilifeform: extremely gnarly to implement.
asciilifeform not yet, lol, implemented, merely 'found how' in theory
phf: both tk and capi "solve" this by having a rich text editor, that supports all the things, but now you have to carefully track regions, etc.
asciilifeform tried with wx's 'rich text editor' widget; flickering slugging hell on both x11 and crapple
asciilifeform: similarly with its html view widget
asciilifeform: the only thing that even theoretically threatens to work is to do it 'as if it were a port of quake', i.e. explicitly draw & double-buffer, and maintain map of regions for the mouse, etc
phf: lol, good luck
phf: i mean, if nothing else both tk and capi's rich editors work™. my test run was to load canticle for leibowitz, and then replace all the occurences of word "god" with a random picture from a folder. also random styling. scrolls fine,etc.
asciilifeform: wx's text editor 'works', but with a '4k' lcd fulla reasonably small text, slow as all fuck when scrolling/updating
asciilifeform: ( on 'm2' crapple not slow! but flickers abominably )
awt[asciilifeform]: Well that significantly pushes back my schedule.
phf: awt, also keep in mind that because of the whole multi-part messages, you don't get one to one correspondence between hypothetical message index, and it's placement in list
awt[asciilifeform]: phf: yes. Been thinking I'll queue them up and insert as soon as the terminal message arrives.
awt[asciilifeform]: Ah but you're right, it breaks the hash per line model.
awt[asciilifeform]: Usually the UI is speced out first, then the requirements for the implementation stem from the design.
awt[asciilifeform]: Got text wrapping working but it's quite slow.
awt[asciilifeform]: And rows all have to be the same height.
asciilifeform: http://logs.bitdash.io/pest/2023-05-11#1025987 << asciilifeform's pov re subj is that storing msgs 'as received' for purpose of getdata is sufficiently separate domain from 'db for display' that it oughta be handled 'a la nqb' i.e. 2 entirely separate db
bitbot[asciilifeform]: Logged on 2023-05-11 20:44:24 phf[jonsykkel|deedbot|awt]: awt, also keep in mind that because of the whole multi-part messages, you don't get one to one correspondence between hypothetical message index, and it's placement in list
asciilifeform: ... 1 of which is simple key-value store, while the other actually keeps the text in the order in which it is expected to appear on the screen
asciilifeform: i.e. you dun want to be parsing black packets errytime the window repaints
asciilifeform: (or the dbized logical expansion of black packets, e.g. individual chunks of multiparts)
asciilifeform: http://logs.bitdash.io/pest/2023-05-11#1025992 << found this to be the case in wx's default 'list view' thing
bitbot[asciilifeform]: Logged on 2023-05-11 22:16:10 awt: And rows all have to be the same height.
asciilifeform after found this, set about baking 'hand-drawn' scroller thing where tried to calculate footprint of text in $string, utterly broke teeth after finding that wx's built-ins that are supposed to make this possible, quite unreliable
asciilifeform: got it to work for fixed-width font tho (where, unsurprisingly, trivial)
asciilifeform: ... to expand re the 'a la nqb' -- chain hashes oughta get looked at strictly when 1) performing getdata 2) when a msg is 1st received and parsed. at which time they oughta turn into straight numeric indices to db rows
asciilifeform: 3) when transmitting, pull the requisite chain hash back outta db via the index.
asciilifeform: may seem like gnarly premature optimization, but asciilifeform strongly suspects that you ~never~ want to be reassembling chunks of multiparters during gui scroll, no iron is fast enuff to make this pleasant (esp. after the db gets fat)
asciilifeform: http://logs.bitdash.io/pest/2023-05-11#1025996 << err, red, lol
bitbot[asciilifeform]: Logged on 2023-05-11 22:57:06 asciilifeform[6]: i.e. you dun want to be parsing black packets errytime the window repaints