2023-12-27 07:04:56 <crc         > user51: re: a fancier repl; I have one in development for my larger Forth
2023-12-27 07:10:57 <crc         > https://asciinema.org/a/4FYHF4I2ZsJupy8xUtdmJeZOo shows a short demonstration of it
2023-12-27 07:29:50 <user51      > crc: Can it also show the rstack?
2023-12-27 07:30:39 <crc         > no
2023-12-27 07:32:56 <crc         > my system doesn't provide addressable stacks. For the data stack I copy it out to an array, print the values as I restore them to the stack. I can't do this for the rstack.
2023-12-27 07:33:12 <GeDaMo      > What would you want to see on the rstack? Return addresses wouldn't be much use, maybe if it was the name of the word it was returning to
2023-12-27 07:38:11 <crc         > for me, address stack usage is mostly of interest during debugging; I can show it there since autopsy runs a nested vm with separate data/address stacks
2023-12-27 07:38:29 <user51      > GeDaMo: For those pesky words that do r> drop.  Otherwise, just curiosity.
2023-12-27 07:38:39 <GeDaMo      > Ah
2023-12-27 07:40:34 <GeDaMo      > I think some forths have an rdrop word for that :P
2023-12-27 07:40:52 <crc         > I only have a few of those: case s:case f if; -if;
2023-12-27 07:41:01 <crc         > and f
2023-12-27 07:41:05 <crc         > f:case
2023-12-27 07:49:33 <KipIngram   > GeDaMo: How easy it is to get from a return address on the stack would vary in difficulty depending on the system architecture.  Usually there would be a way, but it might be slow and inefficient (i.e, you  might have to search the whole dictionary to find the word that occupied that address range).
2023-12-27 07:50:14 <GeDaMo      > Yeah, I'm just saying that would be more useful than random addresses
2023-12-27 07:50:18 <KipIngram   > I don't usually need to do that - I agree it would be of most use during debugging, and I usually just debug with debug prints.
2023-12-27 07:50:34 <KipIngram   > I definitely agree.  It's what I'd want from the rstack.
2023-12-27 07:51:12 <KipIngram   > I dream about a nice integrated development environment eventually, and in those dreams it includes a name-specifying call stack that evolves as I step through the program.
2023-12-27 07:51:36 <crc         > depending on the system, resolving names may not be possible (e.g., in my konilo forth, the word names are not stored, only a hash of the name)
2023-12-27 07:52:08 <KipIngram   > Interesting.  I've never written one like that.
2023-12-27 07:52:21 <KipIngram   > So you can't even have WORDS in that system?
2023-12-27 07:52:32 <crc         > no
2023-12-27 07:55:11 <crc         > I can display a list of the standard words in the kernel + standard startup blocks via a bit of a hack though
2023-12-27 07:55:37 <crc         > Each word in those has a glossary block, so I can get word names from those.
2023-12-27 07:55:51 <crc         > e.g., via http://forth.works/share/q5EcElkDNP.txt
2023-12-27 08:43:14 <vms14       > : words env .word keys sort ;   but this would only give the current env words
2023-12-27 08:45:43 <KipIngram   > I've always just sort of automatically kept a list of words "somewhere."
2023-12-27 08:46:41 <KipIngram   > I see the benefit of using a hash, so you can kind of go straight to the right place with no search attached, but generally I assume I've got enough room to have a copy of the word name there.  And of course hashes CAN collide, so the only way to be 100% sure about something is an explicit name comparison.
2023-12-27 08:47:07 <KipIngram   > I mean, you can lower the probability of a collision as much as you want, but to get it really low you have to have a very sparse hash table.
2023-12-27 08:47:19 <KipIngram   > Lot of unused table space.
2023-12-27 08:48:52 <KipIngram   > Table doubling approaches to hashing seem to trigger doubling when the table gets 60-70 percent full; at that point you're almost bound to have some collisions (so you have to decide which of the items attached to that hash value is the right one).
2023-12-27 08:49:01 <KipIngram   > Seems to me a name comparison is the simplest way to deal with that.
2023-12-27 09:08:25 <crc         > My dictionary stores the hash of the name, but it's in a linked list. Entries are link to previous, hash, and the xt
2023-12-27 09:10:45 <crc         > I've had only had one hash collision that required a name change so far (in ~13 years of doing tests on this), so I'm not worried about that
2023-12-27 10:04:52 <vms14       > crc: irccloud seems much better than the shit I had, ty
2023-12-27 10:07:05 <crc         > vms14: no problem
2023-12-27 10:45:18 <KipIngram   > how full do you typically fill your tables?
2023-12-27 10:50:27 <crc         > I don't have tables
2023-12-27 11:00:04 <crc         > my hash function & dictionary structure: http://forth.works/share/5kPZNA9CdY.txt
2023-12-27 11:44:25 <KipIngram   > Oh.  Well, if you've got a linked list, what is the hash for?  Just to allow faster comparison than string comparison?
2023-12-27 11:44:57 <KipIngram   > Ok, so how many words do you have and how many bits is your hash/
2023-12-27 11:44:59 <KipIngram   > ?
2023-12-27 12:11:32 <crc         > The hash is used in lieu of storing the names
2023-12-27 12:15:01 <crc         > the full system has 542 words; 257 in the minimal system
2023-12-27 12:18:33 <crc         > if I stored the full names for the minimal system, the headers would use 2434 cells. With the hashes only, they use 771 (about 68% smaller).
2023-12-27 12:19:44 <crc         > the space savings was my main purpose. Doing a hash & comparing hashes being faster is a nice additional benefit, but not crucial.
2023-12-27 13:43:42 <rendar      > if in my Forth i'd add async words, do you think they should have some particular sign? E.g. start with ! or something like that, to signal that they are async words?
2023-12-27 13:46:46 <kws         > ! is usually used for set, so id recommend something else
2023-12-27 13:47:39 <thrig       > is async special in some way that demands attention like that?
2023-12-27 13:47:46 <kws         > could do like ^. honestly up to you
2023-12-27 13:47:52 <kws         > yeah, thats a good point too, why
2023-12-27 13:56:58 <rendar      > well, because with async functions my interpreter should call an async executor
2023-12-27 13:57:04 <rendar      > not with normal words
2023-12-27 13:57:31 <rendar      > plus, if i define some my word, i want to understand if its async or not
2023-12-27 15:27:05 <vms14       > rendar: in my case I just have a word named async which expects some code and spawns a thread to execute it
2023-12-27 17:10:57 <rendar      > vms14, that's interesting, but how it can expect code? e.g. `async 2 2 +` and then starts a new threads whcih computes 2+2, then pushes the result into the current stack?
2023-12-27 17:26:21 <vms14       > I use lists as code or the name of a word to execute
2023-12-27 17:27:04 <vms14       > It's a bit terse, but an example
2023-12-27 17:27:22 <vms14       > https://www.irccloud.com/pastebin/8wtHOYxB
2023-12-27 17:28:13 <vms14       > Well it sucks as an example, cause 'infinite.loop' is also taking a list as code
2023-12-27 17:28:22 <vms14       > :D
2023-12-27 17:30:15 <vms14       > But most of my words expect code, and code can be the name of a word or a list
2023-12-27 17:30:50 <vms14       > : is.true 1 0 if.else ;
2023-12-27 17:31:32 <vms14       > ['Is true'] ['is false"] if.else
2023-12-27 17:32:22 <vms14       > In your case I'm sure you have some way to give an execution token or alike
2023-12-27 17:32:48 <vms14       > Or just the memory address of the word
2023-12-27 17:33:16 <vms14       > I abuse lists so much that the language resembles more to a reversed lisp