2023-10-21 01:21:23 <KipIngram   > I wrote up some notes on these file system thoughts I've had the last day or two:
2023-10-21 01:21:25 <KipIngram   > https://pastebin.com/GrgVZ21F
2023-10-21 05:07:45 <KipIngram   > Anyone have a guess at the "common" range of "number of files per directory"?
2023-10-21 05:10:35 <KipIngram   > My only guess is "varies pretty wildly."
2023-10-21 05:10:51 <KipIngram   > Most directories I create never have too terribly many files.
2023-10-21 05:11:00 <KipIngram   > On the other hand, my /bin has 4556.
2023-10-21 05:52:54 <KipIngram   > You know, there are some really nice attributes of file systems, but some "pains" too.  I'm planning this system for remoting comments and other documentation.  It seems very straightforward to me to create a tree of links that connect "<block,  offset, range> to some other <block, offset, range>.
2023-10-21 05:53:06 <KipIngram   > I.e., "this text in this block" is connected to "that text in that block."
2023-10-21 05:53:39 <KipIngram   > And when I edit a block it will be easy to look up any links that involve the higher offset parts of that block and nudge their offset to account for the edit.
2023-10-21 05:54:33 <KipIngram   > But... if I have a file system, I might make a link from some text to something somewhere else, and then later edits might not just move that link's origin text to a different place in the block - it might SPLIT IT over a block boundary.
2023-10-21 05:54:53 <KipIngram   > So what then?  Logical thing would seem to be to make it two links.
2023-10-21 05:55:09 <KipIngram   > Which probably isn't actually problematic, is just is an annoyance.
2023-10-21 05:55:28 <KipIngram   > so I'm sitting here contemplating alternatives.
2023-10-21 05:56:02 <KipIngram   > The simplest one I see is to allow multiple blocks to be gathered together as a file, but treat them as "pages within files."
2023-10-21 05:56:26 <KipIngram   > That is, I'd still honor each block boundary - I'd just recognize that sequence of blocks as collected under a name.
2023-10-21 05:57:11 <KipIngram   > In that order.  In that case, I wouldn't have one "sentence" or whatever you want to call my self-contained bits of text, straddle a block boundary.
2023-10-21 05:57:33 <KipIngram   > So in a real way I'd still be working with blocks - I'd just have some help organizing and associated names with them.
2023-10-21 05:57:50 <KipIngram   > A file would be "a collection of blocks."
2023-10-21 05:58:05 <KipIngram   > Not one monolithic stream of stuff.
2023-10-21 05:58:47 <KipIngram   > I could still take a set of blocks and use them to copy an image into RAM - I'd just pay attention to the bytes in use of each one and glue them together properly.
2023-10-21 05:59:50 <KipIngram   > It seems like it might retain some of the "tidyness" of blocks, while getting me some of the organizational benefits of files, directories, and so on.
2023-10-21 06:00:49 <KipIngram   > And it's already how I was tacitly planning to handle the blocks a directory was stored in.  I wasn't going to let a directory entry split over block boundaries.  I'd just add directory items to the first block until the next one wouldn't fit, and then I'd chain a new one on and start filling it.
2023-10-21 06:01:19 <KipIngram   > Maybe I can just treat all blocks that way.
2023-10-21 06:03:02 <KipIngram   > The main change this would make would be that no word or line would ever split across blocks.  I'd be aware, while editing a "file" where those page boundaries were.
2023-10-21 06:03:51 <KipIngram   > In my editor I'd have a keystroke that would "block down" or "block up" - those would just follow one of the links at the end of the block to the next or previous one.
2023-10-21 06:04:14 <KipIngram   > My editor would keep me apprised of how much of a block I'd used, just like it does now.
2023-10-21 06:05:35 <KipIngram   > My guess is that I'll probably never have a directory that won't fit in one block, and most of the time I won't have a file that won't fit in one block.  I will have some such files, but probably not very many.  Except the system source - I kind of imagine putting that all in one "file."
2023-10-21 06:06:40 <KipIngram   > BTW, this b+tree link system would allow me to put a table of contents, that would get read as commentary, at the beginning of that source file, with links to the various chapters and sections.
2023-10-21 06:08:01 <KipIngram   > I think I'm talking myself into it.
2023-10-21 06:26:45 <KipIngram   > So, open a new file - there's a block.  I'd be able to edit it, add another one, insert blocks into files, cut them out, move them, etc.
2023-10-21 06:26:55 <KipIngram   > Like pages in a notebook.
2023-10-21 16:03:26 <KipIngram   > Last night I sketched out stack effect drawings for a basic set of words for manipulating a file system.  Surprise surprise, they looked a lot like the similar set of little Linux utilities.
2023-10-21 16:10:48 <KipIngram   > By the way, even just thinking about a file system underscores the need for literal strings.  You need to be able to call out file and directory  names.
2023-10-21 17:22:21 <zelgomer    > man. i thought i talked to myself too much
2023-10-21 17:23:19 <KipIngram   > I don't always do that, but sometimes I get caught up in whatever I'm working on and first thing I know I've been less than totally considerate>  :-(
2023-10-21 17:24:21 <KipIngram   > I did just suppress an urge to go off on quantum theory, though, so I can count that a small win.
2023-10-21 17:24:53 <zelgomer    > lol
2023-10-21 17:25:13 <KipIngram   > How's it going this morning?
2023-10-21 17:26:41 <zelgomer    > it's saturday, which means i'm finally going to sit down and start tinkering with ideas that have been bubbling up over the past two weeks
2023-10-21 17:26:59 <KipIngram   > Yeah, Saturdays rock.  :-)
2023-10-21 17:27:08 <KipIngram   > Which idea wins today?
2023-10-21 17:27:40 <KipIngram   > I've been bouncing around all over the place recently, but it is all pieces of one big project I'm trying to gear up to tackle.
2023-10-21 17:27:53 <KipIngram   > I think a lot before I actually start making things.
2023-10-21 17:28:12 <zelgomer    > the one i was talking about before, only tokenizing word definitions and deferring compilation to the semicolon
2023-10-21 17:28:25 <KipIngram   > Oh, yeah - I'm interested in where you go with that.
2023-10-21 17:28:34 <zelgomer    > i'm not sure how i will handle nesting though. like string literals or quotations
2023-10-21 17:28:39 <KipIngram   > I see some "parsing changes" coming in my future too.
2023-10-21 17:30:29 <zelgomer    > my idea is that [ ] will be a generic tokenizer. what's left on the stack after [ ] is just some object that can be consumed one token at a time. so interpretation of those tokens is deferred
2023-10-21 17:31:19 <zelgomer    > which means that now things like   : low-level-word  CODE  ... END-CODE   can now look like this   : low-level-word [ ... ] asm;
2023-10-21 17:31:27 <KipIngram   > I saw a video recently - Aaron Hsu on his codfns work re: APL.  He talked quite alot about how his code starts with a very "flat" syntax tree and gradually re-structures it.
2023-10-21 17:31:40 <KipIngram   > Might be something there that's of interest to you - I'll chase the link down in a bit.
2023-10-21 17:39:53 <KipIngram   > I think it was this one:
2023-10-21 17:39:57 <KipIngram   > https://www.youtube.com/watch?v=gcUWTa16Jc0
2023-10-21 17:40:14 <KipIngram   > it will probably only loosely related to what you're doing, but you might glean a tidbit or two.
2023-10-21 17:41:07 <KipIngram   > One thing I found interesting is that his 'compiler' doesn't iterate / loop at all - it's just a direct pass from the top of the code down to the bottom, with each statement "nudging" his tree toward its final form.
2023-10-21 17:47:55 <zelgomer    > interesting. thanks
2023-10-21 17:52:31 <zelgomer    > the truth is i'm not very good at this. using a computer language to describe a computer language twists my mind into knots
2023-10-21 17:54:03 <GeDaMo      > I've tried reading one of the papers on co-dfns but I can't get far into it :/
2023-10-21 17:58:32 <GeDaMo      > https://dl.acm.org/doi/pdf/10.1145/2935323.2935331
2023-10-21 17:58:41 <GeDaMo      > "The Key to a Data Parallel Compiler"
2023-10-21 17:59:09 <KipIngram   > It's a fascinating piece of work, but I've only made superficial progress grokking it too.
2023-10-21 17:59:23 <KipIngram   > It feels like it's an awfully elegant way to harness the GPU.
2023-10-21 18:00:07 <KipIngram   > APL's been one of the threads in my recent thinking - whatever i build next I want it to support arrays in that fashion.
2023-10-21 18:06:23 <veltas      > GeDaMo: That solid state air cooling is quite cool
2023-10-21 18:07:03 <GeDaMo      > Yeah, it's interesting
2023-10-21 18:07:16 <veltas      > China do a lot of amazing stuff
2023-10-21 18:07:19 <veltas      > Scary
2023-10-21 18:07:40 <veltas      > "quite cool" was not intended as a thrig-style pun
2023-10-21 18:15:44 <thrig       > I didn't invent it
2023-10-21 18:25:48 <KipIngram   > :-)
2023-10-21 18:35:04 <veltas      > The "symbols view" in github doesn't really understand C
2023-10-21 18:35:35 <veltas      > It seems to think stuff like `enum T` defines T everywhere it's used, even though it's necessary to write that in C to refer to the enum
2023-10-21 18:36:03 <veltas      > Which makes me wonder what kind of hacky abomination they wrote to get the symbol info
2023-10-21 18:37:16 <veltas      > Bear in mind elegant technology from a more civilised age like ctags gets this stuff right and is probably faster than what they wrote
2023-10-21 18:38:25 <KipIngram   > I'm no C expert, but ctags struck me as pretty nice.
2023-10-21 18:39:06 <KipIngram   > and, that makes me think of that Lisp cartoon - "These are your father's parentheses.  Elegant tools from a more civilized age."
2023-10-21 18:40:11 <GeDaMo      > https://xkcd.com/297/
2023-10-21 20:09:50 <rendar      > can we say that Forth is one of the safest language out there, because it hasn't syntax, lexing it is unbelievable easy and fast, and you can disable words that are unsafe
2023-10-21 20:09:59 <rendar      > e.g. is easy to confine the code
2023-10-21 20:41:02 <KipIngram   > Oh, I imagine you'd get argument from some people at least if you try to call Forth "safe."  It will let you do anything, including shoot yourself in the foot.  There's virtually no 'protection' of any kind.  For the most part the hardware is "laid bare."
2023-10-21 20:41:29 <KipIngram   > That said, I think you cite some nice benefits it offers.
2023-10-21 20:41:51 <rendar      > wait, i'm speaking theoretically here, i've a Forth that is a scripting language, it is interpreted, and it doesn't touch the underlying hardware at all
2023-10-21 20:42:26 <rendar      > using my forth is using like.. Lua into a project
2023-10-21 20:42:29 <KipIngram   > Ah, ok.  Fair enough.  So, you may well be in a position to say that, then.
2023-10-21 20:42:31 <KipIngram   > Sorry.
2023-10-21 20:42:45 <rendar      > no reasons to be sorry, i didn't mention it
2023-10-21 20:43:45 <KipIngram   > When I first got my currently operational Forth up and running, if I tried to access a memory location that wasn't an address that "belonged to me" (which is very easy to do while developing new code), I'd immediately segfault.
2023-10-21 20:44:02 <KipIngram   > I got sick and tired of that, so I spent a few days figuring out how to catch and respond to those exceptions.
2023-10-21 20:44:38 <KipIngram   > Now such mistakes are handled pretty much like regular compile errors - I fully restore the "start of line" state and drop back to the interpreter, so I'm ready to try again.
2023-10-21 20:44:44 <KipIngram   > Much more friendly environment.
2023-10-21 20:45:06 <KipIngram   > That was pretty hard to figure out, too - it's not documented out there very well, because it's  highly implementation dependent.
2023-10-21 22:13:57 <veltas      > All this stuff about "this language is the most X" is quite misguided in my opinion, there's a human element and some languages are better at some problems than others
2023-10-21 22:14:14 <veltas      > Forth definitely 'wins' over the other languages I know for some niche things, mostly not though
2023-10-21 23:19:28 <gordonjcp   > veltas: I wouldn't necessarily use Forth in a project I expect others to have to cope with
2023-10-21 23:19:34 <gordonjcp   > veltas: but it's probably the most "fun" to hack on
2023-10-21 23:20:02 <gordonjcp   > veltas: have you ever worked on and driven a really old car, or motorbike, or something like that?
2023-10-21 23:20:23 <gordonjcp   > you only need a handful of tools, everything's right there, under the bonnet there's like four wires of which only two are in any way important
2023-10-21 23:20:46 <gordonjcp   > and despite all this, it actually works perfectly fine like that
2023-10-21 23:22:19 <thrig       > needs more layers