jonsykkel[asciilifeform]: tanks man
jonsykkel[asciilifeform]: cant input text yet so bit of a work in progres
phf: http://logs.nosuchlabs.com/log/pest/2023-06-10#1027245 << acme can be programmed, somewhat awkwardly, over 9p protocol. i suspect if i were to do a lisp structured editor for unix, i'd go with acme as an interface instead of sdl
dulapbot: Logged on 2023-06-10 09:07:12 unpx[asciilifeform]: jonsykkel: I wonder how your editor will look like, was looking at the acme editor just for fun
phf: without taking over the whole logic you can still do things like eval and jump-to-definition by hooking into mouse buttons
phf: http://logs.nosuchlabs.com/log/pest/2023-06-10#1027256 << spoken like a true scheme developer, but in common lisp the true tree structure is a level below user input, so you have to make provisions for that roundtrip from the very beginning
dulapbot: Logged on 2023-06-10 09:59:10 jonsykkel[asciilifeform]: well, since existence of lisp makes it clear that any code (and a bunch of other stuf rly) is really a tre structure, u can use the same tool for any code/etc
phf: e.g. ''123 is (QUOTE 123), '#'car is (FUNCTION CAR) unless you have print-pretty enabled in which case it'll render it back as '123 and #'123
phf: but all of that goes out of the window with creative readers, like ;; foo gets read and ignored. or for example i have a prefix reader in pest, that's triggered by ◇, so e.g. ◇2+2◇ gives me 4. for some kind of mathematical code this produces better result than sexps, and ther
phf: e's a reason why both interlisp and zeta lisp had that as a mode.
phf: here's an example of a complete function using this mode http://logs.nosuchlabs.com/log/pest/2023-02-08#1022837
dulapbot: Logged on 2023-02-08 21:07:32 phf: this myers implementation with parts done using infix notation is so ugly, i love it http://paste.deedbot.org/?id=QPOZ
phf: emacs lets you assign character class to arbitrary character, and put it into some predefined categories, e.g. (modify-syntax-entry ?◇ "|" lisp-mode-syntax-table) marks ◇ as an equivalent to " that is beginning/end of string marker
phf: but then you have the whole ugly special reader machinery on #\#, e.g. #x123 or #p"/foo/bar", which you end up having to special case, which is something that you see with e.g. paredit, since it was written by a schemer, it doesn't support proper handling of #p out of the box, it t
phf: reats it as a separate symbol before a string
phf: http://logs.nosuchlabs.com/log/pest/2023-06-09#1027232 << apologies, i'm consistently away from a machine with key, have been traveling (mostly locally, stayed in Annapolis for a bit for boats, stayed down in garret county for a bit for horses)
dulapbot: Logged on 2023-06-09 12:50:43 unpx[asciilifeform]: phf http://paste.deedbot.org/?id=wSS8
phf: http://logs.nosuchlabs.com/log/pest/2023-06-10#1027292 << raskin's "leaping" idea an various lesser implementations, like most common one is incremental search
dulapbot: Logged on 2023-06-10 12:56:56 jonsykkel[asciilifeform]: that is "far away" from cursor
phf: http://logs.nosuchlabs.com/log/pest/2023-06-11#1027309 << i suspect llm view of program's structure is nothing like what a programmer sees in his mind, but that symbolic graph lives "live" in the intellij idea at all times. just needs a sane visualizer(c)
dulapbot: Logged on 2023-06-11 19:37:04 signpost[asciilifeform]: I want to see the whole damned symbolic graph of a program sanely.
phf: so it's like "each day we're further away from god" type thing. nobody wants to work on boring hard problems
phf: http://logs.nosuchlabs.com/log/pest/2023-06-12#1027311 << you need to cut your bytes by code units, rather than code points or bytes. so you have a character #\CYRILLIC_SMALL_LETTER_A, or whatever. it's code point is 1072, but it's code unit in utf-8 is a byte sequence [208, 176]
dulapbot: Logged on 2023-06-12 00:11:20 awt[asciilifeform]: Currently working on multipart - running into issues breaking up ancient greek. I assume there would be problems with cyrillic as well.
phf: so if you measure length by code points, you're going to get 1 less than the count of bytes, potentially getting a truncation when sending string. and if you measure by bytes, you potentially end up sending 208 in one message, and 176 in the other message, which results in decoding error
phf: now when all the clients support proper multipart messages this is no longer a problem, because you reconstruct the final string by concatenating all bytes and then decoding the whole thing. but interim solution is to make sure you never cut in the middle of code unit (the two byte
phf: s above) and that you're counting your total number of bytes correctly
phf: the way i look at this algo is i have a string of unicode characters, and i have n byte arrays, i collect unicode characters from the string keeping track of their byte sizes, and split, when the characters's byte representations no longer fit into the array
phf: http://okturing.com/src/16102/body is the algo that i use in lisp
phf: which gives you (split-string-max-octet-size "おはよう日本helloпривет" 6) ("おは" "よう" "日本" "hello" "при" "вет")
phf: (split-string-max-octet-size "おはよう日本helloпривет" 5) ("お" "は" "よ" "う" "日" "本he" "lloп" "ри" "ве" "т")
phf: why this is correct is an exercise in understanding this whole god awful problem
phf: http://logs.nosuchlabs.com/log/pest/2023-06-12#1027319 << state of the art algorithmic eye tracking, ultra high resolution retinal projection, nvidia rtx 5xxx to render highly realistic environment: you walk past a waterfall, through myst at a beautiful rendition of japanese pagoda
dulapbot: Logged on 2023-06-12 07:04:28 jonsykkel[asciilifeform]: me haking in 2025 http://zzz.st/up/75Ki1FeD/20230612_123900.jpg
phf: , walk through multiple beautiful rooms with reproductions of old arts and artifacts, get to the hacking room, open a virtual laptop, to stare at 80x25 terminal screen for the next 8 hours
jonsykkel[asciilifeform]: the illusion is indeed broken by mutilating reader
jonsykkel[asciilifeform]: but im not gona let that stop me from having a sensible editor that works without modification in 99.7% of my own use cases
jonsykkel[asciilifeform]: http://logs.nosuchlabs.com/log/pest/2023-06-13#1027346 << the absolute horor
dulapbot: Logged on 2023-06-13 10:11:14 phf: here's an example of a complete function using this mode http://logs.nosuchlabs.com/log/pest/2023-02-08#1022837
jonsykkel[asciilifeform]: http://logs.nosuchlabs.com/log/pest/2023-06-13#1027353 << belongs in the toolbox 2 be sure, but isnt optimal in cases where seach term is common. i wana be able to leap to specific "(" on my scren
dulapbot: Logged on 2023-06-13 10:41:22 phf: http://logs.nosuchlabs.com/log/pest/2023-06-10#1027292 << raskin's "leaping" idea an various lesser implementations, like most common one is incremental search
jonsykkel[asciilifeform]: posibly vimperator like interface is hard to beat "bits inputed from hand" wise
dulapbot: Logged on 2023-06-13 11:12:15 phf: , walk through multiple beautiful rooms with reproductions of old arts and artifacts, get to the hacking room, open a virtual laptop, to stare at 80x25 terminal screen for the next 8 hours
phf: http://logs.nosuchlabs.com/log/pest/2023-06-13#1027372 << no question about that, but one ought to still be aware of how much one is going full chuck moore http://logs.nosuchlabs.com/log/pest/2023-03-30#1025758
dulapbot: Logged on 2023-06-13 11:35:51 jonsykkel[asciilifeform]: but im not gona let that stop me from having a sensible editor that works without modification in 99.7% of my own use cases
dulapbot: Logged on 2023-03-30 09:48:27 phf: apropos of nothing i'd like to document the phrase "going full chuck moore", for the logs. it means building your own technology stack, and retreating into it from the outside, inferior world. can be applied to e.g. "owning" some retro stack also.
jonsykkel[asciilifeform]: 80% full chuck moore i think is a good balance
phf: yeah like a concious awareness of where on the chuck moore scale one is :>
jonsykkel[asciilifeform]: warning lamps at top of monitor would be best
jonsykkel[asciilifeform]: like racecar shifter
awt[asciilifeform]: http://logs.bitdash.io/pest/2023-06-13#1026957 << ty. Attempted this algo but python is doing something weird. Sometimes when I unpack the bytes I get a str, others, bytes. Handled this and encoded the messages for the client in base64. Tried decoding with a random base64 decoding site and each piece decoded successfull
bitbot[asciilifeform]: Logged on 2023-06-13 11:04:55 phf[4]: why this is correct is an exercise in understanding this whole god awful problem
awt[asciilifeform]: y into ancient greek. Meanwhile if I try decoding the body in python (from bytes when
awt[asciilifeform]: bytes), I still get the error I originally reported.
awt[asciilifeform]: python version: http://paste.deedbot.org/?id=evrh
awt[asciilifeform]: For the record, this is the error I'm seeing, along with a correct decoding of the same value: http://paste.deedbot.org/?id=S9YT
awt[asciilifeform]: Ah, found the problem. I was breaking up the messages into 324 bytes (BroadcastText payload size) instead of 288 (BroadcastTextM payload size).
awt[asciilifeform]: Set an icon for the desktop client: https://imgur.com/a/XUdKW6Z. Entomologist friendly.
awt[asciilifeform]: The only way I seem to be able to prevent a race condition when handling incoming multipart messages is to space out their transmission a bit. Even moving the processing of text messages on to a single thread didn't help.
awt[asciilifeform]: This is of course in a test environment where all stations are running on the same host.