2021-12-02 01:22:16 joe9: I am being a bit sarcastic when I say that, but I think either way is legit, I just want the one with the least coding 2021-12-02 01:22:32 Sometimes you do actually need to work with data in a file, or in blocks 2021-12-02 01:22:52 But today is not that day 2021-12-02 01:29:25 crc: Very nice demonstration of reorder there, although I don't 100% follow at first glance 2021-12-02 01:29:32 Anyway got to get ready for work 2021-12-02 01:41:50 not Forth but I too am getting on the AOC train https://github.com/siraben/haoc-2021/blob/master/day2.hs 2021-12-02 04:03:02 heresy! 2021-12-02 04:04:53 crc's solution is better because it doesn't store the input in memory 2021-12-02 06:19:54 http://forth.works/share/53483323fdbc4d0d1d455a4a09224ef4 is my quick solution for day 2 2021-12-02 06:24:48 what does tokenise do? 2021-12-02 06:34:48 s:tokenize splits a string on each occurrence of a character (removing the character) and constructs an array from the pieces 2021-12-02 06:37:43 useful 2021-12-02 06:47:57 I was just saying in ##asm how day two seemed to lend itself to being solved with Forth quite nicely. 2021-12-02 06:48:16 yea 2021-12-02 06:50:06 if my forth had parsing words, I'd probably just define forward, up, and down as words and then just included the input file 2021-12-02 06:54:04 Yeah, that's what I was thinking. 2021-12-02 07:40:17 Haven't looked at it yet but looking forward to it based on what I'm hearing here 2021-12-02 07:40:32 Looks like the dumb 'paste the input in my source' approach is going to pay off 2021-12-02 08:33:25 Day 2 https://pastebin.com/raw/qQi9zyFt (done in lunch break) 2021-12-02 08:59:39 what is the correct word to use here instead of LIT ? (nop is the dummy word) : nop ; : IF LIT ?branch , here @ LIT nop , ; immediate 2021-12-02 09:00:26 LIT happens to work but it's only cos i know the internals 2021-12-02 09:52:05 here's an ans version of today's first half: http://forth.works/share/1e329b6655fab8ea2dd1aa484c314898 2021-12-02 10:00:58 Stop being so productive! 2021-12-02 10:03:29 no :) 2021-12-02 10:03:41 Pft! 2021-12-02 10:47:16 crc: Very nice (Patrick Bateman face) 2021-12-02 10:47:41 Much better than mine, in my opinion 2021-12-02 10:55:39 Elizabeth Rather would approve 2021-12-02 12:05:14 crc, good one. 2021-12-02 14:24:41 Has anyone ever thought about using HAMT for a Forth dictionary? 2021-12-02 14:56:54 hodbogi: fancy seein' you here. 2021-12-02 14:59:13 I don't think the HAMT would apply because a forth dictionary isn't just a lookup table, it's also what you'd call the heap, where you can allocate spans of memory. 2021-12-02 16:51:02 "Are you okay, veltas? You're sweating." 2021-12-02 17:47:03 I'm using a linked list for my dictionaries ;) 2021-12-02 17:50:49 seems sensible 2021-12-02 17:50:56 are there other ways to implement forth dicts? 2021-12-02 17:57:47 imode, get out 2021-12-02 17:57:48 :P 2021-12-02 17:57:55 never. 2021-12-02 17:58:01 heh 2021-12-02 17:58:57 I thought maybe a HAMT would be kinda nice if you have a lot of them. there's been a couple different dictionary layouts I've thought of in the past 2021-12-02 17:59:45 imode, Wanna help me finish my operating system? 2021-12-02 18:02:00 only if you help me finish mine. 2021-12-02 18:05:30 Linked lists were fast enough in the 70s, they're fast enough now 2021-12-02 18:06:13 f-a: Lots of forths use hash tables for faster compiling, like gforth and mark4's x4 2021-12-02 18:07:39 I don't know about HAMT specifically 2021-12-02 18:11:40 i thought about it and a stack for dictionary would work too 2021-12-02 18:12:41 when you create a new word, push it onto the stack.. when you want to look up a word, search from most-recently-pushed to least-recently-pushed 2021-12-02 18:13:42 then everything is a stack! data stack! return stack! dictionary stack! 2021-12-02 18:34:55 thanks 2021-12-02 18:39:52 but how do you allocate..? 2021-12-02 18:40:08 the dict is already a stack allocator 2021-12-02 18:40:20 word defs r just a linked list inside of that 2021-12-02 21:13:33 I use a simple linked list because hash tables are hard to work with when compiling incrementally to flash 2021-12-02 21:19:55 tabemann: my msdos forth is coming along... it has 15 linked lists, one for each word length 2021-12-02 21:20:13 but i made it an array, so it only costs 15 cells 2021-12-02 21:21:13 I have two linked lists, one in flash and one in RAM 2021-12-02 21:21:26 ah 2021-12-02 21:22:33 however, on the RP2040 I on bootup compile an array of dictionary item hashes and pointers to dictionary items in RAM based on the flash dictionary 2021-12-02 21:22:46 if you put all the 1 char words on list1 and all the 2 char words on list2 and 3 char words on list3 etc... you don't have to separately store the length of each word 2021-12-02 21:22:46 because compiling gets very slow without it 2021-12-02 21:23:03 in a way i hashed by length 2021-12-02 21:23:32 to me the issue is that when I boot I need to discover the flash dictionary's end 2021-12-02 21:23:59 if I made separate linked lists for, say, every wordlist, I wouldn't know where to discover each of their ends 2021-12-02 21:24:12 ah 2021-12-02 21:24:52 yeah with 1 list you only need to follow the links to the last one 2021-12-02 21:26:51 I go the opposite direction 2021-12-02 21:27:26 I scan from high in flash down to where the $FFFFFFFF ends and where the value $DEADBEEF can be found 2021-12-02 21:28:30 oh is that where you will create the next word? 2021-12-02 21:29:40 words in each dictionary are in a linked list from the last word to the first word