2023-05-08 08:26:27 <vms14       > I'm on netbsd again xD
2023-05-08 08:26:44 <vms14       > and I'm wondering about making the abomination in C
2023-05-08 08:27:04 <vms14       > also I realized I don't really want forth, but my abomination
2023-05-08 08:27:23 <vms14       > althought I'd like to dig more with forth in order to steal more concepts
2023-05-08 08:30:17 <vms14       > but I'll need some kind of gc :/
2023-05-08 08:31:05 <KipIngram   > Your goals seem a little contrary to actually building a Forth.  You seem to have an immediate interest in stuff at the other end of the game - up around sockets and web behaviors and so on.
2023-05-08 08:31:24 <KipIngram   > It would be a while before you could get a Forth ready to tackle those things.
2023-05-08 08:32:27 <vms14       > yeah, also I want lists and the stack being able to get any kind of type
2023-05-08 08:32:50 <vms14       > I guess lists would be a void pointer list
2023-05-08 08:32:54 <KipIngram   > I think the easiest way to do that last is to just let the stack contain object pointers.
2023-05-08 08:33:18 <vms14       > but this means I'll have to use malloc to allocate integers, which makes me kind of sad
2023-05-08 08:33:28 <vms14       > and it's the whole reason I ended having different stacks
2023-05-08 08:33:29 <KipIngram   > And yeah, a list would just be an array of object pointers.
2023-05-08 08:33:47 <vms14       > still I need some sort of types and the gc
2023-05-08 08:33:56 <vms14       > I have no idea how to make a gc
2023-05-08 08:34:08 <KipIngram   > You could use malloc to allocate a big zone for integers and then allocate out of that zone yourself.
2023-05-08 08:34:10 <vms14       > I can only think on making a struct with the value and a reference counter
2023-05-08 08:34:12 <KipIngram   > It would be a lot faster.
2023-05-08 08:34:56 <KipIngram   > If you have an object on the stack and you say DUP, would you then go increment the reference counter?
2023-05-08 08:35:05 <vms14       > shouldn't?
2023-05-08 08:35:16 <vms14       > but also on the dictionary
2023-05-08 08:35:22 <KipIngram   > If you drop, you'd decrement the thing's reference counter?
2023-05-08 08:35:25 <vms14       > if you embed a value there
2023-05-08 08:35:28 <vms14       > yeah
2023-05-08 08:35:29 <KipIngram   > Yeah, I think you would.
2023-05-08 08:35:51 <vms14       > and the decrement process is what it checks if it's 0 and frees it
2023-05-08 08:36:01 <vms14       > also types should have a free function
2023-05-08 08:36:04 <KipIngram   > I've thought a little in the context of string handling how to have transient strings without having to do full reference counting, deallocation, and so on.
2023-05-08 08:36:20 <vms14       > and how it went?
2023-05-08 08:36:37 <KipIngram   > I generally figure I'd just have a ring buffer that I put the results of string operations in, and I'd just make it big enough that by the time I wrapped around I no longer needed the oldest stuff.
2023-05-08 08:36:52 <vms14       > hmm
2023-05-08 08:36:54 <KipIngram   > That's imperfect and is a risk, but could probably be made to work fine.
2023-05-08 08:37:04 <crc         > KipIngram: that's what I do; a ring buffer for temporary strings & (arrays(
2023-05-08 08:37:31 <crc         > it has worked well for me over the last decade or so
2023-05-08 08:37:48 <KipIngram   > :-)  That's a good point of support in my eyes.
2023-05-08 08:38:52 <vms14       > if it's big enough you could live without reaching the limit
2023-05-08 08:39:09 <vms14       > but I won't escape the gc anyways
2023-05-08 08:39:11 <KipIngram   > Sure, or at least when you did you'd be long since done with the stuff you came to overwrite.
2023-05-08 08:39:28 <veltas      > Each problem has the simplest way to do it, including simplest allocation approach
2023-05-08 08:39:37 <KipIngram   > Yeah, my realization the last day or two is that I'm just going to have to tackle memory allocation properly to do all the things I want to do.
2023-05-08 08:39:39 <veltas      > My issue with GC is very few problems the simplest way is with GC
2023-05-08 08:40:07 <vms14       > I thought the simplest way was without gc
2023-05-08 08:40:17 <veltas      > Yeah that's what I'm saying
2023-05-08 08:40:20 <vms14       > ah xD
2023-05-08 08:40:24 <KipIngram   > This morning I'm contemplating EXPECT.  I've always had EXPECT null terminate its string, but I'm starting to think that maybe I want to newline terminate it.
2023-05-08 08:40:35 <veltas      > In very few problems the simplest way is with GC, in most problems it's simpler to not use it
2023-05-08 08:40:45 <KipIngram   > Well, that's not quite the right way to say it.
2023-05-08 08:41:08 <KipIngram   > veltas: That last was in reference to what I typed, not what you typed.
2023-05-08 08:41:16 <vms14       > KipIngram: I don't think it would make much difference using \0 or \n
2023-05-08 08:41:27 <vms14       > as long as this line will never contain another \n
2023-05-08 08:42:07 <vms14       > what's the reasoning behind that?
2023-05-08 08:42:31 <vms14       > why would you prefer a newline?
2023-05-08 08:42:34 <KipIngram   > It wouldn't.  What I'm going for, though, is to make editing easier.  I'm pretty sure that what I want to do when I edit a line of a block is have it carry the whole rest of the block along for the ride.
2023-05-08 08:42:47 <KipIngram   > If I insert a character in a line, I want to be inserting it in the block.
2023-05-08 08:43:14 <KipIngram   > I.e., it'll nudge the whole rest of the block contents forward a byte.
2023-05-08 08:43:35 <KipIngram   > Line editing "in situ."
2023-05-08 08:44:12 <KipIngram   > And I also think that if I'm loading code and I come to the end of a block without getting a null it should just carry on into the next block.
2023-05-08 08:44:19 <KipIngram   > Even if I'm in the middle of a word.
2023-05-08 08:44:39 <KipIngram   > Sort of a "preliminary file system" that treats contiguous blocks as files.
2023-05-08 08:44:50 <vms14       > a union seems a better option than a void pointer
2023-05-08 08:45:06 <vms14       > at least for the builtin types
2023-05-08 08:45:07 <KipIngram   > But those two ideas don't really go together - the machine is fast enough that I can edit all of a block without it being sluggish.
2023-05-08 08:45:20 <KipIngram   > But if I had several continguous blocks of text that would break down.
2023-05-08 08:45:29 <KipIngram   > So I don't know - I'm just mulling ideas around.
2023-05-08 08:45:37 <veltas      > vms14: I disagree with what you've been saying recently that it will take too long to do nice stuff, or is impossible to do nice stuff, in your own assembly forth
2023-05-08 08:45:53 <veltas      > Writing a Forth is not a massive undertaking, and calling external stuff isn't either
2023-05-08 08:46:00 <KipIngram   > I'm trying to pre-think the EXPECT level stuff to make the editor construction almost trivial.
2023-05-08 08:46:40 <vms14       > veltas: I always think the process would be better in assembly than in C
2023-05-08 08:47:07 <KipIngram   > I picture a word EDIT that takes a block # and a line #.  It'll count newlines to find that line, and then the edit process will handle everything in the block from that line on.
2023-05-08 08:47:23 <vms14       > but the binding with C when using C is just to write a function
2023-05-08 08:47:34 <vms14       > I don't have to mess with ABI calls or alike
2023-05-08 08:48:22 <vms14       > I even considered java xD
2023-05-08 08:48:29 <vms14       > I just hate it, so no
2023-05-08 08:49:38 <veltas      > vms14: Calling external stuff is very easy though and doesn't take long to get down
2023-05-08 08:49:45 <veltas      > When you understand how it's easy
2023-05-08 08:50:18 <vms14       > veltas: doesn't it depend on every compiler used?
2023-05-08 08:51:18 <vms14       > I saw some ways to use assembly from C
2023-05-08 08:51:28 <vms14       > you could give it values and have them changed
2023-05-08 08:51:55 <vms14       > but yeah, the reverse way is better as you only interface with C when needed
2023-05-08 08:51:59 <vms14       > the rest is assembly
2023-05-08 08:52:27 <veltas      > Calling C is easy, calling other stuff is harder but literally everything important under the sun is available via a C interface
2023-05-08 08:54:00 <vms14       > what do you mean by other stuff?
2023-05-08 08:58:30 <unjust      > vms14: if you put that union into a struct with at least an enum type member to identify the intended union member to access, that would be a reasonable way to represent an arbitrary object. then add more members to the struct when you need to represent other object metadata
2023-05-08 09:02:59 <vms14       > unjust: yeah, a union and a type property
2023-05-08 09:03:15 <vms14       > the union would cover all the basic data types
2023-05-08 09:03:30 <vms14       > and the "user" defined ones would be a void pointer
2023-05-08 09:03:59 <vms14       > this at least does not force me to allocate integers
2023-05-08 09:04:37 <unjust      > besides asm()/__asm__(), you can also make the C language pedants cringe and go the shellcoder's route of treating an unsigned char[] filled with your desired machine code, and cast it to a void (*)(void) and call - but it's on you to know the calling convention of your platform to be able to properly return to the caller
2023-05-08 09:06:11 <vms14       > lol
2023-05-08 10:52:27 <KipIngram   > Ok, it looks like on my system a 10 byte (decimal) is what functions as newline.  That is, if a block of code has its lines ending in 10, then it TYPEs with proper line feeds.  So editing a line of a block would just involve finding the nth 10 and running the edit word from there with the rest of the block as "max" and the number of bytes up to the 0 that terminates the block contents as the "size."  Edit
2023-05-08 10:52:29 <KipIngram   > only prints up to the next 10.
2023-05-08 10:53:21 <KipIngram   > And it will make sure that valid string bytes don't get pushed off the end.
2023-05-08 14:29:23 <unjust      > skvery: as in squares?
2023-05-08 18:23:58 <vms14       > https://pfe.sourceforge.net/4thtutor/4thtutor.htm