whaack[asciilifeform]: $ticker btc usd
busybot: Current BTC price in USD: $17272.96
billymg[asciilifeform]: A lot of people thought they were buying bitcoin but really they were just giving their money to an exchange, which then funneled it to the DNC.
billymg[asciilifeform]: If you want number to go up, withdraw your coins into cold storage.
billymg[asciilifeform]: the above is pasta from twitter this morning, obvious to all those present but i figured i'd drop it in here for any noob log readers passing by
billymg[asciilifeform]: IF YOU WANT NUMBER TO GO UP, WITHDRAW YOUR COINS INTO COLD STORAGE
shinohai[busybot]: But muh yield billymg
jonsykkel[asciilifeform|busybot]: pls link utube tutorial how to cold store my xaucoin
billymg[asciilifeform]: ^ literally how bad it is out there in the normie channels
billymg[asciilifeform]: major cultural shift from 2012-2016 era where "if i redirect this infinitely expanding fiat paper into a fixed-supply, immutable asset -- slowly, over time, number will go up" to "which meme token can i put $5k into that will pump and make me a millionaire by this weekend"
billymg[asciilifeform]: from "i am the one making number go up, however small my impact may be. i am ok with this because i know there are thousands of others like me" to "it's all in blackrock's hands now, i hope they pump it soon"
jonsykkel[busybot]: wander if thers market for auto "typewriter" device that u send data to throuhg serial port, stamps runes into 0.5mm steel plate based on n-symbol conversion key u invent and memorize. u decide n based on desired effort of memorization, security and compactnes. for fire+snoop proof storage of keys or other noise-looking da
jonsykkel[asciilifeform]: long data stored on multi plates on keyring etc
asciilifeform: jonsykkel: sumbody sold a lower tech thing where steel letters insert into a plate a la gutenberg press and frame screws down.
jonsykkel[asciilifeform|busybot]: would buy
jonsykkel[asciilifeform|busybot]: expense of auto machine might not be justified for relatively smal amounts of use it would see
awt[asciilifeform]: $ticker btc usd
busybot[asciilifeform]: Current BTC price in USD: $16914.18
asciilifeform: jonsykkel: if you want to store pages fulla keyz, learn to etch steel (similar process to pcb etching)
asciilifeform: imho much simpler to hide ciphered backups in over9000 places off-site.
asciilifeform: that way also 'accidental' (or otherwise) unauthorized 'finder' has nfi what he found.
asciilifeform: (vs. moses-style tablets fulla obviously valuable material)
jonsykkel[busybot]: not bad ideas
jonsykkel[busybot]: moses tablet more esthetic tho. for the master keys
signpost[asciilifeform]: consider also that you're betting that sha256 works with bitcoin.
signpost[asciilifeform]: brain-wallet of sha256(absurdPoem) is possible
shinohai[busybot]: http://logs.bitdash.io/pest/2022-11-11#1015958 << There once was a joo named Sam, who said "Lemme hold dat coin for you fam!" ....
bitbot[busybot]: Logged on 2022-11-11 12:33:05 signpost: brain-wallet of sha256(absurdPoem) is possible
jonsykkel[busybot]: can i use that one
signpost[busybot]: lol
dulapbot: Logged on 2022-11-04 23:04:20 asciilifeform: meanwhile went on a dig of 'sane multi-os gui libs?' in re: 'adult pestron', where threads, arbitrarily long msgs, jpg, files, etc and found -- just like 20y ago -- [http://logs.nosuchlabs.com/log/asciilifeform/2022-01-03#1070913]['wx' and 'qt' -- only game
asciilifeform: turns out, depends on 'glwf', which in turn depends on 'libXfixes', which.. will omit the barf, but dun build on dulap-gentoo
asciilifeform: typical.
asciilifeform: ( possibly ~could~ be made to build, but would require 'upgrading' over9000 dep hell )
signpost[asciilifeform]: I'll trade ya the webshit depthicket I'm taming today
asciilifeform: lol
billymg[asciilifeform]: some bitcoin legislation being proposed in CR: http://billymg.com/downloads/Crypto-Asset-Market-Law-23415.pdf
billymg[asciilifeform]: overall looks not bad, as far as these things go
asciilifeform tried 'sdl' lib again after ~decade; ~still~ eats 100% of cpu while doing nuffin, lol
dulapbot: (trilema) 2016-04-12 phf: freedesktop strategy is to create an abstraction layer on top of base tools that makes things "simpler", and then transparently switch the base. in this case value of gtk & sdl to wreckers is that they both operate on wayland already. sdl seems somewhat sane but i wouldn't be surprised if gnome deprecates their X support at some point
asciilifeform: in forums: 'it's for games, so of course polls for events and eats 100% cpu, whatcha complaining about'
signpost[busybot]: asciilifeform: https://lvgl.io/ << just found this turd, no idea if any good
signpost[busybot]: claims no external deps
asciilifeform: signpost: appears to be for embedded boxen w/ framebuffers (i.e. no support for desktop os and its windows/events/etc)
asciilifeform: i/o is actually the hard part -- e.g. sdl worx ok for 'gimme a framebuffer to draw into' but eats 100% cpu because 0 support for asynchronous input, it polls 4evah (assumes yer writing a game, so go and poll b/w frames)
asciilifeform: the sheer outrageous idiocy -- wanna write a text editor? pick a frame rate...
asciilifeform: and either yer eating 100% of cpu polling, or might miss a key press.
asciilifeform: fwiw sdl offers a 'waitevent', but it locks up the proggy entirely until event happens (e.g. can't display a new line in a chat, or whatnot, while it sits in the blocking wait, as the guism is 1threaded)
asciilifeform: near as asciilifeform can tell, thing is an instance where someone 'solved' crossplatformism by ~not actually doing the hard parts~
asciilifeform found that erry single 'sits on opengl' and similar framebuffer ui lib -- demands an event loop, and suffers from this retardation
asciilifeform: likely because to ~not~ commit this atrocity, requires support for os callbacks, which aint in any sense whatsoever standardized and 'do you have 20 years to spare'
asciilifeform like complete idjit, spent hrs looking for workaround re sdl. there aint one. and even 'waitevent' apparently implemented as busywait in current ver.
asciilifeform: re wx & wt -- there aint anyffin resembling working ada bindings, and prolly aint gonna be -- wx implemented as pile of cpp macros, while qt (multi-GB monster) demands not only cpp but own preprocessor.
asciilifeform: *re: wx & qt
phf[busybot]: http://logs.bitdash.io/pest/2022-11-11#1015981 << "i bought a compressor and a pneumatic hammer, but it doesn't work for nailing boards together. it says `hammer` in the name!"
bitbot[busybot]: Logged on 2022-11-11 16:00:00 asciilifeform[crawlerbot]: i/o is actually the hard part -- e.g. sdl worx ok for 'gimme a framebuffer to draw into' but eats 100% cpu because 0 support for asynchronous input, it polls 4evah (assumes yer writing a game, so go and poll b/w frames)
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-11-11#1015982 << why no write text editor with unity 3d? half-life engine? minecraft red stone is in fact turing complete, can also write text editor with that
bitbot[asciilifeform]: Logged on 2022-11-11 16:02:34 asciilifeform[4]: the sheer outrageous idiocy -- wanna write a text editor? pick a frame rate...
asciilifeform: wb phf!
asciilifeform: phf: 'sdl' aint exactly 'minecraft', is rather framebuffer thing (used in qemu, bochs, even parker's cadr emulator, and over9000 simple 2d gamez), so naturally thought 'hm, if can stomach manually drawing letters, could use sdl'
asciilifeform: but apparently mandatorily busywaits (why? asciilifeform not knows. esp. given that afaik all current os offer event signals)
asciilifeform: http://logs.bitdash.io/pest/2022-11-11#1015991 << to run w/ the analogy, neither pneumatic nor ordinary hammer is anywhere to be found, all that's avail. is a chunk of rock w/out anyffin resembling a flat face one could hammer with
bitbot[asciilifeform]: Logged on 2022-11-11 20:31:14 phf[awt]: http://logs.bitdash.io/pest/2022-11-11#1015981 << "i bought a compressor and a pneumatic hammer, but it doesn't work for nailing boards together. it says `hammer` in the name!"
asciilifeform: i.e. near as asciilifeform currently knows, there's 0 cross-platform way to get a chunk of screen one could draw in + a sane (rather than polling idiocy) handler of kbd, mouse, timer, etc.
phf[asciilifeform]: sdl makes most sense in the context of games, because it supports all the different time slicing strategies that the games require. imho using it for "portable framebuffer" is a sideeffect, in which case should follow "display" strategy: program runs at own clock speed, is aware of display clock, periodically feeds display
phf[asciilifeform]: commands, or whole framebuffer
asciilifeform: phf: evidently is how intended to be used.
asciilifeform: leaves q of 'how the fuq to get a framebuffer w/out churning out 3 os-specific piles o'shit' entirely open.
asciilifeform: phf: 'feed display periodically' is obv. inescapable no matter how one framebuffers. but does 0 against sdl's idiocy of eating 100% cpu simply to know when a key was pressed.
asciilifeform: (if there's a lib similar to sdl but with sane thread yielding, asciilifeform not found it yet.)
asciilifeform: parker -- and authors of over9000 other emulators -- evidently also did not know.
asciilifeform: among other things, makes so that using 1 of these proggies on a lappy, runs down battery in <hr
phf[asciilifeform]: asciilifeform, but eating 100% cpu is what games do: pollevents is called at tick, the rest of the tick time is filled with various useful work, physics, rendering, etc.
asciilifeform: right
asciilifeform: (tho seems that having to cut the physics etc. into x msec ticks would be a pain in own right)
phf[asciilifeform]: right, there are strategies there. total time budget, step budget, separate thread, that kind of stuff
asciilifeform: aha
asciilifeform: what there isn't, there, is a way to make proggy displaying a mostly static screen, not eat 100% cpu.
phf[asciilifeform]: my point is mostly that sdl goes back to ol' linux days, when people like icculus were porting wolfenstein 3d and duke 3d to linux, so the library supposed to fill a very specific niche. in fact i've not seen it used for "portable framebuffer" until quite recently (5-10 years ago), when freesoftware people stopped producin
phf[asciilifeform]: g new code, and old code got shoehorned into all kinds of weird use-cases by wreckers
asciilifeform: makes sense 100%
phf[busybot]: in fact real use-case for sdl was getting tux racer working on a nokia phone or something
asciilifeform: seemed to asciilifeform to be 'best horse in glue factory', was all.
asciilifeform: evidently will have to open x11 manuals from 1980s and 'eat elephant' (and then for other os similarly)
phf[asciilifeform]: but then also have to write your own widget library
asciilifeform: hypothetically, bolix-style fixed font and line graphics aint worst possible world
asciilifeform: (sdl also without 'widgets', asciilifeform already made peace with having to '80s gui)
phf[asciilifeform]: i'm sure there's a lot of these (probably similar amiga or dos ports where source was available), but the only project that comes to mind for doing gui with sdl is grafx2
asciilifeform: right, drawing scrollbars etc. aint the hard part.
phf[asciilifeform]: which spends a lot of code lines on rendering gradients, and custom fonts, and buttons, and such
asciilifeform could live w/out gradients & '3d' buttons etc
asciilifeform: what asciilifeform was looking for was minimum : get a framebuffer, capture window resizes, kbd press/release, mouse coords / buttons (and via interrupts rather than poll). from there -- could start.
phf[asciilifeform]: asciilifeform, quirky gui is a mandatory feature of "comfy" replacements for modern technology. gotta have that retro appeal
asciilifeform: that also lol
phf[asciilifeform]: pest for mac system 9 when
asciilifeform: the only 'modernities' that aint imho escapable are uniturds (ok if no 'ligatures', fuck the savages who need'em, render a uniturd font to bitmaps 1ce during compile) and drag/drop/cut/paste. errything else -- can live without
phf[busybot]: i haven't flushed it out yet, but my current approach with genera pest is to have own utf-8 decoder, that figures out what unicode code point, and then either translit, mapping to supported characters, or punt
asciilifeform: naively seems to asciilifeform that it'd be rather like pest on 386, in re: the actual packet-eating/decipherment
asciilifeform: esp. once bolted on signpost's luby thing
asciilifeform: the 'packets at sumthing like line rate' req. makes a rather strict bound on oldest iron that one could reasonably use
asciilifeform: then again if yer line rate is a 10baseT..
phf[asciilifeform]: i suspect as of right now blatta has much lower rate than genera at line rate :x
phf[busybot]: asciilifeform, have you looked at fltk?
phf[asciilifeform]: also, when you're done fucking around with all this modern dead end bullshit, tk will be waiting for you https://github.com/simonjwright/tcladashell
asciilifeform: phf: last looked toomany yrs ago (tried to bake a scheme binding, choked on cppisms). but apparently alive , and sumbody even baked a mostly-complete ada glue, worth a look
asciilifeform: (in re fltk)
asciilifeform will try prior to resorting to tk or 'outta toothpicks'
asciilifeform: ty phf
asciilifeform unsurprisingly at 1st stab finds that the glue dun build outta the box, can't find the FL/* headers. but prolly solvable.
asciilifeform wonders howthefuq it worked on author's box. the eternal question re these.
asciilifeform found that it builds, when patched as shown.
asciilifeform: libfltkada.a ~4.5MB, which aint terrible.
asciilifeform not tested, as thing didn't come with any ready examples, will need to bake one
asciilifeform: found author's www.