2024-08-22 02:09:20 <lispmacs[work]> hey, I just wanted to mention to those of you who are ed lovers, but secretly, deep-down are envious of Emacs users, there is a ed-mode package for Emacs
2024-08-22 02:10:21 <lispmacs[work]> all the functionality of ed, with only 3000 times the memory footprint ;)
2024-08-22 02:11:43 <amby        > when i log into my xenix system on my 100 baud teletype,
2024-08-22 02:20:26 <unjust      > xenix!
2024-08-22 02:27:53 <unjust      > xenix is probably m$'s best product ever
2024-08-22 02:29:36 <amby        > the NT kernel is apparently quite impressive
2024-08-22 02:29:41 <amby        > it's just a shame that the rest of the os sucks
2024-08-22 02:33:45 <unjust      > https://ibb.co/FzGmzcB
2024-08-22 02:46:34 <xentrac     > I've never tried using xenix myself
2024-08-22 02:47:15 <xentrac     > I feel like ed was a very nice UI design for a teletype
2024-08-22 02:47:47 <xentrac     > though maybe you could usefully do something slightly less half-duplex
2024-08-22 02:48:13 <unjust      > you can try it @ https://www.pcjs.org/software/pcx86/sys/unix/sco/xenix/086/2.1.3/
2024-08-22 02:52:24 <xentrac     > thanks!
2024-08-22 02:53:40 <xentrac     > I can't hear the floppy drive
2024-08-22 02:54:59 <xentrac     > aha, it's good to know that the P command works.  But man isn't installed
2024-08-22 02:55:56 <unjust      > i'm sure the 286 and 386 variants might be a bit more fully featured than the 8086 one
2024-08-22 02:57:09 <xentrac     > I was wondering whether P was a GNU addition to ed or whether it was present in early Unices
2024-08-22 03:00:12 <xentrac     > vi is installed!  That's a big upgrade in usability
2024-08-22 03:00:17 <xentrac     > also ls -C helps a lot
2024-08-22 03:01:18 <xentrac     > ctrl-backspace is the DEL assigned to intr
2024-08-22 03:02:20 <xentrac     > oh, but ctrl-W is really unfortunate
2024-08-22 03:03:13 <unjust      > closed your browser tab?
2024-08-22 03:05:00 <xentrac     > yup.  and the one next to it for good measure
2024-08-22 03:20:51 <xentrac     > I don't think man being installed or not is really a CPU power thing; I think it's more a disk space thing.  and I think the fact that Gforth doesn't have help is more a do-ocracy thing
2024-08-22 03:21:53 <unjust      > i think this installation is the bare minimum
2024-08-22 03:21:56 <unjust      > there're some games on the "SCO Xenix 8086 (GAMES)" floppy btw
2024-08-22 03:22:10 <unjust      > the device node it'll be associated with /dev/fd096
2024-08-22 03:22:27 <unjust      > the floppies are just tar archives for the most part
2024-08-22 03:22:37 <unjust      > you can check with dtype /dev/fd096 for example
2024-08-22 03:22:55 <unjust      > they seem to be created in relation to /
2024-08-22 03:23:31 <unjust      > so cd /; tar xvf /dev/fd096 gets a few binaries chucked into /usr/games/
2024-08-22 03:24:11 <unjust      > /usr/games/rogue looks familiar :)
2024-08-22 03:33:21 <unjust      > there should be a disk labelled M1 with manual pages, but this archive doesn't have it
2024-08-22 03:37:48 <xentrac     > heh
2024-08-22 03:38:56 <xentrac     > yeah, I imagine that if their package management system was tar, they didn't have uninstall
2024-08-22 03:39:12 <xentrac     > so installing something was an irreversible action
2024-08-22 03:41:17 <unjust      > i guess if you weren't concerned about existing files being overwritten at the time of installation, you could write a script to rm whatever's listed by tar tvf
2024-08-22 03:51:17 <xentrac     > I was more thinking about disk space being used up
2024-08-22 03:51:38 <xentrac     > like you're saying
2024-08-22 03:51:57 <xentrac     > I'm pretty sure I have in fact written exactly that script more than once in my life
2024-08-22 04:01:22 <unjust      > make installs without stdout and stderr redirection is one of things regret is made of
2024-08-22 04:01:40 <unjust      > (redirection to a file somewhere)
2024-08-22 04:08:33 <xentrac     > heh
2024-08-22 13:17:59 <veltas      > lispmacs[work]: This feels very targeted :P
2024-08-22 13:20:17 <veltas      > ed integrates perfectly into terminal work where you are working at the shell but need to "just change a couple of things" in a file
2024-08-22 13:20:45 <veltas      > You can see the terminal the whole time you're in there, you don't get this with fullscreen editors
2024-08-22 13:21:22 <veltas      > So I do use ed a lot, but it is because it's good at very specific tasks
2024-08-22 13:21:29 <veltas      > It's also good at editing git commit messages
2024-08-22 13:59:15 <user51      > Great at making people think you're a master  :)
2024-08-22 14:00:11 <user51      > Was thinking about forth's modes -- are there any forths that have modes other than interpreting/compiling?
2024-08-22 14:01:05 <veltas      > ed's super easy to learn, especially if you're familiar with vi
2024-08-22 14:01:17 <veltas      > But generally it's so simple that it's easy to learn
2024-08-22 14:01:20 <veltas      > Hard to master
2024-08-22 14:02:07 <veltas      > On some Forths STATE is a number that increments to represent how many nested functions deep you're in, I think(?)
2024-08-22 14:17:04 <unjust      > reforth does that iirc
2024-08-22 14:19:17 <unjust      > https://github.com/seanpringle/reforth?tab=readme-ov-file#sub-words
2024-08-22 14:19:51 <unjust      > "Implementing sub-words is easy. Many Forths could probably do it: 1. Make : (colon) an immediate word. 2. Turn Forth's compile/interpret flag into a counter. Have : (colon) increment it and ; (semi-colon) decrement. ..."
2024-08-22 14:21:11 <unjust      > ^ https://github.com/seanpringle/reforth/blob/master/reforth.c#L2187
2024-08-22 14:22:24 <unjust      > > https://github.com/seanpringle/reforth/blob/master/reforth.c#L2211
2024-08-22 14:35:47 <unjust      > maybe one of those master's user51 is talking about can tell me if there's a way in vim, or a standalone unix-spirited tool, that will parse assembly in a buffer/view and provide me with byte offsets in place of line numbers. as a replacement for set nu
2024-08-22 14:36:09 <unjust      > s/master's/masters/
2024-08-22 15:03:16 <veltas      > unjust: You want that sort of thing https://stackoverflow.com/a/18877483
2024-08-22 15:06:49 <unjust      > basically i want a column of instruction/data byte offsets dynamically generated by the editor/environment as i write/modify assembly source in the buffer. similar in presentation to what objdump produces for each instruction disassembled, but i don't want the offsets included in the file-under-edit/view
2024-08-22 15:08:29 <unjust      > i could live with it being included as part of the buffer though, certainly better than continuous manual counting and easy enough to remove afterward
2024-08-22 16:04:07 <xentrac     > unjust: maybe you could have some more columns which show the register values computed on each of those lines, computed from one or more test cases which are run in a bombproof isolated environment to generate those traces
2024-08-22 16:05:23 <xentrac     > and highlight the other rows which directly computed the inputs or use the outputs of the line your cursor is on, in one or more of those traces
2024-08-22 16:45:23 <unjust      > xentrac: that would be pretty useful in many cases
2024-08-22 16:54:13 <unjust      > that mli idea i had shown recently is looking promising in conjunction with binfmt_misc to have a lightweighter alternative than ELF for simple tasks so far
2024-08-22 16:55:22 <unjust      > s/lightweighter/lighter weight/
2024-08-22 16:56:59 <xentrac     > mli?  OCaml interface?
2024-08-22 16:57:18 <unjust      > "machine language interpreter"
2024-08-22 16:57:24 <xentrac     > oh right!
2024-08-22 16:57:54 <xentrac     > hmm, that's a really good idea!  especially for like rescue floppies
2024-08-22 16:58:02 <xentrac     > a bit less call for those lately
2024-08-22 16:59:02 <xentrac     > I wonder if it could support features ELF can't
2024-08-22 16:59:06 <unjust      > byte counts so far: 2 bin/true  14 bin/false  28 bin/yes  60 bin/pwd  94 bin/echo 135 bin/cat 333 total
2024-08-22 17:00:00 <xentrac     > why is /bin/false so big?  isn't that mov 1, al; ret?
2024-08-22 17:00:22 <unjust      > basically exit(1)
2024-08-22 17:00:50 <xentrac     > you don't have an implicit exit on return?
2024-08-22 17:02:56 <unjust      > no
2024-08-22 17:04:02 <unjust      > main calls run() (asm) which calls %rdi (mmap'ed) and main falls through to return EXIT_SUCCESS
2024-08-22 17:04:57 <unjust      > so bin/true is nop (the binary magic is 0x90 at offset 0 to keep the overhead to the absolute minimum); ret (implicit exit(0))
2024-08-22 17:05:29 <xentrac     > if you want to reduce byte count you might think about a bytecode interpreter rather than a machine language 'interpreter'.  though thumb-2 can come pretty close to things like Smalltalk and elisp
2024-08-22 17:05:44 <xentrac     > and RISC-V compressed of course
2024-08-22 17:06:21 <unjust      > that's definitely something to consider
2024-08-22 17:07:00 <unjust      > so far, i'm happy with the lack of complexity required to get this far without a real executable/object format
2024-08-22 17:07:02 <xentrac     > 16-bit ITC is a bit less compact in order to run faster.  RV32C imposes some unnecessary inefficiencies on software interpretation in order to be more efficient in hardware
2024-08-22 17:07:33 <xentrac     > I'm tempted to suggest running .hex files
2024-08-22 17:07:52 <xentrac     > higher byte counts but easier to edit
2024-08-22 17:07:55 <unjust      > as in the intel format?
2024-08-22 17:07:57 <xentrac     > yeah
2024-08-22 17:07:59 <xentrac     > okay, gotta go
2024-08-22 17:08:10 <unjust      > might as well support motorola s-rec as well :)
2024-08-22 17:08:17 <xentrac     > one or the other