2022-05-13 03:42:20 <veltas      > They should have designed the 'Grid' subsystem with VT100-like codes, then you could use a full-screen editor on serial
2022-05-13 03:43:22 <veltas      > They're using the Starting FORTH editor
2022-05-13 03:43:27 <veltas      > A block editor
2022-05-13 03:43:45 <veltas      > And they have a sort of cross between vi and the starting forth editor for their visual editor
2022-05-13 03:43:51 <veltas      > Again block based
2022-05-13 03:44:02 <veltas      > I think blocks are a mistake though, I know KipIngram doesn't
2022-05-13 03:46:15 <veltas      > Showing the content of the find/insert buffers is needless
2022-05-13 03:46:42 <veltas      > There should be a key to run forth commands, i.e. ':'
2022-05-13 03:46:50 <veltas      > I shouldn't need to quit to do that, anyway
2022-05-13 09:47:26 <KipIngram   > I think blocks are "fine," but I do think that eventually one wants a file system.
2022-05-13 09:48:35 <KipIngram   > veltas: If you're writing from bare metal and have to do it all yourself, it seems kind of obvious to me that you need a "block layer."  Sure, maybe you build more on top of it, but working with fixed size pages is the natural "fundamental way" of approaching storage.  Every storage system I know has that layer at the most bottom layer.
2022-05-13 09:49:15 <KipIngram   > I think to argue that on a Forth running on an OS it's worth bypassing that layer is... "not a invalid argument."
2022-05-13 09:49:31 <KipIngram   > In that case you don't HAVE to start with blocks - the file system is "already there, given to you."
2022-05-13 09:49:51 <Zarutian_HTC> 
ACTION hands KipIngram an IBM DASD with variable sized records where 'gaps' are used to seperate them

2022-05-13 09:50:02 <KipIngram   > I'm primarily doing it because I am planning for eventual deployment on bare metal, and I want to have as much of that working as possible in the first place.
2022-05-13 09:50:18 <KipIngram   > Yeah, I'm not familiar with that one - I'll have to take a look.
2022-05-13 09:50:37 <KipIngram   > The SSDs I work with have 16k fundamental page size - the older systems I worked with used 4k.
2022-05-13 09:51:12 <Zarutian_HTC> oh or the 512 byte sectors of old hds
2022-05-13 09:51:17 <KipIngram   > Right.
2022-05-13 09:51:42 <Zarutian_HTC> and floppies
2022-05-13 09:52:34 <KipIngram   > So, maybe it's not universal, but it's "pervasive" in storage to have a "logical page size."  In our case we have hardware compression, so the physical page size is different, and physical pages each hold two "code pages," which hold variant amounts of logical pages depending on compression results.
2022-05-13 09:53:00 <KipIngram   > And a logical page can "straddle" code pages, so sometimes we have to read two code pages to get what we need to decode that particular logical page.
2022-05-13 09:53:48 <KipIngram   > So we always read full physical pages, though there's a function called "snap" read that may return just one or the other of the two code pages, saving the transmission time of the second un-needed code page.
2022-05-13 09:56:25 <Zarutian_HTC> but here is a thing, I would not say no to an pure Forth implementation of exFAT
2022-05-13 09:57:31 <KipIngram   > Yeah, I have decided that having some kind of "help" from the system for managing what you store on disk.
2022-05-13 09:58:03 <KipIngram   > I've planning a b*-tree based system.  I'm sure it won't be the fanciest file system ever, but it's "straightforward" and should work fine.
2022-05-13 09:58:16 <KipIngram   > Not going to do journaling or anything fancy like that.
2022-05-13 09:58:27 <KipIngram   > Just a straightforward hierarchy of directories.
2022-05-13 10:00:13 <KipIngram   > And I do like the way the traditional Forth block system handles disk buffers transparently for you.  I believe having a large number of disk buffers, with a logical block to buffer hash algorithm, is a great way to make use of copious ram.
2022-05-13 10:00:23 <Zarutian_HTC> there was this DCPU-16 hierchical filesystem that was stupidly simple
2022-05-13 10:00:43 <KipIngram   > I wrote BLOCK to be as fast as possible in the "already resident" case.
2022-05-13 11:54:43 <KipIngram   > The already resident case is a primitive; if it finds the block is not resident it will transfer to Forth definitions for dealing with the actual disk access.
2022-05-13 13:04:01 <veltas      > People always write quality comments on Forth HN posts https://news.ycombinator.com/item?id=31368212
2022-05-13 13:04:20 <veltas      > Lots of people don't like Forth but generally people are respectful (or scared)
2022-05-13 13:04:27 <veltas      > It's a bit like lisp in that regard
2022-05-13 13:07:15 <veltas      > KipIngram: If I do a filesystem again I'll try using a hash table approach
2022-05-13 13:07:40 <KipIngram   > Surely if there is such a fear it's a fear born of ignorance - there's nothing really "hard" about Forth.
2022-05-13 13:08:27 <veltas      > But last time I just made directories and files a singly-linked list of blocks, and made directories contain just a list of the files inside
2022-05-13 13:08:29 <KipIngram   > Yeah, hashing works fine too.  Probably higher performance.
2022-05-13 13:08:38 <KipIngram   > I'm also fairly sure that GForth uses hashing for its dictionary.
2022-05-13 13:08:45 <veltas      > I think maybe they're worried about the people defending it rather than the language
2022-05-13 13:08:55 <KipIngram   > I just can't believe it's as fast as it is using a straight linked list search.
2022-05-13 13:08:55 <veltas      > I'm not talking about dictionaries
2022-05-13 13:08:59 <KipIngram   > I know.
2022-05-13 13:09:09 <KipIngram   > Just another note of how fast hashing can be.
2022-05-13 13:09:46 <KipIngram   > Oh, I see.  Don't want to set off any of us Forth nuts.  :-)
2022-05-13 13:10:01 <MrMobius    > hehe
2022-05-13 13:10:28 <veltas      > Linked list approach is the classic filesystem approach and it's fast at sequential reading of files, and lookup is okay if your directories aren't too big and you use sensible caching of path resolution
2022-05-13 13:10:28 <KipIngram   > I assumed you were talking about getting from a filename / pathname to some starting point on the disk.
2022-05-13 13:11:25 <veltas      > In UNIX-compatible filesystems you should probably store names/paths separately to inodes
2022-05-13 13:11:28 <veltas      > For simplicity
2022-05-13 13:11:35 <veltas      > But if you don't want hard links then yeah
2022-05-13 13:12:17 <KipIngram   > I've never been totally clear on the difference between hard and soft links, and I've really only ever used soft links.  I know that a Linux directory entry stores # of hard links to the item.
2022-05-13 13:12:27 <KipIngram   > But I've never gone and "read up" on the details.
2022-05-13 13:12:49 <veltas      > In UNIX every file is an inode. It is available via hard links. The typical case is there is one hard link for an inode
2022-05-13 13:13:20 <veltas      > It's like a pointer though, you can have hard links elsewhere and they work just the same, if you modify one it modifies the other as well
2022-05-13 13:13:45 <veltas      > When you run 'rm' it actually runs a call called 'unlink()', i.e. it removes a hard link
2022-05-13 13:13:54 <veltas      > And when the last hard link is gone, the file is properly removed
2022-05-13 13:13:57 <KipIngram   > Ah, I see.
2022-05-13 13:14:11 <veltas      > And you can reference count this because it's stored in a tree structure (filesystem)
2022-05-13 13:14:50 <KipIngram   > The main thing I've ever done with soft links is resolve situations where some program can't find a library it needs.
2022-05-13 13:14:51 <veltas      > We have symbolic links as well which are a sort of 'non-owning' link, and also more portable (can point to other filesystems/mounts, be put in tar etc)
2022-05-13 13:14:57 <KipIngram   > Usually I'm half-guessing.
2022-05-13 13:15:33 <veltas      > Hard links can only be used on one filesystem and many utilities aren't inode-aware so may do dumb things with them
2022-05-13 13:15:49 <veltas      > It turns out hard links aren't actually a very good concept, so I wouldn't put them in a new design
2022-05-13 13:16:20 <KipIngram   > I also use soft links to store actual .git directories somewhere remote from my actual project directory.  I have a repos directories under my Dropbox.
2022-05-13 13:16:28 <KipIngram   > directory
2022-05-13 13:17:07 <veltas      > To programs that aren't trying to be symbolic-link aware (which is pretty much everything except ln and ls) it is equivalent
2022-05-13 13:17:27 <KipIngram   > I once had an inadvertent space in am rm *??? command, and wiped out my whole project directory.  It took .git too.
2022-05-13 13:17:37 <KipIngram   > But it doesn't seem to if .git is a soft link.
2022-05-13 13:17:47 <KipIngram   > Just takes the link.
2022-05-13 13:17:53 <veltas      > The problem with symbolic links is they complicate path resolution and can impact performance (you now need two resolutions instead of one)
2022-05-13 13:18:01 <veltas      > (or more if it's a chain of links)
2022-05-13 13:18:34 <veltas      > And you need to detect a link cycle (or actually just give up at a fixed number of redirects)
2022-05-13 13:18:52 <KipIngram   > Right.
2022-05-13 13:19:06 <veltas      > It's a powerful tool, I don't think it's essential to a filesystem design
2022-05-13 13:19:14 <KipIngram   > Anyway, I decided that particular use was a good safety feature - makes the .git directories more secure.
2022-05-13 13:19:28 <veltas      > I think good directory structure design can often avoid the need for symbolic links
2022-05-13 13:19:31 <KipIngram   > Against user screw ups.
2022-05-13 13:19:40 <veltas      > Why does it make them more secure?
2022-05-13 13:20:01 <veltas      > Against rm -rf?
2022-05-13 13:20:03 <KipIngram   > rm * in the project directory removes the .git soft link, but doesn't remove the remote directory itself.
2022-05-13 13:20:05 <KipIngram   > Yeah.
2022-05-13 13:20:15 <veltas      > rm -r * wouldn't remove .git
2022-05-13 13:20:16 <KipIngram   > I didn't MEAN to do that, but I did, once, so I could again.
2022-05-13 13:20:27 <KipIngram   > Well, something I did did remove it.
2022-05-13 13:20:37 <KipIngram   > I don't remember exactly what it was; it's been a while.
2022-05-13 13:20:57 <KipIngram   > but it was some sort of typo thing.
2022-05-13 13:21:06 <veltas      > Firstly, * doesn't match dot files. Also, .git contents is all write-protected so -f is needed to remove contents
2022-05-13 13:21:33 <KipIngram   > Yeah, like I said - I don't remember precisely what I did, and may not have even fully grasped the details at the time.
2022-05-13 13:21:41 <KipIngram   > But somehow I removed my .git, along with everything else.
2022-05-13 13:22:27 <veltas      > I always put .git repos on github or some other server and push/pull regularly to backup
2022-05-13 13:23:17 <KipIngram   > Yep.  I don't.  So this made sense to me.
2022-05-13 13:24:15 <KipIngram   > Anyway, the only real point here was that it was something I'd done with a soft link other than resolve a library reference.  Probably the only other thing.
2022-05-13 13:25:54 <MrMobius    > i have a shortcuts folder with soft links to project folders i use often
2022-05-13 13:26:26 <MrMobius    > unfortunately when you cd to it it keeps its link name and doesnt resolve to the actual path
2022-05-13 13:26:55 <MrMobius    > i also made a script that gives me a list of directories and i pick which one to have it cd to
2022-05-13 13:27:05 <KipIngram   > If you then run pwd you get the real path, though, right?
2022-05-13 13:27:06 <MrMobius    > havent figured out the smart way to do this on *nix yet
2022-05-13 13:27:15 <KipIngram   > I'm guessing.
2022-05-13 13:27:31 <MrMobius    > probably. it's still nice to have it right there to keep yourself straight
2022-05-13 13:27:38 <MrMobius    > without pwd i mean
2022-05-13 13:27:47 <KipIngram   > Right.  I'm checking that now.
2022-05-13 13:28:45 <KipIngram   > No, pwd seems to reflect the softlink too.
2022-05-13 13:29:05 <MrMobius    > right
2022-05-13 13:29:23 <KipIngram   > Well, I'll add that to my list of wrong guesses for the day.
2022-05-13 13:30:02 <MrMobius    > the best thing ive found is to navigate to the project directory i need, start tmux, detach, navigate to next project directory, start tmux, detach etc
2022-05-13 13:30:03 <KipIngram   > You could replace those softlinks with little scripts that cd'd to the actually projects.
2022-05-13 13:30:17 <MrMobius    > then just switch between tmux sessions
2022-05-13 13:30:27 <KipIngram   > I have a collection of little scripts in /usr/local/bin that will establish mosh connections with my work servers.
2022-05-13 13:30:39 <KipIngram   > Or re-connect to an existing connection.
2022-05-13 13:31:08 <KipIngram   > Re-connecting to a currently running screen session is the default - if I give any parameter to the script then it just establishes a new non-screened session.
2022-05-13 13:33:13 <KipIngram   > When I reboot a host, I usually then will say '<host> boot', and start a screen session.  Then later I can just say '<host>' and it'll take me back into the screen session.
2022-05-13 13:34:20 <KipIngram   > I love mosh, btw - one of my favorite pieces of software.
2022-05-13 13:37:36 <KipIngram   > Set things up right and it makes working with remote hosts more or less just like local sessions.
2022-05-13 13:40:14 <KipIngram   > Close your computer and go to bed - next morning and open it up, and there's your session.
2022-05-13 18:49:38 <veltas      > KipIngram is your filesystem done yet
2022-05-13 18:55:39 <KipIngram   > No - I'm an abysmal slob of a failure...
2022-05-13 18:58:28 <veltas      > Don't be so hard on yourself :P
2022-05-13 18:59:10 <KipIngram   > Seriously, my most immediate goal is to get an editor working.  Though I'll first be editing blocks, I want it to be "willing" to do files without a complete re-design.
2022-05-13 18:59:51 <KipIngram   > There will be a "thing" I'm editing - either a block or a source, and I just intend to unpack the lines into an array of line buffers, and then when I'm done pack them back to the disk.
2022-05-13 19:00:27 <KipIngram   > The whole idea the last couple of weeks was to make that single line 'read' ready to work in that wrapper.
2022-05-13 19:00:59 <KipIngram   > When it gets a key it doesn't understand, it returns.  I can take some action in the wrapper based on that and re-call it, often on a different line buffer.
2022-05-13 19:01:28 <KipIngram   > I don't expect it to be that hard, but I'm hardly working on it full time.  Got some woodworking I want to do this weekend too.
2022-05-13 19:01:50 <KipIngram   > We bought a new stovetop not long ago - I want to frame up the old one and put LP nozzles on it - outdoor stovetop.
2022-05-13 19:02:08 <KipIngram   > Strong enough to hold a big 10 gallon or so pot of water, for beer brewing.
2022-05-13 19:02:56 <KipIngram   > Plus I'm about a third of the way through a book a chat friend from the Reddit sub I help moderate asked me to read.
2022-05-13 19:03:40 <KipIngram   > It's an urban fantasy yarn written by a guy I'd never heard of before.
2022-05-13 19:11:39 <KipIngram   > Pretty good so far, but I have no idea yet why he particularly wants me to read it.
2022-05-13 19:12:28 <KipIngram   > The reddit sub I mentioned is one that focuses on another urban fantasy series, by a guy named Jim Butcher.  I think he may suspect the author of the one he asked me to read as a possible ghost writer for Butcher.
2022-05-13 19:12:40 <KipIngram   > So I'm trying to keep an eye out for "Butcher-isms."
2022-05-13 19:13:14 <KipIngram   > Wouldn't surprise me if he's kind of sick of his series - he's ground out 17 novels of it over the last 22 years.
2022-05-13 19:13:46 <KipIngram   > He says he's planning about 25 all told, unfolding a big arc tory, and that it will wrap up with a big climactic trilogy.
2022-05-13 19:14:06 <KipIngram   > I just hope I live long enough - his pace has fallen off the last few years.
2022-05-13 20:04:31 <KipIngram   > veltas: anyway, I'm just not very far away from being able to develop "within the system" in earnest, and that's what I'm aiming at first.  Then I'll think about things like a file system and other such things.
2022-05-13 20:05:09 <KipIngram   > I do think it's one of the first things I should focus on - it will pay dividends.