crtdaydreams[asciilifeform]: phf: do you have an ebuild for libsdl-1.2?
crtdaydreams[asciilifeform]: fugg. 32bit on a non-multilib sys is like square peg and round hole
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-03#1017289 << correct method is to Xnest :3&;DISPLAY=:3 twm&
bitbot[asciilifeform]: Logged on 2022-12-03 13:03:31 asciilifeform[6]: suspects an oddball interaction b/w this thing and 'ratpoison' wm. the events only start to roll when re-exposed somewhere ~other~ than the wm frame where window originally appears
asciilifeform: phf: hm, wat does that do ?
phf[asciilifeform]: Xnest is a nested x11 server
asciilifeform: aaa
asciilifeform has been using crapple lappy for x experiments ever since that lul
phf[asciilifeform]: spins up a window, and if you connect to display 3, you get your shit running in that window. also localizes lockups, etc.
bitbot[asciilifeform]: Logged on 2022-11-22 00:20:27 asciilifeform[5]: crtdaydreams: nfi whether the approach is practical yet. (managed to, so far, wedge x; and then, separately, to create unkillable zombie window after process killed, grr)
asciilifeform: at least there can restart x w/out fucking over9000 things
phf[asciilifeform]: there's enough tooling to not have to do anything this sevage, not that i'm opposed to using apple lappy ofcourse
asciilifeform will try nested x
asciilifeform has been puzzling over moar mundane puzzlers : wai can't draw anywhere close to the edge of the window w/out crash? wai the xcb example properly occupies resized (by ratpoison) window with white bg, but asciilifeform's -- not? etc
asciilifeform tried catching configurenotify event but it doesn't appear that xcb does any such thing by default. nor does that ev fire at creation (there's anuther one that does, but again xcb duncare)
phf[asciilifeform]: well, xscope might help. that's a packet tracer, works the same way as everything else on x (shittily, lul): sets up a fake server, connects to real server (or Xnest in your case), clients connect to fake server, and whatever goes over wire gets dumped
asciilifeform: loox useful. asciilifeform has been using strace as an ad-hoc xscope
phf[asciilifeform]: there's also xtrace that does the same thing, i've not used it. i've used xscope a bunch for debugging genera and for writing from scratch x11 code
asciilifeform: reportedly new wireshark also does (but naturally won't build under asciilifeform's gentoo lol)
phf[asciilifeform]: but yeah, you put xscope on 3, you put xtrace on 4 and connect to 3, you connect your app to 4 and you're golden
asciilifeform: and yes this is prolly the only way to solve the case. gnarly.
phf[asciilifeform]: it's also stock, it comes with x11 installation, and will be on your apple already
asciilifeform and not even touched the horror of actually cobbling together sumthing resembling a gui 'from raw atoms' when finally have a working drawable window & signals
phf[asciilifeform]: asciilifeform, i've down this ungodly path of yours before, so i've tooled up :>
asciilifeform: phf: how far didja get last time ?
asciilifeform continues to uncover ungodly horrors of the deep, e.g. events which come with a 'there's N similar events following this one' counter
asciilifeform: or for that matter various in-memory 'planes' which appear to be required to get scrolling, double-buffering, etc
phf[asciilifeform]: well, my usecase is different, i've been idly writing a book, which is a kind of introduction to basic graphics programming fundamentals, by using a comon lisp reimplementation of an old macromedia based game. it's got a little bit of everything, if you want to know how computer gr
phf[asciilifeform]: aphics work from first principles or how to do "real" code in lisp. binary data parsing, PCX from scratch, bitblit, cinepak as an example of video encoding (it's very easy to work with). so all i needed was a way to canvas
asciilifeform: aa neato
asciilifeform read a # of graphix b00kz, typically they start out 'get sdl' or similar
phf[asciilifeform]: *a way to canvas within less than a chapters worth of implementation details
asciilifeform: (excepting the msdos ones, lol)
phf[asciilifeform]: i've worked with barski on land of lisp, and i really liked his freewheeling from scratch approach "we're going to write a really shit, but good enough web server in clisp for our next lesson"
asciilifeform: there's a rather noticeable gap tho, historically, from 'what's in graphix textbook' to 'gui resembling gtk', i.e. w/out flicker, etc
asciilifeform: 'land of lisp' was a++ imho
asciilifeform not aiming at 'gtk-like' but moar modest b&w line graphics, but at least such that worx on arbitrary-res displays and not liquifies yer eyes with flicker
asciilifeform: a bolix-like style would be entirely adequate for serious use imho
phf[asciilifeform]: we used to run a hacker get together in dc, back in the day, when "presentation on haskell" was still a novel and exciting thing. i mean the group was called "fringe dc". god damn hipsters ruined everything.
asciilifeform was in 'hack dc' club for some yrs, went similarly
asciilifeform: buncha folx got various gear together, amassed a junkyard's worth of parts, and regularly convened, but mostly errybody tired from day job and merely 'shot the shit' and summed to 0
asciilifeform: a 'hack dc' made of ample-time aristocrats could be interesting, but asciilifeform won't be there lol
asciilifeform: 1 time at 'hackdc' they had a series of 'clojure' sessions, and asciilifeform attended, and after that wrote this
asciilifeform: (at some later time, asciilifeform imagines , 'hipsters ruined', but not made it to see this, threw in the towel )
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-11-28#1016957 << have to agree, with much respect to current implementations, they oughta be subordinate to the spec.
bitbot[asciilifeform]: Logged on 2022-11-28 11:23:17 phf[awt]: it's got a big of a makefile effect: you'll have a kludge that's relevant for about a month, and then it becomes legacy kludge forever
signpost[asciilifeform]: yep, really seems like multipart oughta be separate message code, both for the immediate reason and to pour some ideological cement.
signpost[asciilifeform]: I can help awt patch in this message code if helpful. seems like all that'd be needed is to send it to the standard message handler, since the IRC frontend isn't going to do anything special with multiparts
asciilifeform has 0 problem with this pov, given as nobody seemed to strongly barf from the idea of old clients missing multipart msgs until upgraded
asciilifeform will make'em new codes.
phf[asciilifeform]: lisp pest already runs with draft multipart, but i think i only need to change protocol definition to switch to different message type, as opposed to unicode prefix
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-11-28#1017021 << brutal, wish her peace.
bitbot[asciilifeform]: Logged on 2022-11-28 13:38:24 asciilifeform[jonsykkel|awt|deedbot]: meanwhile, in misc. old-timer blogs.
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-12-04#1017333 << i was hacdc interim treasury for a couple of months, but back when i was there it was still somewhat active. 2004? i remember we were trying to setup a community wifi network, starting with that church
bitbot[asciilifeform]: Logged on 2022-12-04 12:55:24 asciilifeform[5]: was in 'hack dc' club for some yrs, went similarly
phf[asciilifeform]: when i came back and lived in dc last time, 2018, it was already "bunch of old dudes talking about doing a project and not having time for it". none of the people from 2004 were there anymore.
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-11-28#1017032 << good time to decide whether inbandism is banned with prejudice
bitbot[asciilifeform]: Logged on 2022-11-28 15:21:41 phf[awt]: asciilifeform, have you given a thought to ACTION? that's something that's not address in the spec, and if you're going to drop irc specific stuff probably should be
signpost[asciilifeform]: and if it is, subsequently whether "action" is part of a class of messages or worthy of its own code.
signpost[asciilifeform] and MULTIPART-MESSAGE ought to be subtypes of MESSAGE in some manner, given both could be called something like rendering hints.
signpost[asciilifeform]: obviously in one direction you expend message codes, and the other, message space by adding sub-classifiers
signpost[asciilifeform]: AWAY status could be another of these sub-types of message
phf[asciilifeform]: action is cute, because it's one of those atavisms, comes from mud culture, and is otherwise non-existent in all the modern™ protocols. possibly because reflective narration in humans is a higher function
signpost[asciilifeform] considers it culturally indispensible!
phf[asciilifeform]: what does exist in modern protocols thouhg, are various content types. like i've only worked with telegram, but it has location message, various kinds of document messages, a sticker pack message, etc.
signpost[asciilifeform]: yeah, one I eagerly anticipate is DHT-LINK-HASH
phf[asciilifeform]: they don't do any kind of type hierarchy though, it's message types live all equally at the high level. so a document message might have a text comment on it and regular message also has text on it, but both texts are not considered to be same attribute
phf[asciilifeform]: *its message types
signpost[asciilifeform]: that chained messages are planned imho relieves pressure on conserving message payload space. I'd probably recommend reserving a few bytes for a message subtype which precedes the payload. will continue to think about it.
signpost[asciilifeform]: http://logs.bitdash.io/pest/2022-12-04#1017361 << possibly subtype comes with length of subfield, and one can put however many in there.
bitbot[asciilifeform]: Logged on 2022-12-04 13:48:46 phf[awt]: they don't do any kind of type hierarchy though, it's message types live all equally at the high level. so a document message might have a text comment on it and regular message also has text on it, but both texts are not considered to be same attribute
signpost[asciilifeform]: then message with a link to boobs can still say "boobs" to clients that can't boobinate.
signpost[asciilifeform]: the 6byte "mark+Z" is probably enough space to say both length and subtype.
signpost[asciilifeform]: dunno even needs that much, probably can shave ~2
signpost[asciilifeform]: just talking through it, no firm proposal.
signpost[asciilifeform]: and as phf implies, a client can then filter by "all hyperlinks", "all with $term in body text", etc., if what's conceptually same is denoted the same across subtypes.
signpost[asciilifeform]: $ticker btc usd
busybot: Current BTC price in USD: $17094.2
asciilifeform: http://logs.bitdash.io/pest/2022-12-04#1017350 << related q -- do we want htmlism in text? (when gui client, prolly will be tempting)
bitbot[asciilifeform]: Logged on 2022-12-04 13:38:08 signpost: http://logs.bitdash.io/pest/2022-11-28#1017032 << good time to decide whether inbandism is banned with prejudice
asciilifeform: http://logs.bitdash.io/pest/2022-12-04#1017349 << asciilifeform was last there in '09 and was already 'old men talking' then
bitbot[asciilifeform]: Logged on 2022-12-04 13:38:07 phf[awt]: when i came back and lived in dc last time, 2018, it was already "bunch of old dudes talking about doing a project and not having time for it". none of the people from 2004 were there anymore.
signpost[asciilifeform]: asciilifeform: that question points out that multipart is probably an orthogonal concern to message subtype.
signpost[asciilifeform]: i.e. subtype of text/html, m of n. subtype of pr0n, m-of-n
asciilifeform: iirc heathen chats often do photos etc. as mime-tagged text
asciilifeform would rather not import that shitstack if can avoid tho
asciilifeform: m-of-n per asciilifeform's picture oughta be for text strictly. (for fat binaries, oughta use signpost's lubytronic encoding)
asciilifeform: m-of-n is so to be compat with broadcast
signpost[asciilifeform]: makes sense.
signpost[asciilifeform]: re: html ick, but also something will grow there "organically" if not defined, I wager.
signpost[asciilifeform]: could choose to be fascistic about text-only plus link-references to DHT items, and how they're displayed is left to the client to decide
signpost[asciilifeform]: that'd at least be a place to start that doesn't haul in chromium
signpost[asciilifeform]: I suppose nothing stops anyone from putting HTML in the text hole, and having their client interpret it. doesn't ask much if anything from the protocol.
signpost[asciilifeform] will think moar and return in a bit
asciilifeform: imho good opportunity to drive 1st nail into coffin of html : introduce sexprs in text payload.
asciilifeform: e.g. (bold "foo") etc.
signpost[asciilifeform]: opens up quite a lot of flexibility to evolve in the viewer
asciilifeform: http://logs.bitdash.io/pest/2022-12-04#1017367 << why add moar type fields when 'command' not even threatens to run outta slots
bitbot[asciilifeform]: Logged on 2022-12-04 15:49:20 signpost: the 6byte "mark+Z" is probably enough space to say both length and subtype.
asciilifeform: ( if for backwards-compat -- how's a msg with hypothetical text type field of unknown type anymoar back-compat. than a command where ditto ? )
asciilifeform is of the 'fewer magick #s where at all possible' school of thought
asciilifeform (...))
asciilifeform: sexprs 'degrade gracefully', if an older client not knows how to interpret (WHATEVER (...)), can simply print it
signpost[asciilifeform]: I think the sexp markup idea covers every interesting use-case for content within a message, yep
asciilifeform: aha
signpost[asciilifeform]: this plus making multipart messages their own command looks pretty tidy to me.
asciilifeform: if packets weren't stuck at rather tight fixed length, whole thing could be sexpr. but as it is need some (minimal) set of numeric codes, where need, but where not -- oughta sexpr imho