2023-02-28 00:04:30 <dave0       > hey vms14
2023-02-28 00:09:12 <dave0       > lisbeths: i don't know how fast jonesforth is, but sectorforth is slow because almost all words use numbers, which have to be built in a round-about way
2023-02-28 00:10:38 <dave0       > for example almost all forth words use 2+ which is built from two 1+ which is built from zero and the successor function
2023-02-28 00:10:53 <dave0       > lisbeths: numbers are slow in sectorforth
2023-02-28 00:12:04 <lisbeths    > can't numbers be implemented as trees of pointers?
2023-02-28 00:12:46 <dave0       > don't know
2023-02-28 00:12:49 <lisbeths    > and I am still curious about the speeds on an optimizing processor
2023-02-28 00:12:59 <lisbeths    > can sector forth allocate cells if memory?
2023-02-28 00:13:07 <dave0       > yes
2023-02-28 00:14:04 <lisbeths    > so the number 1101 can be a list containing four things, a list containing one thing, a list containing one thing, the empty list, and a list containing one thing
2023-02-28 00:14:19 <dave0       > sectorforth doesn't do it that way
2023-02-28 00:14:32 <dave0       > in sectorforth, zero is built from nand
2023-02-28 00:14:49 <lisbeths    > how is it stored in the register
2023-02-28 00:15:05 <dave0       > as a single cell
2023-02-28 00:15:13 <lisbeths    > also nor is superior to nand afaik
2023-02-28 00:15:26 <lisbeths    > so 0 is an address?
2023-02-28 00:15:29 <dave0       > nand and nor can be used to build all the others
2023-02-28 00:15:48 <dave0       > 0 is all-bits-zero
2023-02-28 00:15:49 <lisbeths    > nor has better electric features I think
2023-02-28 00:16:02 <lisbeths    > and what is five
2023-02-28 00:16:23 <dave0       > hang on let me figure it out
2023-02-28 00:17:46 <lisbeths    > if its not 00000000101
2023-02-28 00:18:05 <lisbeths    > then its the result of function application
2023-02-28 00:19:18 <dave0       > : dup sp@ @ ; : -1 dup dup dup nand nand ; : invert dup nand ; : 1 -1 -1 + invert ; : 5 1 1 1 1 1 + + + + ;
2023-02-28 00:19:54 <dave0       > i did a homage to sectorforth that used - instead of + but they both work
2023-02-28 00:22:15 <lisbeths    > so that function produces what data on the register? does it end in 101?
2023-02-28 00:22:41 <lisbeths    > 101 is five in binary
2023-02-28 00:23:29 <dave0       > the number 5 is left on the stack
2023-02-28 00:24:07 <lisbeths    > so are you saying that you have to add the int 1 to the register five times?
2023-02-28 00:24:26 <dave0       > yeah that's one way of doing it
2023-02-28 00:24:54 <dave0       > you can also define   : 2* dup + ;    which makes large numbers a bit quicker
2023-02-28 00:25:23 <lisbeths    > how does jonesforth do it?
2023-02-28 00:25:29 <lisbeths    > or an ordinary forth
2023-02-28 00:25:45 <dave0       > jonesforth parses numbers and pushes them on the stack
2023-02-28 00:26:08 <dave0       > using  >number
2023-02-28 00:26:12 <lisbeths    > so the code to parse numbers can be in the interpreter sitting on top of sectorforth
2023-02-28 00:26:33 <dave0       > yes you could do that
2023-02-28 00:26:54 <dave0       > you can certainly write >number with sectorforth
2023-02-28 00:27:00 <lisbeths    > by how much would that speed up sectorforth
2023-02-28 00:27:01 <dave0       > it would be a lot of work but you could
2023-02-28 00:27:14 <dave0       > no idea, i've never done it
2023-02-28 00:27:31 <dave0       > you would have to write multiply
2023-02-28 00:27:50 <dave0       > or..
2023-02-28 00:28:02 <dave0       > it would be a bit easier if you only used decimal
2023-02-28 00:28:34 <lisbeths    > it seems clear that if the parsing of ints in sectorforth is slowing it down  then the parsing of the ints either needs to improve in sector forth or in the interpreter that runs ontop of it
2023-02-28 00:29:30 <dave0       > sectorforth doesn't parse numbers
2023-02-28 00:29:38 <dave0       > you would have to write your own parser
2023-02-28 00:29:44 <dave0       > which is >number
2023-02-28 00:30:48 <dave0       > sectorforth builds numbers from primitives   dup nand +
2023-02-28 00:30:51 <dave0       > like my example
2023-02-28 00:34:26 <dave0       > lisbeths: i think sectorforth is more of a proof by example that you only need a very few machine code primitives to build a forth
2023-02-28 01:23:06 <lisbeths    > sector forth is very important because in case of the apocalypse you can memorize sector forth and breathe a processor to life quickly
2023-02-28 01:23:30 <lisbeths    > its also easier to send back in time
2023-02-28 01:27:02 <lisbeths    > sector forth is also important for the design of very small processors
2023-02-28 01:27:36 <dave0       > you'd also need hackerman to hack you back in time
2023-02-28 01:30:57 <lisbeths    > I think with enough psychic mediums you could send it to the court of a king
2023-02-28 03:37:29 <dave0       > KipIngram: is `dp` the right name for the data space pointer? like would this be good code:   variable dp   : here dp @ ;   : allot dp +! ;
2023-02-28 08:15:03 <veltas      > If I had to write a programming environment from scratch I would probably go for a small kernel, write out assembly for it and compile to machine code by hand
2023-02-28 08:15:14 <veltas      > Of course it would be a forth
2023-02-28 08:15:22 <veltas      > But not as small as sectorforth
2023-02-28 08:15:59 <veltas      > Go and look at what people have done in history without compilers or machines to compile, they did what I suggested, not something like sectorforth
2023-02-28 08:43:31 <JITn        > TIL iCon ROFL
2023-02-28 10:19:52 <KipIngram   > dave0: Yes, DP is generally the name of the variable that points to the next byte that will be added to the dictionary.  Then
2023-02-28 10:20:00 <KipIngram   > : HERE  DP @ ;
2023-02-28 10:20:59 <veltas      > I've also seen H
2023-02-28 10:21:05 <veltas      > For the HERE variable
2023-02-28 10:21:18 <veltas      > Or just HERE as a VALUE
2023-02-28 10:24:42 <crc         > dave0: I use Free for this, though both DP and H have been used on several systems I've looked at in the past.
2023-02-28 10:33:38 <KipIngram   > LATEST will usually lead you to the header of the latest word that's been added to the dictionary.  It's not just a variable, though - generally there are several vocabulary words that point to the last word of that vocabulary, and LATEST takes you to whichever one of those is the current vocabulary receiving definitions.
2023-02-28 10:34:24 <KipIngram   > So you have something along the lines of
2023-02-28 10:34:38 <KipIngram   > : LATEST  CURRENT @ @ ;
2023-02-28 10:34:51 <KipIngram   > perhaps with some offsetting and so on to conform it to the particular implementation.
2023-02-28 10:35:11 <KipIngram   > CURRENT @ gets a pointer to a vocabulary word, and the next @ loads the actually leaf word pointer from there.
2023-02-28 10:35:27 <KipIngram   > s/actually/actual/
2023-02-28 12:20:33 <joe9        > any recommendations for a file system using forth? something more robust than blocks..
2023-02-28 12:29:03 <joe9        > I can write it in forth, if need be.
2023-02-28 12:29:18 <joe9        > But, I cannot find a fault tolerant design when it comes to file systems.
2023-02-28 12:33:51 <thrig       > some boffin, at MIT possibly, came up with a fully proven filesystem. it was too slow for practical use
2023-02-28 12:38:26 <crc         > I've written a few file system implementations. The only one I occasionally use is pretty simple. (None of mine were designed to be fault tolerant).
2023-02-28 12:38:28 <crc         > http://sprunge.us/0E5a87
2023-02-28 12:40:16 <crc         > I've also done (but not released or used in any actual applications) a Unix-like file system (inode based)
2023-02-28 12:45:44 <crc         > filesystems are something on my list of things to revisit in the future (my newest systems are all block based, so having a filesystem over the blocks might be useful)
2023-02-28 14:28:10 <qartis      > what do people the word that prints a number *without* a trailing space?
2023-02-28 14:28:28 <qartis      > * what do people CALL the word
2023-02-28 16:27:31 <KipIngram   > I don't see how anything could be more *robust* than blocks.
2023-02-28 16:27:39 <KipIngram   > You mean more *convenient*, right?
2023-02-28 16:27:58 <KipIngram   > I've seen it called (.)
2023-02-28 16:28:09 <KipIngram   > So then : .  (.) SPACE ;
2023-02-28 16:29:28 <KipIngram   > A file system would have to USE the block subsystem in its implementation, so it can't possibly be more robust than the words it uses.  I interpret robust as "correct operation under almost all circumstances."  If word set B uses word set A, then B will inherit all of A's problems but may add more problems - so "less robust.'
2023-02-28 16:29:59 <KipIngram   > Though I suppose you could argue that B might recognize problems in A and "work around" them, providing a less likely to err interface.
2023-02-28 16:31:49 <KipIngram   > joe9: I've been thinking some about file systems, and I think i'm going to go with a b*-tree based one.
2023-02-28 16:31:59 <KipIngram   > With something akin to inodes.
2023-02-28 16:32:16 <KipIngram   > Directories will just be files used for a special purpose, and will just associate a name string with an inode number.
2023-02-28 16:32:53 <joe9        > How do you plan to handle updates to a file's data?
2023-02-28 16:32:59 <KipIngram   > Then the inodes will contain all the meta information and will also have a pointer to a b*-tree that maps out all the blocks that comprise the file, along with how many bytes of valid data each block contains.
2023-02-28 16:33:01 <joe9        > copy on write? Or, update in place?
2023-02-28 16:33:23 <KipIngram   > Well, blocks will normally not be full, so many small updates will not need to change the block structure - it would just change the byte count for that block.
2023-02-28 16:33:43 <joe9        > overwrite the block then?
2023-02-28 16:33:43 <KipIngram   > At times blocks will get full, in which case the standard b*-tree practice is to split it into two blocks and add the new block to the b*-tree.
2023-02-28 16:34:01 <KipIngram   > Modify the block and update the count in the b*-tree appropriately.
2023-02-28 16:34:08 <KipIngram   > As well as whatever meta-info needed to be updated.
2023-02-28 16:34:31 <KipIngram   > Technically I don't think you'd NEED the metta data for it to work - it's just a luxury feature.
2023-02-28 16:34:40 <KipIngram   > All you really need is the b*-tree itself.
2023-02-28 16:35:12 <KipIngram   > b*-trees are pretty interesting and there's plenty of info on them on YouTube etc.
2023-02-28 16:35:52 <joe9        > What if there is a crash while the block update is happening?
2023-02-28 16:35:53 <KipIngram   > I saw a video a week ago or so on an improvement over them, but I think it would only pay off at very large scales.
2023-02-28 16:36:04 <KipIngram   > In a b*-tree actual DATA (file data) is kept only in the leaves.
2023-02-28 16:36:13 <KipIngram   > The interior nodes are all pointers to child nodes.
2023-02-28 16:36:20 <joe9        > imo, array > b*tree..
2023-02-28 16:36:39 <KipIngram   > In this improvement, the interior nodes were split between child pointers and "buffer spacE" that temporarily held newly written data, which gradually got flushed to the leaves.
2023-02-28 16:37:01 <KipIngram   > In a simplest implementation you'd probably be in trouble.
2023-02-28 16:37:15 <KipIngram   > To avoid trouble you'd need to do extra work, so that you could figure out how to recover.
2023-02-28 16:37:37 <KipIngram   > That actually goes beyond JUST the basic b*-tree algorithms.
2023-02-28 16:37:56 <joe9        > it has nothing to do with b*-tree stuff.
2023-02-28 16:38:09 <joe9        > It is about managing the data blocks on an update.
2023-02-28 16:38:20 <KipIngram   > The details would depend on how clever you were, but basically you'd need to make a record of the initial state, do your updates, and only when you had a confirmed valid final state erase that record.
2023-02-28 16:38:21 <joe9        > I cannot think of an easy solution for this.
2023-02-28 16:38:58 <KipIngram   > I guess it depends on what you think is "easy," but yeah - I imagine it's a fairly tedious process.
2023-02-28 16:39:03 <joe9        > confirmed valid final state erase that record. -- where would this record be stored?
2023-02-28 16:39:06 <joe9        > on the disk?
2023-02-28 16:39:07 <KipIngram   > And there's no way for it not to impair your efficiency some.
2023-02-28 16:39:15 <KipIngram   > Up to you.
2023-02-28 16:39:21 <KipIngram   > Somewhere you have enough confidence in.
2023-02-28 16:39:46 <joe9        > read/write a whole block of data just to store that record?
2023-02-28 16:39:50 <joe9        > it is a pita
2023-02-28 16:39:57 <KipIngram   > Sounds like you want there to be a slam dunk simple, low-cost solution, and I'm not sure there is.
2023-02-28 16:40:53 <KipIngram   > We use a journal in our drives.  Journal entries are written to flash, and the reason we have htem is because if power fails we don't have time to save all of our RAM tables to flash before we die.
2023-02-28 16:41:21 <KipIngram   > And those RAM tables are absolutely vital.  The journal gives us instructions on reconstructing them.
2023-02-28 16:41:40 <KipIngram   > Occasionally we save the RAM tables to flash and then delete the journal entries we'd need to recover that snapshot.
2023-02-28 16:42:30 <KipIngram   > and it's all pretty complicated - I couldn't really produce the whole algorithm from my head.
2023-02-28 16:42:59 <KipIngram   > But data corruption is just a completely unacceptable scenario for us, so we do whatever work we have to to believe we're protected against it.
2023-02-28 16:43:11 <KipIngram   > And even then it could still happen - if enough things went wrong at once.
2023-02-28 16:43:53 <KipIngram   > In our RAID6 system, you'd have to have three drives simultaneously fail (or fail within a narrow recovery window) in order for us to lose customer data.
2023-02-28 16:44:38 <KipIngram   > And on top of all of that customers are advised to use various mirroring schemes and so on to add even more safety.
2023-02-28 16:44:57 <KipIngram   > It's a many layered approach.
2023-02-28 16:45:20 <KipIngram   > But if a customer has to recover using mirrored data, we regard that as a failure.
2023-02-28 16:45:31 <KipIngram   > On our part, I mean.
2023-02-28 16:47:29 <KipIngram   > When I do a file system, I don't really want to devote space in hte leaf nodes (where the file data actually is) to other information - I want the whole block.  But at the same time, in files which are directories, I may incorporate some redundant information that helps make it more likely to recover the correct directory structure even in the event of point failure.
2023-02-28 16:47:49 <KipIngram   > And if I really wanted to do it RELIABLY, I'd put some such information in the data blocks too.
2023-02-28 16:48:32 <KipIngram   > For example, if every block stored the location of its parent and its grandparent, then even if you lost "a block" you could recover everything except that one block.
2023-02-28 16:48:45 <KipIngram   > You might have to do a brute force scan to do it, but you could.
2023-02-28 16:49:20 <KipIngram   > And if you wanted to do better, you could perhaps organize blocks into RAID stripes, and maintain the necessary RAID data.
2023-02-28 16:49:49 <KipIngram   > RAID5 = you can reconstruct a stripe even if one block in it completely is lost.  RAID6 = you can lose two block in a stripe and still recover.
2023-02-28 16:50:16 <KipIngram   > Usually that's done across different physical devices, but you could certainly do it within a drive if you wanted to.