2024-09-25 00:50:53 more naming challenges. if i'm reference-counting objects, are the words to increment and decrement reference counts +ref and -ref or ref+ and ref- 2024-09-25 00:52:34 maybe retain and release 2024-09-25 00:53:33 i don't know, it would mean typing 2 or 3 more letters in each case 2024-09-25 00:53:49 are you trying to wear out my keyboard?? 2024-09-25 00:56:28 how about keep and kick? 2024-09-25 00:56:44 it's occurred to me that if i embrace more of an object oriented design, i don't even need this parallel metadata memory. the target memory simply becomes a seriest of object addresses, and their vtables (for lack of a better term) manages how they are evaluated, replaced, etc. 2024-09-25 00:56:45 or keep and free 2024-09-25 00:57:09 in Forth the term for vtable is traditionally "cfa" 2024-09-25 00:58:05 well, vtable address, anyway. and the vtable itself is executable code rather than an array 2024-09-25 00:58:15 hmm. i always thought of the cfa as pointing to a machine code interpreter 2024-09-25 00:58:25 yeah, in my case it's an array of xts 2024-09-25 00:59:11 Forth words by default only have one method, but nothing is stopping that method from dispatching to other pieces of code 2024-09-25 01:00:38 but what i need is for + to look in the top stack item for its dispatch 2024-09-25 01:00:56 the top stack item is nameless data, not a word 2024-09-25 01:01:54 aha, yes 2024-09-25 01:02:19 so you're wondering how to distinguish integers from pointers in that situation 2024-09-25 01:02:37 without parallel metadata memory 2024-09-25 01:02:53 well, not really wondering. i have implemented something, but always welcome better ideas :) 2024-09-25 01:06:11 the standard solutions are: (1) box your integers; (2) align your pointers and use the low-order bits to distinguish integers from (possibly offset) pointers; (3) nanboxing 2024-09-25 01:06:13 i have an entry-point method bi which takes two objects and an xt. so the top object's bi handler is invoked, and depending on what it is, invokes a refined bi on the other object. e.g., number's "bi" handler invokes "nbi" on the other object, relocation's bi handler invokes "rbi" on the other object. 2024-09-25 01:06:36 makes sense, that's called the double dispatch pattern 2024-09-25 01:06:45 so the number's nbi handler knows it's adding two numbers. relocation's nbi handler knows it's adding a number and relocation 2024-09-25 01:06:51 oh, didn't know that thanks 2024-09-25 01:06:57 right 2024-09-25 01:09:23 oh I guess the alternative otto ()3) is discriminated unionsb, like, with a separate type field and all of your cells being bigger than a pointer 2024-09-25 01:10:52 anyway, i was already doing some kind of dispatch like this before (using a different method than vtables though), and i had an entirely separate dispatch for memory access. what i meant to say was that by embracing the object model, i can't combine all of these things. 2024-09-25 01:10:52 xentrac: i think you could say that's sort of what i was doing before, but rather than interleaved, the types and the data were separated 2024-09-25 01:13:28 yeah, I understand 2024-09-25 01:13:41 parallel arrays in a sense 2024-09-25 01:13:49 exactly 2024-09-25 01:21:09 Perl does it that way 2024-09-25 01:21:46 a difficulty with tag bits is that it reduces your integer range 2024-09-25 01:26:38 a little surprised perl doesn't do the all numbers are floats thing 2024-09-25 01:29:23 perl probably got IV and NV from awk 2024-09-25 01:31:45 awk doesn't have IV and NV 2024-09-25 01:32:08 typedef struct Cell { 2024-09-25 01:32:19 // ... 2024-09-25 01:32:35 char *sval; /* string value */ 2024-09-25 01:32:35 Awkfloat fval; /* value as number */ 2024-09-25 01:32:42 // ... 2024-09-25 01:32:45 } Cell; 2024-09-25 01:32:59 so perl has SV (string value) NV (number value) IV (integer value) in a struct thingy 2024-09-25 01:33:28 right 2024-09-25 01:33:48 same approach, but different names 2024-09-25 01:34:27 pretty sure ksh has something fairly similar 2024-09-25 01:37:11 oh really? 2024-09-25 01:37:24 Tcl eventually added something similar, I was arguing about that on Character Assassination News today 2024-09-25 01:38:09 https://news.ycombinator.com/item?id=41637953 2024-09-25 01:39:08 https://cvsweb.openbsd.org/src/bin/ksh/table.h?rev=1.15&content-type=text/x-cvsweb-markup 2024-09-25 01:40:23 interesting, I didn't expect ksh to have ints 2024-09-25 01:49:54 the ksh I have here is mksh and is running this test rather slowly: fib() { if [[ $1 -lt 2 ]]; then result=1; else local arg=$1; fib $(($arg - 1)); local tmp=$result; fib $(($arg - 2)); result=$(($tmp + $result)); fi; }; fib 35; echo "$result" 2024-09-25 01:51:29 sh code is often in the "too slow to benchmark" realm 2024-09-25 01:52:03 it finally output 14930352 after 196 seconds 2024-09-25 01:52:22 that's more than twice as fast as bash 2024-09-25 01:53:09 how about dash? 2024-09-25 01:54:26 dash doesn't have [[ so I'll have to adapt it 2024-09-25 01:54:58 [[ is speedier than execing out to [ also known as test(1) 2024-09-25 01:56:22 yeah but I think both dash and bash implement [ as a builtin 2024-09-25 01:57:53 86 seconds, more than twice as fast as mksh 2024-09-25 01:57:54 they do, but of course you can confirm that they aren't invoking an external test/[ binary with strace 2024-09-25 01:58:28 I'm reasonably sure dash didn't exec 14 million things in 86 seconds 2024-09-25 01:59:11 cool 2024-09-25 01:59:13 even if it does have a smaller memory map to copy than bash does 2024-09-25 01:59:35 i like dash and awk 2024-09-25 01:59:46 written tons of stuff in both 2024-09-25 02:00:41 linux is fast with forks. other OS, maybe not so much 2024-09-25 02:00:44 i noticed dash performed significantly better than bash on the system i'm using for fib 25. i wasn't going to wait for fib 35 2024-09-25 02:01:07 look at the BUGS section of the bash manual 2024-09-25 02:01:10 bash: real 0m5.029s / dash: real 0m0.907s 2024-09-25 02:01:11 fast is relative 2024-09-25 02:02:35 unjust: there are somewhat incompatible implementations in http://canonical.org/~kragen/sw/dev3/dumbfib.{fs,S,plx,js,lisp,lua,ml,py,scm,sh,tcl} 2024-09-25 02:02:40 bash's [ implementation seems slower than its [[ 2024-09-25 02:02:54 although I learned today I was Doing It Wrong in Tcl 2024-09-25 02:03:44 i saw the acknowledgement on SWAP 0 C! 2024-09-25 02:04:20 i mean 0 SWAP C! 2024-09-25 02:04:44 0 swap c!? 2024-09-25 02:05:46 Character Assassination News 2024-09-25 02:10:53 i'd be interested to know if clone(2) performs much better than fork(2) on linux 2024-09-25 02:10:53 i don't think i've ever used clone 2024-09-25 02:12:16 I think that on amd64 they are both library functions invoking the same system call 2024-09-25 02:13:13 man page say: Since glibc 2.3.3, rather than invoking the kernel's fork() system call, the glibc fork() wrapper that is provided as part of the NPTL threading implementation invokes clone(2) with flags that provide the same effect as the traditional system call. 2024-09-25 02:13:40 so not just on amd64, but clone(2) isn't the library function 2024-09-25 02:14:08 strace says: clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5235571850) = 30960 2024-09-25 02:14:57 is clone() from Plan9? 2024-09-25 02:15:55 i don't know, i never looked into plan9 or inferno at all 2024-09-25 02:16:28 they're cool 2024-09-25 02:16:38 as you'd expect from the name of "Inferno" 2024-09-25 02:19:05 if it'll cook my steak, even better 2024-09-25 02:19:38 what are the idealogical improvements in plan9 and inferno over unix though? 2024-09-25 02:19:39 most data centers are trying instead to keep the power bill down 2024-09-25 02:20:16 unjust: https://9p.io/magic/man2html/1/yesterday 2024-09-25 02:20:54 and then there's also clone3(2) 2024-09-25 02:21:11 heh @ BUGS It's hard to use this command without singing. 2024-09-25 02:22:37 i wonder what /n and /rc are for though 2024-09-25 02:23:14 I forget 2024-09-25 02:23:21 http://doc.cat-v.org/plan_9/3rd_edition/rio/rio_slides.pdf describes how they thought GUIs should work 2024-09-25 02:31:18 based on that document, it sounds like everything might actually be a file (or a file server?) in plan9 2024-09-25 02:31:28 it goes a lot farther in that direction than Unix, yeah 2024-09-25 02:31:34 it seems like an interesting approach to expose task-specific /dev/whatever-resource on a per process basis 2024-09-25 02:31:48 yeah, Linux eventually added that feature 2024-09-25 02:32:00 it turned out to be very popular 2024-09-25 02:32:06 Docker, for example 2024-09-25 02:33:09 i'm not familiar with docker or similar namespace based approaches to virtualization 2024-09-25 02:33:55 i guess that's a solution for userland virtualization? 2024-09-25 02:34:00 kind of yeah 2024-09-25 02:34:17 Android also runs each application in its own private namespace 2024-09-25 02:34:59 Nix goes even further 2024-09-25 02:37:49 it's really handy for avoiding several problems that are common in development environments: 2024-09-25 02:37:57 1. "It worked on my machine." 2024-09-25 02:38:22 2. "I just started working here, so I don't have a full dev environment set up yet." 2024-09-25 02:38:54 3. "I don't know, something must be different between staging and production that makes it crash." 2024-09-25 02:39:33 4. "But if I install that library systemwide, it'll break my web browser." 2024-09-25 02:40:25 resource namespacing, or Nix specifically? 2024-09-25 02:40:30 Docker specifically 2024-09-25 02:40:54 but it's per-process filesystem namespaces that make this possible 2024-09-25 02:41:06 what does the nested environment consist of? 2024-09-25 02:41:27 copies of only the necessary libraries and binaries required to make the target application work? 2024-09-25 02:41:27 a different view of the filesystem 2024-09-25 02:41:32 not copies 2024-09-25 02:41:43 access to 2024-09-25 02:42:37 so if someone unlinks libc.so.6 everyone suffers? 2024-09-25 02:43:44 no, changes like that are done in a per-container filesystem layer 2024-09-25 02:44:55 another neat thing about Docker is that it makes running text-terminal applications about as easy as visiting web pages 2024-09-25 02:44:58 for perspective, my closest point of reference to something like this is sticking minimal userlands into chroot environments 2024-09-25 02:45:08 yes, that's what I did before Docker 2024-09-25 02:45:35 totally by coincidence I did it again last week because it was something that was simpler to do with chroot than with Docker 2024-09-25 02:46:52 because someone wanted to know how to statically link X-Windows programs: https://news.ycombinator.com/item?id=41508011 2024-09-25 02:47:57 i remember sixel being somewhat slow to render 2024-09-25 02:48:08 at least in xterm 2024-09-25 02:48:36 yes, sixel was terribly slow to render, which was not really a problem in its original use, which was a dot-matrix printer 2024-09-25 02:49:26 current machines are fast enough that you *can* use sixel to play twitch video games 2024-09-25 02:49:34 but I'm not sure that means you *should* :) 2024-09-25 02:51:15 Yeso is not super fast to render either because all my Yeso programs so far do all the rendering on the CPU 2024-09-25 02:51:17 i last used it to display thumbnails from scraped video pages 2024-09-25 02:51:48 but at least it uses shared memory to pass the raw pixel data from the rendering program to the X server 2024-09-25 02:52:00 via imagemagick's convert ... sixel:- 2024-09-25 02:52:49 oh, I didn't know about ImageMagick file format prefixes 2024-09-25 02:53:17 I'm thinking it would be pretty cool to have a windowing system that works through the filesystem, but just a regular filesystem 2024-09-25 02:53:54 using named pipes or domain sockets for IPC? 2024-09-25 02:53:56 no 2024-09-25 02:54:07 the window server would just update window contents when you replaced a graphics file with a different one 2024-09-25 02:54:20 you'd have a subdirectory for each window on the screen 2024-09-25 02:54:30 like a framebuffer device per window, almost 2024-09-25 02:54:34 yes 2024-09-25 02:54:55 sounds rational to me 2024-09-25 02:55:01 and the window server would append mouse and keyboard events to a series of log files in the same directory as the image files 2024-09-25 02:55:57 with things like inotify, the filesystem parts of this setup only add hundreds of microseconds of latency, which is acceptable for most purposes 2024-09-25 02:56:16 would be useful for recording sessions at least 2024-09-25 02:56:33 yes, or for keyboard macros 2024-09-25 02:56:37 and i guess you could logrotate (or similar) the old stuff after some desirable period 2024-09-25 02:56:41 yes 2024-09-25 02:57:04 and running an application over an ssh connection would be some straightforward live file synchronization logic 2024-09-25 02:58:13 Linux unfortunately doesn't have any network filesystems that support inotify. SMB/CIFS does support notification but Samba and Linux's SMB client support don't 2024-09-25 02:58:27 FAM supported such notifications: https://web.archive.org/web/20050827205603/http://oss.sgi.com/projects/fam/doc.html 2024-09-25 02:58:38 but its replacement Gamin doesn't 2024-09-25 02:59:14 but even in that kind of case you could probably keep the latency down below 10 milliseconds with polling 2024-09-25 03:00:20 it would be quite straightforward to write GUI apps as dash or awk scripts 2024-09-25 03:00:56 my name for this fantastic piece of vaporware is `yvigil` 2024-09-25 03:06:35 i'm keen to see a poc 2024-09-25 03:09:38 if inotify doesn't work for existing network filesystems, does fanotify also avoid reporting on their events? 2024-09-25 03:19:04 i'm thinking that if you have write access to a framebuffer device, a quick and dirty proof of concept might just be writing a shell script that listens for inotify events in a directory on a local filesystem, awaiting writes to a designated window file in any subdirectory. each directory could have a shell script that amounts to the dd command line required to write the contents of the window file to the 2024-09-25 03:19:10 right place on "screen" 2024-09-25 03:20:24 so the listener script would just the dd script on receipt of a write to that window file 2024-09-25 03:23:32 s/just/& exec/ 2024-09-25 04:47:22 after writing a chunk of that, i realize it's necessary to merge all of the visible window views before writing to /dev/fb# - maybe tomorrow 2024-09-25 16:47:07 KipIngram: Read one more chapter. There just isn't much to disagree with. Maybe I'm not getting it? 2024-09-25 16:56:23 I'll be fair and say maybe that's just me. Lots of stuff seem agreeable, but not actionable. 2024-09-25 17:13:54 Well, I do think of it as mostly about a way of thinking, not so much a book of recipes. 2024-09-25 17:28:59 Should've looked for 'Doing Forth' :D 2024-09-25 18:06:56 :-) 2024-09-25 18:07:33 I think that one would be a more Forth-specific book. Maybe that's what Starting Forth is, but I've never consumed it to the degree I have TF. Mostly just perused it. 2024-09-25 18:08:27 I do think those are kind of the two big books, though. And if you want a old school FIG-oriented "nuts and bolds under the hood" treatment, there's nothing better that Forth Fundamentals volume 1, by McCabe. I think it's out of print, though. 2024-09-25 18:08:45 I never really understood how Forth works until I read that one. 2024-09-25 18:09:10 And I was kind of astounded at how much simpler it actually is than I had it cooked up to be in my head. 2024-09-25 18:09:27 I found it on the archive but couldn't get a copy. Bummer. 2024-09-25 18:16:17 i started by reading jonesforth 2024-09-25 20:31:18 user51: i've got a copy of FORTH Fundamentals as a directory jpeg images (you can convert it to PDF or whatever else you prefer) if you want it, i can upload them somewhere 2024-09-25 20:31:18 s/jpeg/of &/ 2024-09-25 23:04:30 Starting FORTH is better than Thinking FORTH 2024-09-25 23:04:55 Thinking FORTH has some good quotes though