2024-09-05 00:22:22 <xentrac     > veltas: the filesystem overhead is real, but it doesn't conventionally approach 2×
2024-09-05 00:22:43 <xentrac     > more like 2%
2024-09-05 02:06:31 <palter      > xentrac - They run it on both Windows and Linux.
2024-09-05 02:12:51 <xentrac     > palter: oh, so i386?
2024-09-05 02:17:00 <palter      > Yes. Long ago, it ran on a number of other platforms --  VAX, RS6000,  Sun 4, MIPS. None of those are relevant anymore.
2024-09-05 02:18:34 <xentrac     > you can still get new POWER chips
2024-09-05 02:18:58 <xentrac     > MIPS Inc. is pivoting to RISC-V
2024-09-05 02:23:17 <thrig       > aren't POWER a bit expensive
2024-09-05 02:24:55 <xentrac     > aye
2024-09-05 02:26:34 <crc         > zelgomer: I almost always put ; on the same line as the last word(s) in a definition, in both my block based system and the one using files
2024-09-05 02:27:22 <xentrac     > crc: do you think that's better?  I do too but I don't have a good reason for it
2024-09-05 02:28:39 <crc         > For me, it feels better. No real reason other than that, esp. on a system using files.
2024-09-05 02:29:44 <crc         > on a system using blocks, devoting a line to just a closing ; feels wasteful to me
2024-09-05 02:31:49 <crc         > For blocks, I have http://forth.works/share/NkatxWA13R.txt which is similar to the `INDEX` word veltas provided (this is in addition to a general `titles` word in the basic system image that runs against all blocks, and an interactive `catalogue` to browse/search through block titles)
2024-09-05 02:35:12 <crc         > and my son has written some tools to allow him to edit the contents of blocks using standard text or code editors (I don't use these myself, I just use my own block editors)
2024-09-05 02:36:00 <crc         > we have discussed attempting a FUSE approach to doing this more transparently, but not undertaken this yet
2024-09-05 02:36:05 <xentrac     > hmm, I wonder if F83 has bomsething like titles
2024-09-05 02:36:13 <xentrac     > *something
2024-09-05 02:45:03 <zelgomer    > i think i could rank style as one of my top three forth hurdles right now
2024-09-05 02:45:55 <zelgomer    > if i can fit a definition on one line, then it's fine. once it turns into multiline, i can't decide on how much like c it should look
2024-09-05 02:48:47 <zelgomer    > i'm sure the traditional answer is that i shouldn't have words that span more than obe line, but once you have a begin-while-until-then loop, with stack effect comments, there really isn't room for much more on one line
2024-09-05 02:50:46 <xentrac     > one possible source for viewpoints on this is to feed it to Gforth see
2024-09-05 02:51:55 <xentrac     > for example, for my earlier example of things using pc and goto:
2024-09-05 02:51:56 <xentrac     > : things
2024-09-05 02:51:57 <xentrac     >   0 pc over . swap 1+ tuck 10 <
2024-09-05 02:51:59 <xentrac     >   THEN ; ok
2024-09-05 02:52:18 <crc         > xentrac: Inside F83 by CH Ting mentions an `INDEX` word; it suggests using `0 CAPACITY 2/ INDEX` to see the first line of all source blocks in the system
2024-09-05 02:52:19 <xentrac     > I think that would benefit from some extra horizontal whitespace
2024-09-05 02:52:24 <xentrac     > crc: oh thanks!
2024-09-05 02:53:24 <xentrac     > that does sort of do the right thing but I think it sort of assumes I have the printer turned on
2024-09-05 02:55:15 <xentrac     > I forget if this was a general CP/M facility, I have a vague memory, but F83 handles ^P by toggling a flag which sends a copy of everything to the printer
2024-09-05 02:56:40 <xentrac     > (everything displayed)
2024-09-05 02:56:52 <xentrac     > this is handled with this definition of emit:
2024-09-05 02:56:52 <xentrac     > : (EMIT)   (S char -- )
2024-09-05 02:56:53 <xentrac     >    PRINTING @ IF  DUP (PRINT)  -1 #OUT +!  THEN  (CONSOLE)  ;
2024-09-05 02:57:29 <xentrac     > which means, yes, that it's checking the printing flag on every output character
2024-09-05 02:58:19 <xentrac     > I think index is intended for that
2024-09-05 03:03:40 <xentrac     > it doesn't seem to support ^S and ^Q to pause the index listing.  I did this:  : np 18 indexpage @ + indexpage ! 0 indexpage @ index ;
2024-09-05 03:07:09 <xentrac     > it seems a little bit goofy to me for it to check on every output character like that, since emit is already a deferred word in F83!
2024-09-05 03:09:20 <vms14       > how horrible is my concat lang for a forthwright?
2024-09-05 03:09:22 <vms14       > https://termbin.com/9x0a
2024-09-05 03:09:38 <vms14       > this is what the code does
2024-09-05 03:09:39 <vms14       > https://vms.neocities.org/oh
2024-09-05 03:10:01 <vms14       > I have to add collision detection and damage, then a way to kill the enemies
2024-09-05 03:10:20 <vms14       > you can move with wasd
2024-09-05 03:12:51 <zelgomer    > xentrac: i don't like the if-else-then each on a new lime with its body, but maybe i need to give it more chance
2024-09-05 03:17:26 <vms14       > I have mixed feelings with deviating so much from forth, forth is a well designed language unlike mine, I like the stack being able to get any kind of data, also the lexical scope, but I envy the possibilities forth allows, how managing memory is something quite natural and leads to a lot of possibilities
2024-09-05 03:18:00 <vms14       > I like the simplicity forth has to add its own data structures and accessors
2024-09-05 03:19:25 <vms14       > the problem is I make the interpreter on top of js, which has no memory management and I decide to not fake it. but then a lot of forth concepts cannot apply
2024-09-05 03:19:33 <vms14       > memory access*
2024-09-05 03:20:29 <vms14       > also I dislike the fact that forth encourages factoring, but in my lang every word adds a lot of overhead
2024-09-05 03:23:05 <vms14       > I know how to fake compile by caching the decisions of the interpreter in a list of closures, it gives some performance since the interpreter is quite slow, but is a dirty trick
2024-09-05 03:25:03 <xentrac     > zelgomer: I don't like it either
2024-09-05 03:25:46 <xentrac     > vms14: it looks cool!
2024-09-05 03:26:43 <vms14       > I learned to like it, but has 0 debugging features and drives me crazy every time I have a bug
2024-09-05 03:27:12 <vms14       > usually does not even realize there was a bug xD
2024-09-05 03:27:18 <xentrac     > haha
2024-09-05 03:27:56 <vms14       > https://termbin.com/s4fn this is the implementation
2024-09-05 03:27:59 <xentrac     > zelgomer: I think I probably tend to make my code too cluttered and cramped tho
2024-09-05 03:28:03 <vms14       > can also work in node
2024-09-05 03:28:23 <vms14       > but is missing a lot of words, I add them when I need them
2024-09-05 03:28:46 <vms14       > if you run it in node it will run a basic repl (I use rlwrap)
2024-09-05 03:29:16 <xentrac     > rlwrap is pretty handy
2024-09-05 03:29:27 <vms14       > if you run it in the browser it will load any <script type="oh"> also will fetch them if it has a src=""
2024-09-05 03:29:37 <xentrac     > Emacs shell-mode is very similar to rlwrap
2024-09-05 08:50:31 <veltas      > xentrac: If you've got lots of small files, e.g. lots of small source files, and you're on an already small disk, the overhead can be much higher
2024-09-05 08:53:09 <xentrac     > a small source "file" in a Forth screen occupies 1024 bytes
2024-09-05 08:54:23 <xentrac     > coincidentally, that is also the smallest unit in which CP/M could allocate storage to a file
2024-09-05 08:55:03 <xentrac     > the additional overhead CP/M adds in this case is a 32-byte entry in the disk directory
2024-09-05 08:56:11 <xentrac     > which is 3%
2024-09-05 08:57:15 <xentrac     > (large files can have many such entries in the directory to point to all their blocks)
2024-09-05 08:59:29 <xentrac     > so CP/M is actually worse in this way than Forth, but only by a few percent.  more sophisticated filesystems can allocate storage with finer granularity, which can save a lot of space
2024-09-05 09:04:26 <xentrac     > if memory serves, for example, HDOS, another RT-11-like 8080 operating system (the one Gordon Letwin worked on before Microsoft hired him) allocated space by 512-byte sectors instead; I think its directory was a little more bloated, because it had things like file modification dates
2024-09-05 09:18:39 <veltas      > And a big advantage of blocks is the numbers would be physical, it tends to have contiguous data usage and databases can calculate physical blocks to access on the first go for a given record ID
2024-09-05 09:18:56 <veltas      > Assuming the Forth is running as the OS
2024-09-05 09:21:05 <veltas      > I think there's a simple modification available for anyone that doesn't like how Forth blocks seem to waste space on whitespace, support control characters and don't use fixed line positions
2024-09-05 09:21:55 <veltas      > Then each block can represent up to a 1024 byte 'file', which is a bit more forgiving for spaced out code
2024-09-05 09:27:43 <xentrac     > yeah, it's definitely good to avoid levels of indirection that can give rise to fragmentation
2024-09-05 09:27:52 <xentrac     > I used to have to defrag floppy disks
2024-09-05 09:28:27 <xentrac     > (in the UCSD P-System, whose filesystem didn't support non-contiguous files)
2024-09-05 09:31:20 <xentrac     > I think in this case it's worth accepting the penalty of the level of indirection.  It might even have been worth adding an extra level of indirection, like an FTL, to support crash recovery and reduce seeks when writing
2024-09-05 09:36:01 <xentrac     > https://www.sydneysmith.com/wordpress/1651/cpm-disk-formats/ says conventional SSSD 5-1/4" disks were 35–40 tracks, 18 sectors per track, 128 bytes per sector.  That's 630-720 sectors on the disk.  If you grouped them into 3-sector allocation units, you'd have 210–240 units per disk, so you could store a physical-to-logical mapping in 210–240 bytes
2024-09-05 09:37:08 <xentrac     > sometimes people used 512-byte sectors like HDOS did, so there was less wasted space between sectors
2024-09-05 09:40:31 <veltas      > Yes but even without fragmentation your classic OS had to read at least one extra block to lookup a fixed offset in a file, often more
2024-09-05 09:41:02 <veltas      > Modern OS will cache this better but that means more RAM
2024-09-05 09:41:31 <veltas      > I'm interested to push limits of blocks and see how it works with more data
2024-09-05 09:41:51 <veltas      > Interested to know what sort of issues crc's run into as I'm assuming he has a LOT of block content to manage
2024-09-05 09:42:37 <veltas      > Blocks are a fun part of Forth, Forth has lots of fun stuff and this is one of them.  By the logic I'd prefer a file system I'd probably also avoid Forth in the first place
2024-09-05 09:43:38 <veltas      > Also I already wrote a sort of small embedded filesystem at work so it's "been there done that"
2024-09-05 09:43:56 <xentrac     > I'm pretty sure HDOS did cache the filesystem directory in RAM, but I'm not sure CP/M did
2024-09-05 09:44:39 <veltas      > Of current dir and root dir?
2024-09-05 09:44:52 <xentrac     > they didn't have a hierarchical filesystem
2024-09-05 09:44:57 <xentrac     > so there was only one directory :)
2024-09-05 09:45:02 <xentrac     > yeah, I'm interested in Forth not to make easy things difficult but rather to make difficult things easy!
2024-09-05 09:45:03 <veltas      > I only know FAT
2024-09-05 09:45:11 <veltas      > And ext4
2024-09-05 09:45:54 <veltas      > Forth is making easy things difficult though
2024-09-05 09:46:06 <xentrac     > that's not what it was invented for
2024-09-05 09:46:06 <veltas      > It's easy to support infix, for example
2024-09-05 09:46:21 <veltas      > Correct
2024-09-05 09:46:37 <xentrac     > and I feel like making it difficult to insert a card into the middle of my deck is in the "make easy things difficult" category
2024-09-05 09:46:56 <veltas      > I think Forth is about finding clever ways to get more done with less, and I think personally blocks are a valid way to achieve this
2024-09-05 09:47:16 <veltas      > Imagine you're using Forth as a baremetal system
2024-09-05 09:47:17 <xentrac     > they can be, and I think they were an understandable tradeoff at the time
2024-09-05 09:47:25 <xentrac     > but I still think they didn't pay off
2024-09-05 09:47:49 <xentrac     > I agree about getting more done with less!
2024-09-05 09:49:48 <xentrac     > no problem is as easy to solve as a problem you can avoid solving in the first place
2024-09-05 09:50:38 <xentrac     > so, if the question is, "How can I most easily write a filesystem?", I think it's very Forthy that the first thing they tried was "What if we don't?"
2024-09-05 09:50:57 <veltas      > If I wrote a filesystem for forth it wouldn't have more than one directory
2024-09-05 09:51:17 <xentrac     > because not writing a filesystem is definitely going to be easier than writing a small filesystem, just as not supporting infix is easier than supporting infix
2024-09-05 09:52:05 <GeDaMo      > "MCP internally uses a 'FLAT' directory listing all file paths on a volume." https://en.wikipedia.org/wiki/Burroughs_MCP#File_system
2024-09-05 09:52:11 <xentrac     > yeah, Oberon too
2024-09-05 09:52:20 <veltas      > Also need to bear in mind how Forth was used to build applications for a dedicated machine
2024-09-05 09:52:20 <xentrac     > for reasons of efficiency
2024-09-05 09:52:48 <veltas      > A filesystem is totally unnecessary for a lot of simple Forth applications/databases
2024-09-05 09:52:51 <xentrac     > well, initially!  polyFORTH has been deployed in lots more contexts than that
2024-09-05 09:52:58 <xentrac     > yes, agreed
2024-09-05 09:53:11 <xentrac     > but it's very helpful for a development environment:
2024-09-05 09:53:16 <xentrac     > - you can insert and delete lines
2024-09-05 09:53:28 <veltas      > You can insert and delete lines in the block editor
2024-09-05 09:53:42 <xentrac     > only until the block fills up!
2024-09-05 09:53:45 <xentrac     > - variable-length lines save space
2024-09-05 09:53:46 <veltas      > And insert/delete blocks
2024-09-05 09:54:05 <xentrac     > if you insert a block, you have to change the numeric references to the blocks that followed it
2024-09-05 09:54:09 <veltas      > I don't know how swiftforth et al do it but I have words to copy and blank ranges of blocks
2024-09-05 09:54:11 <xentrac     > for example in your load block
2024-09-05 09:54:23 <veltas      > Don't move first block unless you need to
2024-09-05 09:54:31 <veltas      > Change numeric references if you do
2024-09-05 09:54:49 <veltas      > There shouldn't be more than a couple of references to a block in source screens
2024-09-05 09:55:01 <veltas      > And it's easy to search for them too with the block editor
2024-09-05 09:55:16 <xentrac     > is it?
2024-09-05 09:55:30 <veltas      > Yeah there's a search command, can't remember exact name
2024-09-05 09:55:41 <veltas      > That searches for find buffer in blocks up to a given number
2024-09-05 09:55:51 <xentrac     > but for example 2 11 thru refers to block 7
2024-09-05 09:55:57 <xentrac     > how is the block editor going to find that?
2024-09-05 09:56:44 <veltas      > Search for 2 11 thru ?
2024-09-05 09:56:58 <veltas      > If that's how you refer to it
2024-09-05 09:57:28 <veltas      > If you've got a library that gets used everywhere then you can give it a name, and refer to that everywhere
2024-09-05 09:57:39 <veltas      > e.g. 2 11 2CONSTANT MY-LIBRARY
2024-09-05 09:57:44 <xentrac     > yeah
2024-09-05 09:58:15 <xentrac     > but I think it's more usual to just load the blocks and then refer to it by its vocabulary name
2024-09-05 09:59:04 <veltas      > You're allowed to name block numbers if you want
2024-09-05 09:59:20 <xentrac     > here's how F83's utility.blk begins its load screen:
2024-09-05 09:59:21 <xentrac     > \ Load Screen to Bring up Standard System             07Apr84map \ ( Load Screen to Bring up Standard System             03Apr84map
2024-09-05 09:59:25 <xentrac     >                                                                  \ )
2024-09-05 09:59:27 <xentrac     >   2 LOAD    ( Utilities )
2024-09-05 09:59:30 <xentrac     >   9 LOAD    ( STRINGS )                                          \ STRINGS   Character manipulation and case conversions
2024-09-05 09:59:33 <xentrac     >  12 LOAD    ( EDITING )                                          \ EDITING   The Starting Forth Editor, adapted to split screen
2024-09-05 09:59:33 <veltas      > Please don't copy all that in
2024-09-05 09:59:37 <xentrac     > I won't, don't worry!
2024-09-05 10:00:00 <veltas      > You can stick to numbers if it's more static
2024-09-05 10:00:09 <xentrac     > then at the end of block 2 it says 1 6 +THRU
2024-09-05 10:00:18 <veltas      > Interactive utilities like the editor won't be referred to more than once
2024-09-05 10:00:41 <veltas      > Can you not see how in this case, these block numbers are easier to manage because of the nature of what's in those screens?
2024-09-05 10:00:58 <xentrac     > Easier than what?
2024-09-05 10:01:01 <veltas      > This is the typical route for saying Forth 'needs' some generic feature modern OS's have by default, this "what if" exercise
2024-09-05 10:01:38 <veltas      > The painful truth is that Forths are very contextual and to avoid complexity you need to make decisions like this at every level, but it gets easier over time
2024-09-05 10:02:17 <veltas      > xentrac: Easier than it would be to manage say an evolving library that's used in many other blocks
2024-09-05 10:02:21 <xentrac     > Sure, what makes sense for a development workbench doesn't make sense for a motor controller
2024-09-05 10:03:08 <xentrac     > hmm, but presumably those *were* evolving libraries that were used in many other blocks at the time
2024-09-05 10:03:19 <xentrac     > although they stopped evolving 40 years ago
2024-09-05 10:03:24 <veltas      > The big thing F83 does that I might question is shadow screens, although they can be done right
2024-09-05 10:03:44 <xentrac     > I think they make a lot of sense on an 80×24 screen
2024-09-05 10:03:57 <veltas      > The editor isn'''''''''''''t a library
2024-09-05 10:04:04 <veltas      > Sorry bad connection
2024-09-05 10:04:08 <xentrac     > no worries
2024-09-05 10:04:21 <xentrac     > it's true, the editor isn't.  but strings is
2024-09-05 10:04:49 <xentrac     > (although, you know what else would make sense there? being able to use columns 64 through 79 in your source code!)
2024-09-05 10:05:11 <xentrac     > (but that would not allow you to print out two screens side-by-side on 132-column printers)
2024-09-05 10:05:59 <veltas      > The shadow listings I saw for polyforth would print two pages of screen triads, to show source on left page and shadows on right
2024-09-05 10:06:09 <xentrac     > yeah, F83 has a word for that
2024-09-05 10:06:12 <veltas      > Like a booklet
2024-09-05 10:06:20 <xentrac     >  43 LOAD    ( SHOWING )                                          \ SHOWING   A print utility for screens with/without shadows
2024-09-05 10:07:08 <veltas      > The point I'd make with F83 is that by the time it was released, it was 'done', so wouldn't need anything clever to handle evolving code
2024-09-05 10:07:20 <veltas      > And future releases presumably didn't move stuff around an incredible amount
2024-09-05 10:07:28 <xentrac     > maybe, yeah
2024-09-05 10:07:36 <veltas      > And the workarounds are not hard
2024-09-05 10:08:04 <veltas      > I guess you could consider a directory block containing some CONSTANT / 2CONSTANT defs to be a filesystem though lol
2024-09-05 10:08:25 <xentrac     > yes :)
2024-09-05 10:08:39 <veltas      > But I didn't sweat over writing that def so I think we're still satisfying the goal of more for less
2024-09-05 10:09:33 <veltas      > 1. Be your own filesystem  2. ????  3. PROFIT!
2024-09-05 10:09:54 <xentrac     > you could probably come up with a fairly small vocabulary that automated the process, though
2024-09-05 10:10:21 <veltas      > That's the danger with programming
2024-09-05 10:10:21 <xentrac     > Darius Bacon suggested that you could use triads as the allocation unit
2024-09-05 10:11:21 <xentrac     > more appropriate for the IBM PC with its 360KiB floppies, so your allocation unit numbers fit in a byte
2024-09-05 10:11:50 <xentrac     > but obviously even more wasteful than allocating by blocks ;)
2024-09-05 10:12:19 <veltas      > Yeah I don't think I'd do that
2024-09-05 10:12:25 <xentrac     > when I was using 100KiB disks under HDOS, I spent a lot of effort on saving space
2024-09-05 10:12:35 <xentrac     > Huffman-compressing files, that kind of thing
2024-09-05 11:08:37 <veltas      > And you get more 'screenspace' if you use printouts alongside your monitor
2024-09-05 15:55:05 <KipIngram   > But won't your INDEX info usually sit around in a block buffer in RAM, unless you happen to be doing something that does a lot of disk access?
2024-09-05 15:55:25 <KipIngram   > I tend to give my systems a LOT of buffers, since I'm hardly going to use all that RAM anyway.
2024-09-05 15:59:21 <KipIngram   > Oh, wait - I misread one of the comments above.
2024-09-05 15:59:32 <KipIngram   > Never mind that comment.
2024-09-05 16:00:44 <KipIngram   > I somehow got the idea that somehow the comment was about not reading the disk too frequently.
2024-09-05 16:01:32 <KipIngram   > veltas: I think if you've written enough Forth in your system to make the time taken to scroll out the index list be significant, you've done really well.  :-)
2024-09-05 16:57:53 <crc         > veltas: re: managing blocks, I have extracted some notes from earlier this year to http://forth.works/share/BrHczS8hoB.txt
2024-09-05 17:48:33 <rendar      > can we say that 'dup drop' is a nop and a smart compiler will nullify that operation?
2024-09-05 17:55:51 <crc         > with a traditional implementation, that'd technically be a nop
2024-09-05 17:56:36 <crc         > I've sometimes used things like that to introduce small delays in execution, which wouldn't work if the compiler was to optimize it away
2024-09-05 20:11:26 <xentrac     > veltas: what I mean is that my vague memory is that the machine I ran CP/M and HDOS on took about one second to read or write a track of the floppy, which was five kilobytes and thus would have been five index entries, and the MX-80 took about one second to print out a line, which is five times slower
2024-09-05 21:20:49 <veltas      > KipIngram: I'm thinking of e.g. old DOS Forths reading from floppy etc
2024-09-05 21:21:31 <veltas      > Also INDEX applied to all your blocks implies reading the entire disk, so I would guess that's pretty slow for e.g. a floppy disk
2024-09-05 21:21:55 <veltas      > You can skip binary blocks and database so I guess just reading the source screens isn't so bad
2024-09-05 21:27:18 <veltas      > rendar: I could imagine some compilers optimising it out
2024-09-05 21:33:03 <xentrac     > veltas: my recollection is that reading an entire floppy disk typically took on the order of a minute
2024-09-05 21:33:39 <xentrac     > but daisy-wheel, dot-matrix, and inkjet printers at the time were not close to six pages per minute or even two pages per minute
2024-09-05 21:39:42 <veltas      > Looking it up that is what I've seen reported, around a minute, I don't remember at all
2024-09-05 21:51:48 <veltas      > crc: Thanks for the blockpost, good read.  I think I remember using something like catalogue when I used ilo?
2024-09-05 21:52:03 <veltas      > And patching/diffing blocks sounds cool
2024-09-05 21:55:07 <veltas      > I'm currently spacing things 2/5/10/20 blocks in a group based on guesses
2024-09-05 21:55:27 <veltas      > Working on words for convenient moving around of blocks
2024-09-05 21:55:58 <veltas      > A defrag word would definitely be a good idea too, especially if generating source for a distribution
2024-09-05 21:56:31 <KipIngram   > Ah, that is a good point.  I lapsed into thinking of it like it was just listing a block or blocks.
2024-09-05 21:56:41 <veltas      > I've done barely anything with blocks but I can say that working with blocks is the most authentic feeling of Forth I've had so far
2024-09-05 21:56:51 <veltas      > It feels more interactive than anything else I've tried
2024-09-05 21:56:51 <KipIngram   > That would probably be worth caching if you could afford the RAM.
2024-09-05 21:57:01 <KipIngram   > For sure.
2024-09-05 21:57:42 <KipIngram   > And I strongly believe a Forth should offer block level access.  After all, that has to be done SOMEWHERE in a system, no matter what you've covered it up with, and Forth should offer you all of the "lowest level" stuff.
2024-09-05 21:58:21 <KipIngram   > In the other direction, I have no issue with a file system being built on top of it.  Disks are awfully big these days, and no one's going to block manage a terabyte drive (would be my guess).
2024-09-05 21:58:39 <KipIngram   > So I don't have any sort of "anti-file system" mentality.
2024-09-05 21:59:04 <veltas      > The thing is, I don't think any of the blockers have an anti-file-system mentality
2024-09-05 21:59:10 <veltas      > I think it's just a pro-block-mentality
2024-09-05 21:59:20 <KipIngram   > If I did a file system I'd probably set it up so that I had to explicity "give over" block pools to the file system - those not given I could still manage manually if I wanted to.
2024-09-05 21:59:33 <veltas      > And playing in the sand with blocks you realise what works, and so far I've not found anything that needs a file system
2024-09-05 22:00:17 <KipIngram   > Yes, and I've always felt a database built directly on blocks would be faster than one that had a file system interposed.  Particularly if that file system was attempting to be "generic" instead of db optimized.
2024-09-05 22:01:53 <xentrac     > KipIngram: yeah, you definitely need block-level access at some level, and I think the block/update/buffer/save-buffers interface is pretty nice
2024-09-05 22:03:54 <xentrac     > what I'm skeptical of is that it's a good tradeoff, specifically for an interactive development system, to not spend a page or two of code on a filesystem
2024-09-05 22:04:24 <xentrac     > (well, and of screens)
2024-09-05 22:05:05 <veltas      > I'd be interested in reading a filesystem in 2 screens (?)
2024-09-05 22:05:18 <xentrac     > oh, I meant 3-6 screens ;)
2024-09-05 22:05:27 <xentrac     > a printed page or two
2024-09-05 22:05:37 <veltas      > Or I think 2 screens is achievable
2024-09-05 22:05:50 <xentrac     > maybe so!
2024-09-05 22:06:14 <xentrac     > I think not doing it was a reasonable thing to try 50 years ago, but in retrospect it was a choice that didn't pay off
2024-09-05 22:11:29 <xentrac     > I did explore the possibilities a few months ago I think
2024-09-05 22:12:32 <xentrac     > yeah
2024-09-05 22:12:49 <xentrac     > 6 months ago
2024-09-05 22:13:23 <KipIngram   > Now that I think about it, INDEXing would just wreak havoc on your block cache.  In that DOS env you mentioned you'd have to read the whole floppy and that would almost certainly kick all of your useful content out of your block buffers.
2024-09-05 22:13:54 <xentrac     > F83 only had four block buffers anyway
2024-09-05 22:14:25 <KipIngram   > Seems like holding the range of blocks actually in use in variables somewhere would be helpful - at least then you'd only have to read THOSE blocks.  And anytime you modified a new one those variables would get updated.
2024-09-05 22:15:11 <xentrac     > you could imagine a sequentially word which would work like block but wouldn't promote the block it referenced to the front of the LRU list
2024-09-05 22:15:55 <xentrac     > then index could use that
2024-09-05 22:16:39 <xentrac     > my notes on how to write a Forth filesystem in two screens are in forth-micro-fs.md in http://canonical.org/~kragen/sw/pavnotes2.git/
2024-09-05 22:17:09 <xentrac     > I think it's a design sketch that ought to work, but it doesn't tackle the space-efficiency problem of screens
2024-09-05 22:19:45 <xentrac     > by "the range of blocks actually in use", do you mean the set of blocks that a filesystem layer had assigned to a file?  Or the set of blocks that were currently associated with an in-RAM block buffer?
2024-09-05 22:21:08 <xentrac     > looking at it now, there are definitely some things I wouldchange about the code in forth-micro-fs.md
2024-09-05 22:31:44 <KipIngram   > That's true.  Good idea.
2024-09-05 22:34:07 <KipIngram   > In the systems I've written I usually have blk-rd and blk-wr that both have stack effect ( n addr --) and which just do nothing but the indicated disk operation.  Then block etc. sit on top of that.  So blk-rd could handle this - you could read each block into PAD and copy the line out.
2024-09-05 22:34:20 <KipIngram   > And that wouldn't touch the buffers at all.
2024-09-05 22:35:10 <KipIngram   > Those lowest level words don't muck with any of that - blk-wr doesn't clear "update" bits, etc.  They just do what they're told.
2024-09-05 22:36:41 <KipIngram   > I've really only used them to implement BLOCK, but they are "there."
2024-09-05 22:40:08 <xentrac     > what did you mean by "the range of blocks actualy in use"?
2024-09-05 22:41:03 <xentrac     > coincidentally I'm watching an interview with an old friend of mine who deprecates people trying to write code in as few lines as possible: https://youtu.be/xIWMvtM02NA?t=3969
2024-09-05 22:42:52 <xentrac     > blk-rd and blk-wr do seem like things you'd definitely have to have
2024-09-05 22:44:11 <xentrac     > well, no.  F83 doesn't!  Here's its closest equivalent to blk-rd:
2024-09-05 22:44:26 <xentrac     > : FILE-READ   (S buffer-header -- )                              \ FILE-READ  read 1024 bytes from a file.
2024-09-05 22:44:29 <xentrac     >    SET-IO
2024-09-05 22:44:32 <xentrac     >    DO   2DUP SET-DMA  DUP REC-READ   1 SWAP RECORD# +!  B/REC +
2024-09-05 22:44:34 <xentrac     >    LOOP  2DROP  ;
2024-09-05 22:45:25 <xentrac     > set-io goes from the buffer header to, among other things, the actual buffer address
2024-09-05 22:46:05 <veltas      > Refactoring for me is about trying to understand code with my limited mental capacity
2024-09-05 22:46:16 <veltas      > Not a purist exercise
2024-09-05 22:46:37 <veltas      > Likewise writing more with less
2024-09-05 22:49:32 <xentrac     > *ideally* that's true for me as well ;)
2024-09-05 22:49:42 <xentrac     > but I definitely have purist tendencies
2024-09-05 22:50:22 <xentrac     > KipIngram: I think your factoring of block is better, though I don't quite understand the F83 factoring
2024-09-05 22:50:52 <xentrac     > set-io leaves 8 0 as the last two items on the stack because a CP/M "record" was 128 bytes so there were 8 of them in a block
2024-09-05 22:51:34 <xentrac     > b/rec is 128
2024-09-05 22:52:13 <xentrac     > and although this is the MS-DOG version of F83 I'm looking at here, it's using the FCB BDOS calls that MS-DOG inherited from CP/M, which access files by 128-byte records
2024-09-05 22:52:48 <xentrac     > I suspect they may have done it that way to facilitate portability between MS-DOG and CP/M
2024-09-05 22:53:13 <xentrac     > because it sure looks like the CP/M version was a backport
2024-09-05 22:53:24 <amby        > ms-dog?
2024-09-05 22:53:31 <amby        > is that a repeated typo or intentional
2024-09-05 23:23:27 <veltas      > xentrac: By the way re your local variables thing, if I was doing that I would use either the dictionary like a stack, or put all the vars contiguously to make saving/restoring simpler
2024-09-05 23:40:44 <xentrac     > veltas: those are both pretty reasonable ideas, although the first one implies you can't use local variables at the top level of a defining word such as constant