2022-02-24 04:21:27 <veltas      > Just seems really pointless, probably 100 easier things before you need GC most times
2022-02-24 04:24:44 <veltas      > i.e. some kind of graph that will repeatedly lose nodes, then when the pool is too large just copy the graph to another pool and group-free the other pool
2022-02-24 04:25:00 <veltas      > And you could do that with ALLOT half the time
2022-02-24 07:10:18 <Zarutian_HTC2> KipIngram, remexre: Garbage Collection, hard? depends on the object system really
2022-02-24 07:12:00 <Zarutian_HTC2> the one I have written uses an copying collector and a circular memory for the objects
2022-02-24 07:13:40 <Zarutian_HTC2> plus the objects are each made up of header cell, xt to method handler, refs part, and data part.
2022-02-24 07:16:27 <Zarutian_HTC2> what will it be used for? compositional graphics, gui Toolkit, and maybe more
2022-02-24 18:20:10 <Zarutian_HTC> who was it here that was looking into doing SmartMessages with Forth?
2022-02-24 18:28:27 <KipIngram   > Zarutian_HTC: I was actually taking the position that for a system with fixed uniform page size it's actually quite easy.  It's just labor intensive by Forth standards.
2022-02-24 18:29:43 <KipIngram   > It's more involved with variable allocation sizes, but it's been so long since I studied the common algorithms I can't really remember exactly how hard it is in any quantitative way.
2022-02-24 18:30:23 <Zarutian_HTC> KipIngram: I went the easier HERE esque route of just having an allacation pointer and did not bother with pages or slabs of them
2022-02-24 18:30:41 <KipIngram   > Anyway, when we had that Lisp discussion a year or two ago for a few days, I went and did some reading, and it seemed that the simplest Lisp implementations just have "cells" and everything else is structure built on those.  So a memory manager that just manages those cells is enough.
2022-02-24 18:30:46 <Zarutian_HTC> allocation*
2022-02-24 18:31:03 <KipIngram   > Someone mentioned more complex objects, like arrays and so forth - that wouldn't fit into that 'simplest' paradigm.
2022-02-24 18:31:12 <Zarutian_HTC> right, cons cells with car and cdr
2022-02-24 18:31:42 <KipIngram   > I was pretty impressed with how simple such a very basic Lisp looked like it could be.
2022-02-24 18:32:03 <KipIngram   > I'd heard about Lisp my whole life, of course, but until that period I'd never really "looked into it."
2022-02-24 18:32:35 <Zarutian_HTC> and part of the header in my description earlier are the sizes of the two parts of the object, (the refs part and the data part)
2022-02-24 18:32:38 <KipIngram   > I'd just been "put off" by all the parentheses, so I kind of shunned it.  :-)
2022-02-24 18:34:18 <Zarutian_HTC> so variable size objects arent an issue, though resizable arrays will be either composed of chunks or get resized and moved at certain points
2022-02-24 18:35:25 <Zarutian_HTC> KipIngran: google fructure and you see that those parens are just to describe structure
2022-02-24 18:35:37 <Zarutian_HTC> KipIngram: ^
2022-02-24 18:35:41 <KipIngram   > Right.  In the Forth I wrote just before this one, I had a simple memory manager at the foundation layer - fixed block size.  Headers had to be in one block, but word bodies could reside across block boundaries - I just detected that and put a jump to the new block in.
2022-02-24 18:36:28 <KipIngram   > What I had on my mind at the time was a Forth for a rather small Cortex M4 environment with limited RAM, but I still wanted to be able to have multiple sessions (think about running Forth in a bunch of Gnu Screen windows, each independent of the others).
2022-02-24 18:36:36 <KipIngram   > So the basic page size had to be fairly small.
2022-02-24 18:37:13 <KipIngram   > After a while I decided that feature creep was setting in and I kind of abandoned it and started over.  This time I passed on the bottom layer memory manager.
2022-02-24 18:38:13 <KipIngram   > One nice thing it let me do, though, was keep "temporary word" headers (words needed by a later word but then not needed anymore) in a dynamically allocated block, and then when I got the final word built I just unlinked those guys from the search order and freed the RAM.
2022-02-24 18:38:20 <KipIngram   > That worked quite well.
2022-02-24 18:38:39 <KipIngram   > I introduced a word .: which worked just like : but put the word in the temporary space.
2022-02-24 18:39:05 <KipIngram   > And had a word .wipe that would do the unlink / free step.
2022-02-24 18:39:21 <KipIngram   > If .: found a page already in use, it used it - if it didn't, it got one for the purpose.
2022-02-24 18:40:08 <KipIngram   > I have .: and .wipe in the new system too, because I really liked the usability of that.  But it has no way to actually free up the RAM the headers occupy.  It just removes the names from the search order.
2022-02-24 18:40:29 <KipIngram   > And .: just sets a flag in the header, so .wipe will know which ones to remove.
2022-02-24 18:41:34 <KipIngram   > I guess I actually still could get the same result by just "counting on" some memory space way up above the dictionary being available for that purpose.
2022-02-24 18:42:13 <dave0       > maw KipIngram
2022-02-24 18:42:38 <KipIngram   > Feels a little fraudulent - using unallocated RAM.  But it would work.  :-)
2022-02-24 18:42:43 <KipIngram   > maw, dave0