2024-01-05 03:14:47 <zelgomer    > do you guys have a preferred set of words or strategy for defining structures and member accessors
2024-01-05 03:15:28 <zelgomer    > what is the forth way to do this? just define a bunxh of words by hand to read or write members?
2024-01-05 04:09:08 <crc         > zelgomer: I tend to just write them out manually. I've dabbled a little with automated generation. See http://retroforth.org/examples/defstruct.retro.html for a little example of this.
2024-01-05 04:10:11 <crc         > I've done a larger thing for generating accessors for larger structures, but it's not one I can share the source of. currently
2024-01-05 14:38:04 <zelgomer    > crc: thanks. i guess this is somwthing i just have to get used to. after more than 15 years in c, i just naturally think in c structs
2024-01-05 15:35:28 <KipIngram   > Yeah; Forth can "do anything" but it generally doesn't take care of details of that sort for you.
2024-01-05 16:02:34 <zelgomer    > crc: i guess your (defstruct is useful for homogenous tuples. yesterday i wrote something where you give it sizes with the fields, like    struct #foo  #cell bar  #cell baz  128 quux  end-struct  ( now #foo is the total size )
2024-01-05 16:03:15 <zelgomer    > but that still requires you to know the size of a field to fetch or store it, so it doesn't seem like it helps much
2024-01-05 16:04:23 <zelgomer    > you still end writing accessors to encapsulate fetching and storing
2024-01-05 16:04:28 <zelgomer    > end up
2024-01-05 16:06:30 <zelgomer    > probably don't want to find myself trying to implement a type system :)  probably going to throw this away and force myself to do it hand, at least for now
2024-01-05 16:07:17 <Zarutian_iPad> zelgomer: ya implementing a selectrix knock off or?
2024-01-05 16:07:29 <crc         > zelgomer: the application at work has a more flexible struct system, but it's not used much (just in one of the parts).
2024-01-05 16:07:55 <zelgomer    > Zarutian_iPad: selectrix?
2024-01-05 16:07:56 <crc         > I tend to just have my structs contain pointers for anything that's not a memory cell in length
2024-01-05 16:08:29 <Zarutian_iPad> TYPE as in TYPEWRITER
2024-01-05 16:09:18 <zelgomer    > crc: i see. interesting, thanks
2024-01-05 16:09:47 <Zarutian_iPad> but I do get what you meant
2024-01-05 16:10:33 <Zarutian_iPad> I just prefer to use an object system than structs
2024-01-05 16:10:46 <zelgomer    > Zarutian_iPad: oh, i only just now got it. lol, sorry. no, i'm happy with the type system already provided by my terminal emulator
2024-01-05 16:12:01 <Zarutian_iPad> (not oop but object system that builds on the idea of <BUILDS DOES> but has gc and seperate space from the forth dictionary)
2024-01-05 16:12:02 <zelgomer    > data structures has always been a hurdle for me in functional languages, too
2024-01-05 16:17:18 <Zarutian_iPad> it isnt much of a hurdle, it is just that I somestimes want dynamicly calculated value on field/property access
2024-01-05 16:19:35 <zelgomer    > Zarutian_iPad: how do you know when something is collectable? do you keep track of its lifespan on the stack?
2024-01-05 16:20:23 <thrig       > : first-edition-superman ... ; \ collectable
2024-01-05 16:21:41 <zelgomer    > yeah, barring the comment, how would you know?? superman sucks
2024-01-05 16:21:48 <Zarutian_iPad> zelgomer: nope, I use an event loop and at each end of turn of it the datastack is empty of references and gc is performed
2024-01-05 16:23:07 <Zarutian_iPad> and each object is made of four parts, header, xt, refs part, and data part
2024-01-05 16:23:56 <zelgomer    > okay,
2024-01-05 16:24:01 <Zarutian_iPad> xt points to the 'script' of the object, which handles invocations to the object (objects can share xt)
2024-01-05 16:24:36 <Zarutian_iPad> refs part contains references to other objects, and data contains everything else
2024-01-05 16:25:54 <zelgomer    > are they named?
2024-01-05 16:26:19 <Zarutian_iPad> the parts? or the objects?
2024-01-05 16:27:13 <zelgomer    > hold on let me move to a real keyboard, this damn touchscreen is tedious
2024-01-05 16:30:17 <zelgomer    > i'm trying to imagine what else would be in that header. see, i think you're hitting on something that i've struggled with: i've always thought of create does> as a template engine or a macro. when you use a macro to declare a function in c, there's only one instance of that function. it becomes a static object. and that's how i've seen create does>...  : myconst create , does> @ ;  42 myconst hello  (
2024-01-05 16:30:24 <zelgomer    > hello is now a word in the dictionary and there's only one of it, it's not something that can be instantiated later by another word )
2024-01-05 16:30:38 <zelgomer    > but now you're describing garbage collecting objects that were built with create does>
2024-01-05 16:31:52 <Zarutian_iPad> oh, the header is one cell and contains three pieces of information,  is it a normal object or a broken heart, how big is the refs part in nr of references and how big the data part
2024-01-05 16:32:03 <Zarutian_iPad> nothing else
2024-01-05 16:32:29 <zelgomer    > so your create actually instantiates anonymous objects, it doesn't create new dictionary entries
2024-01-05 16:33:15 <Zarutian_iPad> a broken heart is basically an object that has been moved and the next cell isnt an xt but a pointer to where it had moved
2024-01-05 16:33:22 <Zarutian_iPad> yebb
2024-01-05 16:33:50 <zelgomer    > very interesting. thanks!
2024-01-05 16:34:00 <Zarutian_iPad> I do not know how many objects there will be or when they should be deleted
2024-01-05 16:35:23 <Zarutian_iPad> the object space is a circular buffer to, and all the accesses to it go through two words objs_@ and objs_!
2024-01-05 16:35:34 <Zarutian_iPad> not very imaginative I know
2024-01-05 16:36:35 <Zarutian_iPad> but it means that I could have the objects in a different memory device or in virtualized memory from blocks or files
2024-01-05 16:37:45 <zelgomer    > ah yes, and now we're back to the circular buffer discussion that was happening when i first joined this channel weeks or months ago :)
2024-01-05 16:38:07 <zelgomer    > i also have a circular buffer, but i only use it as a scratch pad area
2024-01-05 16:38:24 <zelgomer    > temporary string buffers, mostly
2024-01-05 16:38:59 <Zarutian_iPad> oh and I also use objs_cells+ for offset calculations so if an object stradels the end and begining the rest of the system is none the wiser
2024-01-05 16:39:40 <Zarutian_iPad> and gc causes objects to move through the buffer in one direction
2024-01-05 16:41:44 <zelgomer    > fancy stuff. i'm still trying to make fire by rubbing two sticks together
2024-01-05 16:42:39 <Zarutian_iPad> why this system? I want to do gfx via composition without taking up too much memory
2024-01-05 16:44:54 <Zarutian_iPad> basically I have two 'interfaces' for it: pixmap/bitmap/tilemap, and palette/tileset
2024-01-05 16:47:48 <Zarutian_iPad> and composition objects like translate, flip, 90˚ rotate, shear, 1-89˚ rotate through use of three shears, hsv2rgb, rgb2hsv, indexed2rgb, scale by integer, image kernel applier, ans so on
2024-01-05 16:47:59 <Zarutian_iPad> s/ans/and/
2024-01-05 16:49:31 <Zarutian_iPad> the first 'interface' has four accessor methods/selectors: getWidth, getHeight, getPoint, putPoint
2024-01-05 16:51:41 <Zarutian_iPad> a translate composition object has a reference to its underlying pixmap, another object, and delegates getWidth and getHeight to that
2024-01-05 16:52:19 <Zarutian_iPad> it also has, in its data part, the x offset and y offset
2024-01-05 16:53:16 <Zarutian_iPad> for the getPoint and putPoint it just adds those offsets to the requested x and y modulo width and height respectively
2024-01-05 16:53:39 <Zarutian_iPad> so, you get the idea for the rest
2024-01-05 17:16:04 <zelgomer    > Zarutian_iPad: i had to step away and think about it for a bit. i think you have implemented the closure system i was wishing for here a few days
2024-01-05 17:17:00 <Zarutian_iPad> closures are poormans objects, and objects are poormans closures
2024-01-05 17:17:07 <Zarutian_iPad> as the saying goes
2024-01-05 17:17:11 <zelgomer    > true
2024-01-05 17:18:02 <zelgomer    > Zarutian_iPad: if you allocate objects A, then B, then C and D, and when you do gc you find that A and C are collectable, you can only advance your circular pointer to B and C remains uncollected, right?
2024-01-05 17:21:01 <zelgomer    > Zarutian_iPad: now the thoughts are coming... is your does> for these objects a method dispatcher?
2024-01-05 17:27:40 <Zarutian_iPad> B and D get moved in the gc and A and C just becomes stale data in the buffer nothing points or references to
2024-01-05 17:28:11 <zelgomer    > ah so they are relocatable
2024-01-05 17:28:47 <Zarutian_iPad> zelgomer: pretty much the does> (which the xt points to) dispatches on the method selector
2024-01-05 17:29:41 <Zarutian_iPad> yebb they are relocateable which os the main reason why the refs part is seperate from the rest of the data of the object
2024-01-05 17:31:01 <Zarutian_iPad> I can put in an transparent forwarder that just ticks a counter upwards without bothering about a class or interface type
2024-01-05 17:32:11 <Zarutian_iPad> basically supports object composition and delegation without much hassle or crappy v-table use
2024-01-05 17:32:35 <zelgomer    > exactly. i'm very impressed :)
2024-01-05 17:33:01 <zelgomer    > you've my gears turning now
2024-01-05 17:33:16 <zelgomer    > on things i'm still probably a far cry from, but still
2024-01-05 17:33:56 <zelgomer    > add it to the pile of neat high level ideas i hope to play with one day if i can just ever get past the compiler phase
2024-01-05 17:34:01 <Zarutian_iPad> mostly I just use small constants for the method selectors and a jump table in each dispatcher
2024-01-05 17:34:29 <Zarutian_iPad> compiler phase?
2024-01-05 17:35:13 <zelgomer    > yeah, DIYing my own metacompiler
2024-01-05 17:35:44 <Zarutian_iPad> trying to squeeze as much speed out of it or?
2024-01-05 17:36:46 <zelgomer    > i think it's mostly about workflow and ecosystem. i want to be able to produce executable binaries that don't parse anything at startup
2024-01-05 17:36:54 <Zarutian_iPad> zelgomer: then this http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html is something for you
2024-01-05 17:37:09 <zelgomer    > and then i want to be able to target platforms other than my pc
2024-01-05 17:40:06 <zelgomer    > i don't actually have any end goal with forth. there's no program or product in particular that i want to develop with it. i guess for now i'm just here for the journey :)
2024-01-05 17:46:23 <zelgomer    > Zarutian_iPad: i'm about halfway through and i can tell you this is going to take several reads
2024-01-05 17:52:16 <GeDaMo      > Futamura projections are a bit mind bendy :P
2024-01-05 18:00:55 <zelgomer    > and not a single reference to professor farnesworth. disappointing
2024-01-05 19:55:44 <zelgomer    > Zarutian_iPad: was about to ask why a circular buffer and not just an linked list object cache, but i think the answer is because you get to have objects of varying sizes
2024-01-05 20:08:23 <Zarutian_iPad> zelgomer: it makes the objs_cells+ word much simpler
2024-01-05 20:10:51 <zelgomer    > yeah
2024-01-05 20:13:09 <Zarutian_iPad> : objs_cells+ ( optr u -- optr ) SWAP objs_start @ - + objs_size % objs_start + ; iirc