orenc thtesodo goami rna
orenc thtesodn goami roa
orenc thterodn goami soa
orenc thte odn goamirsoa
orenc thte idn goamorsoa
or nc thteeidn goamorsoa
or nc thtgeidn ooamorsea
or nc thegeidn ooamorsta
or na thegeidn oocmorsta
or a thegeidnnoocmorsta
or a thegeimnnoocdorsta
r aothegeimnnoocdorsta
r aodhegeimnnooctorsta
r aodhegeimnnoocaorstt
r acdhegeimnnoooaorstt
r acdeeghimnnoooaorstt
r aacdeeghimnnooo orstt
aacdeeghimnnooororstt
aacdeeghimnnoooorrstt
aacdeeghimnnoooorrstt
sacdeeghimnnoooorratt
a sacdeeghimnnoooorr tt
a satdeeghimnnoooorr tc
c a satdeeghimnnoooorr t
c a s tdeeghimnnoooorr ta
coa s tdeeghimnno oorr ta
coaos tdeeghimnno o rr ta
coaos tdeeahimnno o rr tg
coaos td eahimnno o rretg
coaos td erhimnno o raetg
coaos to erhimnno d raetg
chaos to roimnno deraetg
chaos to roemnno deraitg
chaos to rdemtno oeraing
chaos to ordemtno eraing
chaos to ordertao emning
chaos to ordertmo eaning
chaos to order to meaning
interesting problem: progressively mapping a cosmically high number of unique strings of arbitrary length to an ordered set so that we can assign an index to each string, extract a substring from each index, and filter strings not in the set.
evidently, this approach requires compression. the compressed result is functionally equivalent to a regular expression, or a schema validation system.
been experimenting yesterday with a 1-bit trie, and that made clearer to me how tries and hashmaps relate to interpretation and compilation.
in an interpreter, each instruction only takes single arguments and outputs single arguments to produce definite results.
compilers however attempt to partially specialize functions, which we typically implement using types; but what we're really doing is use types as an approximation for the set of all possible values that could go into a function.
i'm looking at contenders for a xterm based gui lib that I can crib from for a scopes based lib. the micro text editor was implemented with tcell, which in turn was heavily inspired by termbox, which looks like a nice minimalistic C implementation to start off of.
i feel all this should be a backend for SDL, so that i can support real graphical environments as well later on, but as far as i know (and please correct me @icculus if i'm wrong) it's out of focus.
xfce4 really is the best choice for this tiny intel atom laptop. it's not just the frugal use of resources. it's also that window title bars are narrower. optimal for this 1366 x 768 display.
@matiasgoldberg@lritter
Yeah, the wayland transition could go faster.. OTOH, my impression is that Wayland still has issues (on other desktops), maybe when XFCE gets there, the Wayland infrastructure is finally ready to replace X11 without causing pain
@Doomed_Daniel@lritter yeah, XFCE gets TONS of updates but unlike the other wm's they tend to be iterative improvements. Compared to gnome where each new set of patch notes is like "removed more user options, also made it harder to override styles and themes, also we've decided nobody ever needs a scrollbar anymore, everyone uses touchscreens on their desktop right?"
if a novice programmer can code something that runs in a safe language, then an experienced programmer can translate this program to optimized, high-performance semantics.
i theorize that the experienced programmer's job can be sufficiently automated, provided that we control the novice's language, without requiring silly differentiable algorithms.