00:00:00 --- log: started forth/19.05.23 00:28:23 --- quit: nighty- (Ping timeout: 248 seconds) 00:29:11 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 00:43:04 --- quit: dave9 (Ping timeout: 252 seconds) 00:48:23 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 01:38:11 My preference is horizontal in most languages, with the exception of assembly languages. 01:43:31 --- join: pierpal (~pierpal@host201-184-dynamic.11-87-r.retail.telecomitalia.it) joined #forth 02:04:22 --- quit: ashirase (Ping timeout: 272 seconds) 02:08:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:31:15 rdrop-exit: vertical forth kinda looks like assembly to me 04:49:03 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 07:36:40 --- quit: tabemann (Ping timeout: 252 seconds) 08:32:42 --- quit: pierpal (Ping timeout: 258 seconds) 08:40:40 --- quit: rdrop-exit (Quit: Lost terminal) 08:56:27 --- quit: Zarutian (Read error: Connection reset by peer) 08:56:40 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 09:19:59 --- quit: john_metcalf (Ping timeout: 246 seconds) 09:52:53 vertical makes it - as noted - easy to track stack-pics. Horiz should be limited to "'spot see run" - so dead simple you don't need a sliderule or pic 09:59:02 --- join: dys (~dys@tmo-121-73.customers.d1-online.com) joined #forth 11:57:25 --- quit: gravicappa (Ping timeout: 248 seconds) 12:35:27 writing a Forth-like with a FIFO instead of a stack is weird 12:35:39 I have some kind of stack-fifo abomination 12:36:20 maybe I just want a stack with a word that sticks the current item to the bottom 12:36:35 but that's ROLLing I guess 13:00:08 just flip the stack, use it, and flip back again if/when needed... 13:01:59 right now I have the two front-of-queue items in registers and a word that moves the TOS to the bottom... 13:02:30 I want something relatively easy to implement in hardware 13:02:56 l 13:02:57 WilhelmVonWeiner: I just skip over items I don't need in a particular pass with `d>` ...that keeps them for the next pass and gets them out of the way. 13:03:26 it's a solution, but quite a... wasteful(?) solution 13:40:52 how do you deal with the parser/interpreter clobbering your fifo 13:40:58 WilhelmVonWeiner: It could serve as the execution history, ...or the definition of a fifo-style word. Compile/swallow-up a definition to the dictionary by moving the pointer to the bottom over to the right. That would persist a definition. 13:40:59 Keep the active part of the fifo such that it wraps around. Keep the fifo length to the number of elements in the fifo. 13:40:59 Compile to the dictionary side of the fifo when you want to keep something. Dropping from the fifo can be anonymous or you can name what you drop to get a dictionary header for future referencing. 13:46:12 zy]x[yz: Currently I just start at the lowest ram address 0x20000000 and move upwards. 13:48:39 yeah but everything the parser parses goes onto the fifo, and then as the parser does its thing it also uses the fifo 13:49:18 with the stack there's no inteference because when it returns to the user input, the interpreter's use of the stack has been unwound. with a fifo, it doesn't get unwound, instead it clobbers whatever the user had previous put on the fifo 13:50:30 or am i missing something? 13:53:30 zy]x[yz: You're right the parser has been tricky with fifos. 13:53:31 I feel like the whole execution wants to be breadth-first/lazy-evaled to behave the way I want. 13:57:15 Trying to go halfway and mix eager with lazy has been problematic. 14:19:32 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 14:19:45 hi 15:03:30 h'lo 15:32:48 --- quit: lonjil (Remote host closed the connection) 16:41:27 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 16:52:46 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 16:53:47 c[_] Good morning 16:56:51 WilhelmVonWeiner, pointfree if you guys can figure out how to make that work, I've been really interested in seeing what a fifoforth would look like. i just gave up because it seemed like there was no good way to do it without overcomplicating everything 16:58:34 (how) do people usually write allocators for bare-metal forths? 17:02:20 Memory allocators? 17:03:10 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 17:03:32 hey guys 17:03:39 Hi tabemann 17:04:14 in Forth traditionally the dictionary or user space is used for allocation, and is basically a block of memory with a pointer into it 17:04:38 HERE is the pointer's current state and ALLOT adds to (or subtracts from) that pointer 17:05:14 there is ALLOCATE/FREE, akin to malloc()/free(), in ANS Forth, but it traditionally does not get much use/is not available 17:05:48 I don't think "user space" is a Forth concept, there are user variables though 17:07:37 you call it the dictionary; I just say "user space" because it seems to be the best description, since it can contain more than just words 17:07:54 since user variables exist in this space 17:10:01 is remexre even awake? 17:10:15 Oh sorry was on a different window 17:10:21 okay 17:10:22 Usually get mentioned :p 17:10:28 I just find the term "user space" confusing, since in Forth we already have a term for it, "dictionary" 17:11:06 I'm familiar with HERE/ALLOT/, but I think I need malloc/free or some other facility 17:11:20 I've got (a few) dynamic vectors 17:12:31 is the dictionary typically ALLOCATEd space, or is the heap ALLOCATE draws from ALLOTted, or neither? 17:12:49 on bare metal forths there is typically no heap 17:13:48 the dictionary exists as a linearly upwardly expanding space of memory, while the data stack exists as a linearly downwardly expanding space of memory 17:14:10 The dictionary is a big chunk of RAM 17:15:20 sure, I know; I mean, how does ALLOCATE's heap interact with this big chunk? is the dictionary capped at some amount, and after that, you're overriding the heap? 17:15:25 or hitting a guard page or something 17:15:50 usually the dictionary and the data stack exist in the same block of memory 17:15:51 What heap? You said a bare meta Forth 17:16:01 * metal Forth 17:16:08 By heap, I mean the memory ALLOCATE draws from 17:16:27 since when do bare metal forths typically have ALLOCATE? 17:16:38 exactly 17:16:50 Since I have two different tables I want to be able to grow at any time 17:16:52 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:17:01 :P 17:17:07 ALLOT the maximum amount of space you will need 17:17:11 A bare metal Forth has hardware underneath 17:17:42 tabemann: that's like 128M though 17:17:58 rdrop-exit: sure? so does one running as a Linux process? what do you mean? 17:18:15 or if the tables are only expanding, never shrinking, you could ALLOT individual blocks of data and put them in a linked list, or another array pointing to them 17:18:18 Hardware doesn't provide you with ALLOCATE 17:18:40 rdrop-exit: sure, that's why I want to know how it's typically implemented, so I can implement it 17:18:51 You would implement any type of ALLOCATE on top of your Forth, not the other way around 17:18:58 yes 17:18:59 you 17:19:01 whoops 17:19:21 you'd ALLOT the maximum heap size, and write ALLOCATE to portion out memory in this block of memory 17:20:01 okay 17:20:05 I'll probably go with that 17:20:07 remember - there is no allocator available - if you need one you must write it yourself 17:20:20 You don't need a ALLOC functionality to bring up your Forth 17:20:24 yeah, I just wanted to know how people normally fit theirs into the design 17:20:38 They usually avoid ALLOC 17:20:52 at least at lower levels 17:21:32 I'm doing a multitasking forth, so I want to be allocate process tables 17:21:36 in the forth I've been working on lately the only place where I use ALLOCATE is for loading code from files, to be able to support arbitrary sized files without executing one line at a time, but this is currently hosted on Linux, and I might take out this functionality to support porting to other platforms 17:21:38 Forth doesn't require ALLOC, but if your application does, then you add ALLOC to your Forth 17:22:56 remexre: ALLOCATE is a high level functionality, it should not be required in implementing a bare metal Forth 17:22:57 remexre: my current Forth is multitasking, and makes no use of ALLOCATE to support it 17:23:36 how do you allocate the tables with process-specific information? 17:23:38 ALLOCATE is an OS-level Concept 17:23:43 it just ALLOTs task control blocks for each task, and puts them in a doubly-linked ring 17:24:00 tabemann: Don't you need random access? 17:24:40 remexre: I allot out dictionaries and stacks for each individual task, and put user variables at the bottom of the dictionaries for each task 17:24:46 remexre: what do you mean? 17:25:16 to delete a process I just remove it from the doubly-linked ring, and to permanently delete it I execute a word created with MARKER in the main task 17:25:26 s 17:25:31 s/process/task 17:26:07 I've got message passing between tasks, and the (head and tail of the) mailboxes are in the process records 17:26:30 so when I send a message to process #346, I need to get to link #346, no? 17:26:56 I implemented message passing too, through implementing channels via ring buffers 17:27:12 why put mailboxes in the process records? 17:27:30 just implementing ring buffers ALLOTED in the dictionary is more general 17:27:49 remexre: That doesn't sound like a bare-metal Forth 17:28:07 tabemann: Those have fixed capacity though, no? 17:28:11 rdrop-exit: okay, confession time 17:28:22 (note that these ring buffers I implemented block when a task tried to write to an already filled buffer or when a task tries to read from an empty buffer) 17:28:23 I'm compiling a functional language to Forth 17:28:46 tabemann: Oh, okay; I wanted non-blocking sends 17:28:48 The horror!!! 17:29:29 so I want sufficiently high-level primitives implemented in Forth 17:29:44 remexre: so implement ALLOCATE using ALLOT, and put messages as blocks in your heap that are in doubly linked lists 17:29:46 I probably won't be actually using ALLOCATE/FREE'd memory much either, since I'll be allocating a GC heap within that 17:30:39 tabemann: Yeah, that works for messages, but to find the process, I still would want to be able to just look up the process's mailbox list without traversing through all the processes 17:30:55 You're mixing up levels, the Forth is bare-metal, then you implement your functional bloat on top of it 17:31:17 The underlying Forth has no need for it 17:32:48 I'm not sure if I'd call GC bloat per se 17:32:51 From a Forth perspective ALLOCATE is high-level optional functionality 17:33:23 but yeah 17:33:32 all this is stuff you're implementing on top of Forth 17:33:35 not part of Forth itself 17:34:16 sure, I just wanted to make sure that there wasn't a massive foot-shooting going on in my approach 17:34:45 GC is bloat 17:35:51 --- join: Mecrisp (~matthias@2a02:560:426d:f200:a15:28bc:760f:3a47) joined #forth 17:36:12 GC is what allows the average person to write code that doesn't crash all the time, on one hand, and is essential to functional programming, on the other hand; note that GCs can be implemented that are quite fast, actually 17:38:49 * tabemann should note that he is a Haskeller in addition to a Forther 17:39:56 Collecting garbage is only necessary if you're generating garbage, low level and control applications don't generate garbage 17:40:23 * crc finds gcs to be annoying to write and notes that a buggy gc can cause a lot of headaches 17:40:45 GC is not appropriate for realtime applications, for obvious reasons 17:42:40 By definition if you *need* GC, you're working at a high level and expecting the system to clean up after you 17:43:40 either you are a poor programmer who can't manage their own memory or you're programming in a language where every operation creates garbage by its very nature (e.g. Haskell) 17:44:48 Any language that creates garbage by its very nature is very high level indeed 17:45:05 but at the same time, if you need safety and you don't need realtime performance, GC is oftentimes what one needs 17:45:57 What are you calling safety? I wouldn't use a GC in any safety critical application 17:47:09 safety in the sense that your code will fail cleanly by raising an exception when something goes wrong 17:47:18 If you're calling safety protecting idiots from themselves, well that's definitely not the Forth way 17:49:18 code will always have bugs 17:49:39 especially garbage collectors 17:50:18 in environments like Erlang they have specifically designed it so that failure can be handled cleanly, and obviously if something could segfault and bring down the whole environment it is not safe 17:50:53 in Erlang individual processes can die, but the whole environments survives in spite of that 17:50:56 Yeah, Erlang is an inspiration for the functional language 17:51:07 but with a static type system 17:51:32 have you looked at Haskell? 17:51:36 Sure Erlang sandboxes everything, you can do that in Forth too 17:52:22 tabemann: Yeah, my issue is that Haskell still lets you have undeclared exceptions 17:52:29 and I'm not a fan of laziness 17:52:42 yes, laziness does have its disadvantages 17:52:43 rather, laziness-by-default 17:52:55 I'm taking more inspiration from Idris 17:53:23 You can write a sandboxed environment on top of Forth, or write a Forth on top of a sandboxed VM 17:53:33 totality checking, strictness by default 17:53:56 but undeclared exceptions are a plus, not a minus - look at what they did in Java with declared exceptions, which makes it hard to do functional programming and basically forces programmers to use RuntimeException for everything 17:54:03 But you write a bare-metal Forth on bare-metal 17:54:25 I like the idea of Idris, but I'm not sure if I can wrap my brain around dependent typing 17:55:01 okay, I've gotta go 17:55:02 bbl 17:55:43 tabemann: cya! 17:55:51 ciao 17:57:56 --- part: Mecrisp left #forth 17:59:10 --- quit: tabemann (Ping timeout: 245 seconds) 18:48:04 --- quit: dddddd (Remote host closed the connection) 19:19:25 --- join: tabemann (~tabemann@2600:1700:7990:24e0:b944:a349:56b9:12fb) joined #forth 20:08:33 --- quit: rdrop-exit (Quit: Lost terminal) 20:31:22 https://t1lang.github.io/ what do you think of this forth like lang? 21:04:11 yunfan: I think it's a good idea. 21:04:37 Having a memory safe low-level language is a good idea, especially if it has compile-time analysis. 21:10:33 I'll bookmark it to review later. Will be interested if the developer gets it to a point where the compiler is in t1 instead of c#. 21:17:29 --- join: gravicappa (~gravicapp@h109-187-203-93.dyn.bashtel.ru) joined #forth 21:53:28 --- quit: dave0 (Quit: dave's not here) 22:27:40 --- join: john_metcalf (~digital_w@host109-152-144-112.range109-152.btcentralplus.com) joined #forth 22:56:45 siraben: the link had mentioned t0, the previous in its series 22:57:02 siraben: and that's a ssl implmentation, which i think is interesting 23:17:31 --- quit: gravicappa (Ping timeout: 244 seconds) 23:29:25 --- quit: dave9 (Ping timeout: 250 seconds) 23:30:27 --- join: dave9 (~dave@069.d.003.ncl.iprimus.net.au) joined #forth 23:50:25 --- quit: dys (Ping timeout: 245 seconds) 23:59:59 --- log: ended forth/19.05.23