2022-03-24 00:29:41 <KipIngram   > Well, I caught gdb pretty red-handed failing to properly step away from the breakpoint.  It of course replaces the byte at the break address with the 0xCC opcode.  But when I then "step," it's supposed to put the original byte back and a new 0xCC at the first byte of the next instruction, and RUN THE FIRST INSTRUCTION.  It's not doing that properly - I can tell from inspecting the registers.
2022-03-24 00:30:13 <KipIngram   > To get a clear picture of what was going on I had to add a new label at the end of the handler and break there, and inspect the final results.
2022-03-24 00:30:38 <KipIngram   > Also, dings on gdb for not allowing a breakpoint to be set at an ADDRESS.
2022-03-24 00:31:20 <KipIngram   > I shouldn't have had to add a label - I should be able to slap a break anywhere I want, and I'd be taking responsibility for making sure it was at the first byte of an instruction.
2022-03-24 00:31:53 <KipIngram   > dollars to donuts that when it was written it was written with C in mind.
2022-03-24 00:33:50 <KipIngram   > So, where am I as the day ends.  I found a reference that gave the offsets for each register in that context structure.  I used those to write my code - what it's trying to do is aim the context rip at NEXT and the context r13 (the Forth IP) at ERR, and load an 8 error code into context rcx (top of stack).  So I'm just trying to return to 8 ERR.
2022-03-24 00:34:21 <KipIngram   > That "doesn't fail."  It doesn't do 8 ERR, and it inserts a bogus character into the input stream, but the system continues to run.
2022-03-24 00:35:07 <KipIngram   > However, I can tell by looking at the RAM region pointed to by rdx that those offsets aren't right.  It LOOKS like the offsets should all be 0x28 higher.   But if I change the code to do that (and confirm that the block was changed in all the right ways), I segfault.
2022-03-24 00:35:24 <KipIngram   > So, further along than this afternoon, but... ugh.
2022-03-24 00:35:30 <KipIngram   > Doesn't feel like a near thing yet.
2022-03-24 00:39:18 <KipIngram   > It really bothers me to see the docs and what I see in gdb fail so completely to mesh.
2022-03-24 00:45:58 <KipIngram   > Ah... here:
2022-03-24 00:46:01 <KipIngram   > https://stackoverflow.com/questions/18913859/what-is-the-right-way-to-operate-ucontext-t
2022-03-24 00:46:33 <KipIngram   > There is some description of the context structure, and it shows five 8-byte items PRIOR TO the general registers in the structure.  That's 0x28 bytes.
2022-03-24 00:46:53 <KipIngram   > That makes what I see in RAM match with the offsets I found - the offsets would then be within the register part of the structure.
2022-03-24 00:47:19 <KipIngram   > Unfortunately, that works "less well" than the other, though that may just be becaue I'm therefore messing with more innocuous registers.
2022-03-24 00:47:39 <KipIngram   > I mean, it doesn't get much less innocuous than rip and Forth IP.
2022-03-24 01:18:01 <KipIngram   > You know, one possible issue here, which isn't really long-term relevant given what I'm ultimately trying to do (catch faults that occur while I'm executing my self-contained primitives), might be the fact that when I get these SIGINT signals I'm running a syscall.  Though I don't think the interrupt actually occurs until I return to user space.  But specifically I'm in key, so that might explain why I get a
2022-03-24 01:18:04 <KipIngram   > ghost character.
2022-03-24 01:18:23 <KipIngram   > But I never run the code that actually responds to that, so I don't know.
2022-03-24 01:18:44 <KipIngram   > I really think I'm doing exactly what I thought I wanted to do to the context.
2022-03-24 01:19:05 <KipIngram   > Not seeing any reason yet why it shouldn't work.
2022-03-24 01:35:15 <KipIngram   > Well, I'll be damned.
2022-03-24 01:35:41 <KipIngram   > I shifted tack - I abandoned the SIGINT and tried SIGFPE instead (floating point error).  That's a goal anyway.
2022-03-24 01:35:50 <KipIngram   > And... it *works*.  Flawlessly.
2022-03-24 01:36:03 <KipIngram   > 12345  ok
2022-03-24 01:36:05 <KipIngram   >   ok
2022-03-24 01:36:07 <KipIngram   >   ok
2022-03-24 01:36:09 <KipIngram   >   ok
2022-03-24 01:36:11 <KipIngram   >   ok
2022-03-24 01:36:13 <KipIngram   > 1 2 3 4 5 0 /  /: floating point error
2022-03-24 01:36:15 <KipIngram   > . 12345  ok
2022-03-24 01:36:34 <KipIngram   > That is EXACTLY what it's supposed to do - it's supposed to revert away the earlier part of the line.
2022-03-24 01:37:03 <dave0       > nice KipIngram !
2022-03-24 01:37:47 <KipIngram   > It works for SIGSEGV too now.
2022-03-24 01:38:05 <KipIngram   > There's just something about being in the middle or aftermath of a syscall that fouls it up.
2022-03-24 01:38:13 <KipIngram   > but that's not even where I really wanted it.
2022-03-24 01:38:24 <KipIngram   > DAMN IT WORKS!!!!!!
2022-03-24 01:38:31 <dave0       > lol
2022-03-24 01:38:32 <KipIngram   > What a nice gift to go to bed on.
2022-03-24 01:38:41 <dave0       > you got the programmer's high :-)
2022-03-24 01:38:42 <KipIngram   > This was a deep dive day, man.
2022-03-24 01:38:49 <KipIngram   > Absolutely.  :-)
2022-03-24 01:39:14 <KipIngram   > Ok, well, now I need another one - I want floating point errors and addressing errors.  Those were the goals.
2022-03-24 01:39:17 <KipIngram   > But... tomorrow.
2022-03-24 01:39:22 <KipIngram   > Heh heh heh...
2022-03-24 01:42:57 <KipIngram   > well, I guess that's not a FLOATING point error.
2022-03-24 01:43:00 <KipIngram   > Arithmetic error.
2022-03-24 01:46:27 <KipIngram   > Night guys.  Time to rest.
2022-03-24 02:02:10 <dave0       > nite KipIngram
2022-03-24 04:10:56 <veltas      > KipIngram: You never leave user space
2022-03-24 04:11:28 <veltas      > The signal is invoked and the main thread halts, the signal runs on a new stack but is running in userspace
2022-03-24 04:11:58 <veltas      > The ghost character for ^C I would guess is the character code of ^C being forwarded to the program's stdin
2022-03-24 04:12:48 <veltas      > Also nice, yeah when I get back to my FORTH I have plans to do the same thing: catch errors like divide by zero and segfaults
2022-03-24 04:14:30 <veltas      > I am going to implement exceptions so I will have it cause an exception throw
2022-03-24 04:14:54 <veltas      > And I shall probably steal your code to do this lol
2022-03-24 06:09:52 <veltas      > The starting forth editor is actually quite usable, a few minor modifications to the preview words at the end of a command and it is not far off from using vi with only basic string matching
2022-03-24 06:37:46 <veltas      > BCPL seems to have some nicer stuff than B or C
2022-03-24 06:43:09 <eris[m]     > oh?
2022-03-24 06:50:55 <veltas      > eris[m]: The ternary in BCPL is written -> ,  so you can write e.g. https://pastebin.com/raw/37U2W1hZ
2022-03-24 06:51:45 <veltas      > https://www.cl.cam.ac.uk/~mr10/bcplman.pdf
2022-03-24 06:52:14 <veltas      > Some example programs pp.245-
2022-03-24 06:53:32 <veltas      > Seems to have implicit end-of-line semicolon as well
2022-03-24 07:03:32 <veltas      > Unfortunately it suffers from B's problem of "what are bytes lol"
2022-03-24 08:03:12 <veltas      > @ gets an address and ! dereferences
2022-03-24 09:51:14 <KipIngram   > So is there some prohibition on x86_64 /  Linux against loading the processor stack pointer?  At one point yesterday I tried to write it, using a value that I had earlier read from it, and that didn't seem to want to work.
2022-03-24 09:51:21 <KipIngram   > It was late - I didn't follow up on it.
2022-03-24 09:51:56 <KipIngram   > I don't use rsp myself - generally it keeps whatever value it starts out with all the way through, except for when I do syscalls.
2022-03-24 09:52:25 <KipIngram   > The idea was to restore it to that value on error recovery, just in case it had "grown some" during the handler shenanigans.
2022-03-24 09:54:23 <KipIngram   > I may have just had some silly mistake.  I just wrote a quick primitive that just copies rsp to rax and then copies it back - that didn't give any problem.  So it's  not some specially enforced restriction.
2022-03-24 09:56:22 <KipIngram   > Must have just been a slip up - it seems to work fine this morning.
2022-03-24 10:05:56 <veltas      > KipIngram: Some signals don't allow changing the stack
2022-03-24 10:06:27 <veltas      > Which makes sense, signals that just notify of something shouldn't, signals that indicate the thread crashed should
2022-03-24 10:12:32 <KipIngram   > It seems to be fine to do what I wanted this morning.  I must have just made a "sleepy error" last night.
2022-03-24 10:13:26 <KipIngram   > So, when the addressing or floating point exception is actually generated by one of my primitives (which means I'm nowhere near a syscall), this works perfectly.  If it's sitting there waiting for a keystroke, though, and I externally send it a sig 8 of sig 11, it hangs.
2022-03-24 10:13:43 <KipIngram   > So this whole apparatus doesn't play well with syscalls.
2022-03-24 10:13:59 <KipIngram   > But that's not really where I need it, either.
2022-03-24 10:16:42 <KipIngram   > An external signal sent while I'm in a loop (syscall free) works fine - it just interrupts the loop.
2022-03-24 10:36:59 <veltas      > Hmmm I'm sure there's some way of getting it to work while it's suspended
2022-03-24 10:38:30 <veltas      > KipIngram: Relevant? https://stackoverflow.com/a/32813165
2022-03-24 11:00:44 <KipIngram   > Yeah - I was thinking more about it.  When I'm waiting for a keystroke, I'm suspended / asleep.  Then the handler comes along and re-directs execution away from the code that's eventually going to wake me back up.  So it's probably doing exactly what it's supposed to, but I'm asleep and have no way to wake up.
2022-03-24 11:01:28 <KipIngram   > The most brute-force thing to do would be to make the handler esaily switchable (I could just plug a return instruction into the first byte) and switch it off when I'm about to make a syscall and back on after.
2022-03-24 11:02:02 <KipIngram   > Then it should just ignore those signals if they're externally sent during a syscall.
2022-03-24 11:22:49 <veltas      > KipIngram: Have you looked at the stackoverflow answer I posted though?
2022-03-24 11:23:07 <KipIngram   > Not yet - troubleshooting something else at the moment.
2022-03-24 11:23:18 <veltas      > Okay because it looks like it could answer the problem
2022-03-24 11:41:24 <KipIngram   > Ah, so maybe I need the SA_RESTART flag.
2022-03-24 11:41:38 <KipIngram   > That does look on point.
2022-03-24 12:10:57 <KipIngram   > That seems to have done the trick.
2022-03-24 12:11:16 <KipIngram   > I still need to avoid taking the error recovery action if I'm in a syscall.
2022-03-24 12:11:36 <KipIngram   > But now if I plug a ret into the handler I no longer get the "shadow keystroke"
2022-03-24 12:11:42 <KipIngram   > Signal is just cleanly ignored.
2022-03-24 12:11:55 <KipIngram   > Thank you - that was spot on.
2022-03-24 12:12:44 <KipIngram   > So anyway, I'm not going to plug rets routinely - I'm going to have a small handful of these for different faults.  I'll add a switch variable and have them all check it.
2022-03-24 12:13:24 <KipIngram   > Now that I know where my registers are in the stack context I can get at stuff like that.
2022-03-24 12:14:10 <KipIngram   > Of course, there are "gotchas" here.
2022-03-24 12:14:46 <KipIngram   > What if I send EXPECT a bad buffer address?  It's not going to access that buffer itself - it's going to pass it into a read syscall.
2022-03-24 12:14:55 <KipIngram   > So the violation would occur IN the syscall.
2022-03-24 12:15:11 <KipIngram   > But anyway, forward progress here.
2022-03-24 12:21:12 <KipIngram   > Guess I could FILL the buffer before calling EXPECT.
2022-03-24 12:21:25 <KipIngram   > Then if it has any bad addresses, they'd fault on the fill.
2022-03-24 12:21:54 <KipIngram   > Or no - not that.  Have EXPECT fill the buffer before making tye syscall.  That's what I was thinking, even though it's not what I said.
2022-03-24 12:22:26 <KipIngram   > FILL is "rep fast."
2022-03-24 12:23:02 <KipIngram   > And that has the fringe benefit of clearing out old content.
2022-03-24 14:10:16 <KipIngram   > Ok, I added a switch and wrappered the few syscalls in my code with it.  It now behaves extremely well - signals are ignored while I'm in a syscall and otherwise responded to.
2022-03-24 21:20:25 <KipIngram   > Finally got around to writing .wipe, so now "helper words" actually means something.
2022-03-24 21:20:40 <KipIngram   > Makes quite a difference - I have a whole bunch of helpers.
2022-03-24 21:20:54 <dave0       > hey KipIngram
2022-03-24 21:21:03 <KipIngram   > maw dave0
2022-03-24 21:21:12 <dave0       > sup?
2022-03-24 21:21:23 <KipIngram   > Not a lot.  Just a routine work day.
2022-03-24 21:22:11 <dave0       > i should do some documentation!
2022-03-24 21:22:30 <dave0       > i've been putting off commenting my sectorFORTH
2022-03-24 21:23:49 <dave0       > KipIngram: i re-wrote sectorforth (https://github.com/cesarblum/sectorforth) from scratch and it works but i have to finish the code comments
2022-03-24 21:24:07 <KipIngram   > Is that the one that fits in one disk sector?
2022-03-24 21:24:12 <dave0       > yup
2022-03-24 21:24:16 <KipIngram   > Something tight would probably need comments.  :-)
2022-03-24 21:24:34 <KipIngram   > There's bound to be some "cleverness" in there that bears explaining.
2022-03-24 21:25:07 <dave0       > the real interesting thing is the `hello.forth` which builds up a forth to print "hello world"
2022-03-24 21:25:25 <KipIngram   > I'm really more or less at the point where I could start working on my editor with comment support and so on.
2022-03-24 21:25:46 <KipIngram   > Yeah, that would be interesting.  Bootstrapping is generally an interesting topic.
2022-03-24 21:25:47 <dave0       > cool
2022-03-24 21:27:05 <dave0       > rp@ pushes the address of the return stack pointer onto the data stack, which i use to make zero!   : 0 rp@ rp@ - ;
2022-03-24 21:27:26 <dave0       > it's funny to me that you have to build the number `zero`
2022-03-24 21:29:47 <KipIngram   > Why not just : 0 dup - ; ?
2022-03-24 21:30:45 <KipIngram   > Of course, I even build 0 in assembly, technically - I push top of stack and then xor rcx, rcx.
2022-03-24 21:31:39 <KipIngram   > You know in "pure math" they do stunts like that - successive numbers are defined in terms of a "successor" iterator.
2022-03-24 21:32:06 <KipIngram   > They "build up" the natural numbers that way, when they're bootstrapping the whole shooting match.
2022-03-24 21:39:42 <dave0       > sectorFORTH has the primitives:   : ; @ ! - nand 0= sp@ rp@ key emit    and variables   last here >in state
2022-03-24 21:40:06 <dave0       > sp@ pushes the current address of the data stack, rp@ does it for return stack
2022-03-24 21:40:13 <dave0       > : dup sp@ @ ;
2022-03-24 21:40:39 <dave0       > : 0 rp@ rp@ - ;     and then     : 1+ 0 0= - ;
2022-03-24 21:40:51 <dave0       > so it sort of uses the successor thing like you said :-)
2022-03-24 21:41:46 <dave0       > it was quite fun writing that
2022-03-24 21:57:38 <KipIngram   > Ah, I see.
2022-03-24 21:58:19 <KipIngram   > Interesting.
2022-03-24 21:58:50 <KipIngram   > So I guess it promises "true" is 1?
2022-03-24 21:59:00 <KipIngram   > Sorry - I mean -1.
2022-03-24 21:59:13 <SpaceCoaster> Dave0: that looks like fun. I have been playing with a 65816 forth that someone else developed but it is a bit too much to understand. This looks simpler with very few moving parts.
2022-03-24 22:03:01 <KipIngram   > So, no , ?
2022-03-24 22:03:14 <KipIngram   > Do : and ; behave as expected?
2022-03-24 22:03:31 <dave0       > KipIngram: yep, flags are 0 and -1 ... you coud also have used nand to make -1 but 0= is shorter :-)
2022-03-24 22:03:41 <dave0       > KipIngram: yup
2022-03-24 22:03:49 <KipIngram   > Yah - nand can do anything.  :-)
2022-03-24 22:04:06 <KipIngram   > So it's got a whole interpreter compiler?  And that fits in a sector?
2022-03-24 22:04:22 <dave0       > KipIngram: are you interested in having a look at it? i can zip up what i've got
2022-03-24 22:04:38 <dave0       > KipIngram: yup fully interactive, in a boot sector
2022-03-24 22:04:38 <KipIngram   > What's it written in?
2022-03-24 22:04:45 <KipIngram   > That's impressive.
2022-03-24 22:05:19 <KipIngram   > Nothing about the interpreter / compiler is "that hard," but by the time you get all the details tended to there's a fair bit there.
2022-03-24 22:08:15 <dave0       > KipIngram: https://paste.c-net.org/BobbieChopping
2022-03-24 22:11:15 <KipIngram   > Ok, that's pretty cool.  I will want to look through that pretty carefully to see how it's put together.
2022-03-24 22:11:26 <KipIngram   > And you've got something you can run it on?
2022-03-24 22:11:47 <dave0       > oh i run it on dosbox
2022-03-24 22:11:57 <KipIngram   > Ah, ok.  That counts.
2022-03-24 22:12:39 <KipIngram   > I've really been meaning to dig into some virtualization tools.  I keep saying I want to write an OS - I don't actually have to wait until I design a piece of hardware.
2022-03-24 22:12:53 <dave0       > i did test the   hello.forth   file but it's tedious to type it all in (but it does work :-)
2022-03-24 22:13:32 <dave0       > KipIngram: i think writing an OS would be a lot of work!
2022-03-24 22:13:34 <KipIngram   > Mine's up to 18669 bytes now.
2022-03-24 22:13:45 <KipIngram   > That's the sum of the used body and header space.
2022-03-24 22:14:01 <KipIngram   > I've got that and the stacks living in a 64k buffer.
2022-03-24 22:14:25 <dave0       > oh is it for msdos?
2022-03-24 22:14:27 <KipIngram   > Well, where exactly the OS leaves off and one's tools begin - hard to say, I guess.
2022-03-24 22:14:54 <KipIngram   > No.  It's intended to be portable.  When I put it on a gadget someday it will just own all the RAM.
2022-03-24 22:15:06 <dave0       > oh nice
2022-03-24 22:15:11 <KipIngram   > And offer some sort of reasonable memory allocation tools.
2022-03-24 22:15:29 <KipIngram   > And some kind of file system, etc.
2022-03-24 22:16:06 <dave0       > i saw a homebrew cpu running minix and connected to the internet
2022-03-24 22:16:07 <KipIngram   > That bit about the blurry line between OS and tools is particularly true for Forth.  It just sort of spans the whole gamut.
2022-03-24 22:16:21 <KipIngram   > Nice.  I want to do an FPGA processor at some point.
2022-03-24 22:16:25 <dave0       > a forth os with tcp/ip stack and a web server would be awesome
2022-03-24 22:16:28 <KipIngram   > And would love to put those two projects together.
2022-03-24 22:16:47 <KipIngram   > I fancy having a "guaranteed back door free" computer that's actually marginally competent.
2022-03-24 22:17:00 <dave0       > i think chuck moore said an operating system is just a limitation in your programming langauge
2022-03-24 22:17:28 <KipIngram   > Sounds like something he might say.  I do have some kind of notion that Forth "prefers" to run on bare metal.
2022-03-24 22:17:43 <KipIngram   > Running it under an OS keeps it from really shining quite as nicely.
2022-03-24 22:17:59 <KipIngram   > You wind up writing reams of stuff to interface to the existing OS, so you're really still having to use it.
2022-03-24 22:18:19 <KipIngram   > that said, I might try to turn this into my Linux shell at some point.
2022-03-24 22:18:28 <KipIngram   > That's another "project branch" I've thought about.
2022-03-24 22:19:01 <KipIngram   > It has NO notion of Linux right now, really.  It uses a few syscalls, but there's no "systematic interface."
2022-03-24 22:19:42 <KipIngram   > I didn't really write it with the notion of mapping onto Linux nicely in mind - it's really written with a "stand alone" perspective.
2022-03-24 22:25:39 <vms14       > KipIngram: why do you think running forth under an OS keeps it from really shining?
2022-03-24 22:25:47 <KipIngram   > Looks like I currently have 336 words.
2022-03-24 22:25:53 <vms14       > I think yes, if it's a real forth
2022-03-24 22:26:00 <KipIngram   > That's after dropping all the helpers.
2022-03-24 22:26:43 <vms14       > but if you start making a language similar to forth then you can take the os to your advantage
2022-03-24 22:27:07 <vms14       > as long as you don't follow the forth 'specs'
2022-03-24 22:27:15 <KipIngram   > Well, like I said - because you have to operate "through the OS" to really "do" anything.
2022-03-24 22:27:47 <KipIngram   > I may just be being elitist.
2022-03-24 22:31:32 <vms14       > well forth dislikes an os, I agree
2022-03-24 22:31:50 <vms14       > he wants to be the os
2022-03-24 22:35:01 <KipIngram   > Yes.  :-)
2022-03-24 22:35:35 <vms14       > I've rewritten my forth, now I've fixed a bug I had, couldn't use strings inside if, if-else, dotimes, etc
2022-03-24 22:36:04 <vms14       > and I think today I've written the most useful function in my life, a debug function xD
2022-03-24 22:36:33 <vms14       > it's just a function with an if to check if debug flag is on, I call it from all the functions I have
2022-03-24 22:36:35 <KipIngram   > How does that work?
2022-03-24 22:36:48 <vms14       > all functions call it passing some arguments
2022-03-24 22:36:53 <KipIngram   > I usually debug my Forth by staring at my code and inserting debug prints.
2022-03-24 22:37:18 <KipIngram   > I want a "real" debugger, but I'll have to write it and it will be a bit of a project.
2022-03-24 22:37:25 <KipIngram   > I want it integrated with the editor.
2022-03-24 22:37:58 <KipIngram   > I want it to use the "alternate console" - whenever I "go to debugger" (hit a breakpont, etc.), I want it to flip over to that console and draw the debug screen.
2022-03-24 22:38:08 <KipIngram   > Keep the primary console available to the application.
2022-03-24 22:38:54 <KipIngram   > Have a nice display that shows me my registers, my Forth stacks, whatever memory I've opted, etc.  And a call tree.
2022-03-24 22:39:15 <vms14       > KipIngram: this is mostly what I do, but with a global flag
2022-03-24 22:39:24 <KipIngram   > which is pretty closely related to the return stack, so it's probably just a fancy labeling on the return stack.
2022-03-24 22:39:43 <vms14       > and I can put names of functions in a debug array so the debug function will print stuff only if called from those functions
2022-03-24 22:40:13 <vms14       > debug knows who is calling it, prints the name of the function which called it + the arguments given
2022-03-24 22:40:37 <vms14       > if there are no items in the debug array then prints for all functions
2022-03-24 22:41:31 <KipIngram   > That sounds kind of handy.
2022-03-24 22:41:32 <vms14       > https://termbin.com/gt1h if you want to try it you can just put some code and it will show all the functions
2022-03-24 22:41:44 <vms14       > it's a perl script so perl file.pl
2022-03-24 22:41:57 <vms14       > and has no readline, rlwrap or similar would be nice
2022-03-24 22:42:09 <vms14       > if you put just a 1 you'll see a lot of stuff
2022-03-24 22:42:20 <vms14       > has almost no builtins, but now if and dotimes work
2022-03-24 22:42:39 <vms14       > 3 { "some text" . } dotimes
2022-03-24 22:42:51 <vms14       > you can disable the debug with 0 core-debug
2022-03-24 22:43:05 <vms14       > and turn on it again with 1 core-debug
2022-03-24 22:44:10 <vms14       > strings can have interpolation with other strings or numbers using ~a and ~% is a newline
2022-03-24 22:44:24 <vms14       > ~a takes an item from the stack and just puts it there
2022-03-24 22:44:58 <vms14       > it is handy btw, it helped me a lot to catch the bugs very fast as it's like a trace
2022-03-24 22:45:03 <KipIngram   > That sounds a little like the formatted output I put together on my last one.
2022-03-24 22:45:15 <vms14       > I mean every function says what it finds and what does/transforms to
2022-03-24 22:45:28 <KipIngram   > It "works" like TYPE, but if it seems format fields in the string it will take a stack argument for each one, and print it per the format field specifications.
2022-03-24 22:45:43 <KipIngram   > It was a pretty damn complete "printf like" setup.
2022-03-24 22:45:57 <KipIngram   > Used a bytecode interpreter to "execute" the format fields.
2022-03-24 22:46:15 <KipIngram   > That little vm had a "stack" of byte-wide items living in a 64-bit cell.
2022-03-24 22:46:18 <vms14       > I like what I have, I was worried last time I've tried because strings didn't work when used inside if or alike
2022-03-24 22:46:53 <vms14       > but sure I'll find some bug showing how bad the design is and I'll have to rewrite it XD
2022-03-24 22:47:04 <vms14       > instead of return stack I have an execution stack
2022-03-24 22:47:39 <vms14       > the interpreter is a loop that checks if there's data in that stack and just executes a word from there
2022-03-24 22:47:40 <KipIngram   > My "implementation before the previous one" was written in GNU C, and it was just so horrible looking I could hardly believe it.
2022-03-24 22:48:01 <vms14       > hahha mine is dirty surely
2022-03-24 22:48:48 <vms14       > and I'm not following the forth way, I shouldn't even say it's a forth like
2022-03-24 22:49:03 <KipIngram   > Hey, you're interested and that's cool.
2022-03-24 22:49:16 <vms14       > it just has a stack and rpn, but no return stack and no memory allocation
2022-03-24 22:49:41 <vms14       > but the stack can take any value including lists, and you can quote words with ' they'll get pushed on the stack
2022-03-24 22:50:15 <vms14       > and now that i've fixed that issue I can start adding builtins
2022-03-24 22:50:24 <vms14       > it can compile yet with : and ;
2022-03-24 22:50:37 <vms14       > and I've added [ and ] but idk what will happen
2022-03-24 22:50:42 <vms14       > didn't tried them
2022-03-24 22:51:59 <KipIngram   > I'm fond of [ and ]
2022-03-24 22:52:18 <KipIngram   > I don't really use them a particularly large amount, but I just like how easy you can switch back and forth.
2022-03-24 22:52:46 <KipIngram   > My most common thing is to use [ to end definitions that don't need a return at the end (because they loop back to the start).
2022-03-24 22:52:59 <vms14       > I think they are working
2022-03-24 22:53:06 <KipIngram   > Only the compile time part of what ; does is needed in that situation, and that's what [ is.
2022-03-24 22:53:12 <KipIngram   > Excellent.
2022-03-24 22:53:35 <vms14       > : oh 1 2 3 [ 4 5 6 ] ; pushes  4 5 6  on the stack
2022-03-24 22:53:36 <KipIngram   > As someone who was just desperately hoping something would work this time last night, I'm happy for you.  :-)
2022-03-24 22:53:48 <KipIngram   > Looks good.
2022-03-24 22:53:56 <KipIngram   > Now does oh push 1 2 3?
2022-03-24 22:54:06 <vms14       > it does
2022-03-24 22:54:10 <vms14       > and only those 1 2 3
2022-03-24 22:54:24 <KipIngram   > Gold star.
2022-03-24 22:54:31 <vms14       > every time I execute, 4 5 6 never got into the definition
2022-03-24 22:54:46 <KipIngram   > Yup.
2022-03-24 22:55:53 <vms14       > but what should happen if I don't put a ] on the word definition?
2022-03-24 22:55:58 <vms14       > should be an error?
2022-03-24 23:01:21 <vms14       > seems to work anyways but not sure
2022-03-24 23:01:32 <KipIngram   > Well, it depends on how you handle end of line, I guess.
2022-03-24 23:02:00 <KipIngram   > In Forth if you don't use ; then you won't get a return, and unless there's some way you know you won't try to execute past there, Forth will just run off into the weeds.
2022-03-24 23:02:29 <KipIngram   > In my case there's an unconditional jump, so I know I don't need (;) (the runtime piece of ; ).
2022-03-24 23:03:07 <vms14       > : oh 9 8 7 [ 4 5 6 ; compiles oh and the stack then is { 4 5 6 }
2022-03-24 23:03:17 <KipIngram   > In old FIG Forth the header of your next word would be right there, but I deliberate put my headers remote so that I could put definitions literally right by each other and let execution pass along like that.
2022-03-24 23:03:21 <vms14       > if I execute oh then the stack is { 4 5 6 9 8 7 }
2022-03-24 23:03:23 <KipIngram   > That was an explicit plan.
2022-03-24 23:03:42 <vms14       > and stills putting 9 8 7 every time i call it
2022-03-24 23:03:53 <vms14       > I don't care about newlines
2022-03-24 23:04:01 <vms14       > well I'll try
2022-03-24 23:04:41 <KipIngram   > Reason I thought of it is that someone here in channel suggested to me a few days ago that since I always write short definitions I could let end of line end the definition.
2022-03-24 23:04:47 <KipIngram   > I'm not doing that, but it was a valid idea.
2022-03-24 23:05:25 <vms14       > it does not care about newlines, seems to work anyways
2022-03-24 23:06:07 <KipIngram   > I think that's as it should be.
2022-03-24 23:06:08 <vms14       > the fact is ; is immediate so does not care when is executed, it ends compiling mode, and uses a global array that holds the contents of the word definition
2022-03-24 23:06:25 <KipIngram   > In my past efforts I've not had newlines even supported.
2022-03-24 23:06:33 <vms14       > the word being defined is also global
2022-03-24 23:06:39 <KipIngram   > I just treated 4 kB disk blocks as 64 lines of 64 chars each.
2022-03-24 23:06:48 <KipIngram   > So it lookedlike one long line to Forth.
2022-03-24 23:07:03 <vms14       > and only in compile mode the interpreter adds stuff to that word compile array
2022-03-24 23:07:22 <KipIngram   > Right.  ; is immediate, and runs the minute it's encountered.
2022-03-24 23:07:36 <KipIngram   > But it will usually 1) compile a (;) and 2) set STATE = 0.
2022-03-24 23:07:44 <KipIngram   > And possibly tail optimize.
2022-03-24 23:08:09 <vms14       > : gets the word to be defined and sets $word_to_compile to that name and enters compiling mode
2022-03-24 23:08:20 <KipIngram   > Ok.
2022-03-24 23:08:48 <KipIngram   > Same with mine.  : is immediate (I can define words in the middle of words:
2022-03-24 23:09:01 <KipIngram   > : foo  ...code...  : bar  ...code... ;
2022-03-24 23:09:18 <vms14       > ; compiles and resets the word contents, but does not the name
2022-03-24 23:09:22 <KipIngram   > It CREATEs a new dictionary entry, makes it a : def, and enters compile mode.
2022-03-24 23:09:25 <vms14       > :0 mine is not immediate,
2022-03-24 23:09:38 <KipIngram   > it typically isn't.
2022-03-24 23:09:49 <KipIngram   > If you want to do that you have to separate your headers and bodies.
2022-03-24 23:10:43 <vms14       > never thought about nested definitions
2022-03-24 23:10:55 <vms14       > I could change $word_to_compile to an array
2022-03-24 23:11:10 <vms14       > I don't even have nested lists
2022-03-24 23:11:13 <KipIngram   > Well, I've found it useful, but it's certainly optional.
2022-03-24 23:11:29 <KipIngram   > I would generally put them on different lines:
2022-03-24 23:11:35 <KipIngram   > : foo  ...code...
2022-03-24 23:11:41 <KipIngram   > : bar  ...code ... ;
2022-03-24 23:11:50 <vms14       > but then I should have a list of lists to hold the contents for every word being defined
2022-03-24 23:11:58 <vms14       > hmm
2022-03-24 23:11:59 <KipIngram   > And if bar recurses, it will jump back to bar, not foo.
2022-03-24 23:12:14 <vms14       > and ; ends both?
2022-03-24 23:12:19 <KipIngram   > yes.
2022-03-24 23:12:31 <vms14       > I could make a way to insert stuff in a word
2022-03-24 23:12:34 <KipIngram   > It compiles (;) and switches to STATE=0.
2022-03-24 23:12:56 <dave0       > KipIngram: ah! i understand your words now :-)
2022-03-24 23:13:07 <dave0       > how they can share code
2022-03-24 23:13:14 <KipIngram   > Best way to think about the body section is to regard it as an array of 32-bit cells.
2022-03-24 23:13:22 <KipIngram   > The headers "point into it."
2022-03-24 23:13:54 <KipIngram   > Well, before the 32-bit cells for definitions there is the machine code for the primitives and so on, but I 4-byte align after that's all assembled.
2022-03-24 23:14:40 <KipIngram   > So you need the headers only at compile time - in theory if you were compiling some gadget application you wouldn't need to include them in the image you flashed.
2022-03-24 23:14:45 <vms14       > initially I was thinking in make ; pop some array so the next ; would end the previous definition
2022-03-24 23:15:00 <vms14       > and have an array of arrays for the words contents
2022-03-24 23:15:29 <KipIngram   > Yeah - if your underlying system can just regard definitions as lists of items, then you can just stop at the end of the list.
2022-03-24 23:15:37 <vms14       > it's a nice idea, I'll save it
2022-03-24 23:16:03 <vms14       > I'm using perl, this is why my forth is so different
2022-03-24 23:16:18 <vms14       > doing it in the forth way would be counter productive
2022-03-24 23:16:19 <KipIngram   > Right - I still think you're learning stuff.
2022-03-24 23:16:33 <vms14       > hahah yes, I didnt learn forth yet
2022-03-24 23:16:49 <vms14       > wanted a forth in C but I'll try to add ffi to this one
2022-03-24 23:17:11 <vms14       > wanted not, but I want to use some C libraries
2022-03-24 23:17:50 <vms14       > and actually I'm designing while trying stuff, that's why I think I'll have to rewrite several times
2022-03-24 23:18:05 <vms14       > I guess later some feature will show a flaw in design
2022-03-24 23:18:12 <KipIngram   > I regard this one as a "start over" of the last one.
2022-03-24 23:18:23 <KipIngram   > Last one was my first assembly language effort since college.
2022-03-24 23:18:35 <KipIngram   > Assembly language Forth, I mean.
2022-03-24 23:19:07 <vms14       > I rewrote mine from scratch, using some previous code as reference, but not pasting any line
2022-03-24 23:19:14 <KipIngram   > Very first one was in assembly, for the 6809.
2022-03-24 23:19:30 <KipIngram   > It was hideious.
2022-03-24 23:19:35 <vms14       > I have to learn asm, now I have a use case :D
2022-03-24 23:19:36 <KipIngram   > hidious
2022-03-24 23:19:48 <KipIngram   > asm is very nice - there are just no restrictions.
2022-03-24 23:20:15 <KipIngram   > Certain aspects of the structure you have to get right, though, or you'll find yourself unable to write anything.
2022-03-24 23:20:27 <KipIngram   > Usually your code is made unwritable.
2022-03-24 23:21:02 <KipIngram   > in Linux you can call mprotect to change that, but I just allocated a buffer with full rwx permissions and copied the whole system to it.
2022-03-24 23:22:00 <KipIngram   > That load image is still present, though - COLD uses it to make a fresh copy.
2022-03-24 23:22:52 <vms14       > forth has something that I like, but I have no idea of what is it
2022-03-24 23:23:17 <dave0       > vms14: i like how forth isn't c :-)
2022-03-24 23:23:25 <vms14       > btw my forth will overwrite previous definitions
2022-03-24 23:23:32 <KipIngram   > :-)
2022-03-24 23:23:33 <vms14       > it's a hash instead of linked list
2022-03-24 23:23:35 <vms14       > dave0: xD
2022-03-24 23:23:38 <KipIngram   > cool
2022-03-24 23:23:50 <vms14       > KipIngram: not so cool I guess
2022-03-24 23:24:10 <KipIngram   > Right now mine won't do that.
2022-03-24 23:24:22 <vms14       > can't forget but delete them
2022-03-24 23:24:51 <vms14       > and for me it seemed right that a previous word would use a previous definition
2022-03-24 23:25:06 <vms14       > I see a flaw the fact mine overwrites them
2022-03-24 23:25:36 <dave0       > vms14: oohh it only overwrites them in the hash table? the definitions still exist but no name points to them?
2022-03-24 23:25:58 <vms14       > dave0: definitions would get overwritten
2022-03-24 23:26:08 <dave0       > vms14: ooh not allowed to do that
2022-03-24 23:26:12 <vms14       > and previous words using those, will now use the new one
2022-03-24 23:26:23 <dave0       > oh nevermind
2022-03-24 23:26:39 <vms14       > but that's not how it should be
2022-03-24 23:26:48 <vms14       > well, I have not even a return stack xD
2022-03-24 23:27:06 <vms14       > I have an execution stack :D
2022-03-24 23:27:26 <vms14       > using perl I don't see why I should stick to how forth does stuff
2022-03-24 23:27:53 <vms14       > and always liked to steal the concepts I like and do it in my way
2022-03-24 23:28:09 <vms14       > that's also why I like perl, I can do whatever I want however I want
2022-03-24 23:28:29 <vms14       > and I think it's also why I like forth, or at least one of the things I like from it
2022-03-24 23:28:46 <KipIngram   > Well, delete is actually a more flexible feature.  In a typical system it leaves holes in the dictionary that aren't easy to re-use.
2022-03-24 23:28:56 <KipIngram   > I lied earlier - the header section is not completely indispensable.
2022-03-24 23:29:15 <KipIngram   > Headers point to the body implementations, but the cells within a word's definition point back to it's header.
2022-03-24 23:29:26 <KipIngram   > Specifically to a pair of pointers I call CFA/PFA.
2022-03-24 23:29:46 <KipIngram   > The names and the links aren't consulted at run-time, but the CFA always is and the PFA might be.
2022-03-24 23:29:50 <KipIngram   > Primitives have no PFA.
2022-03-24 23:30:08 <vms14       > actually my interpreter when finds a colon word to execute the only thing it does is to update the execution stack
2022-03-24 23:30:26 <vms14       > dotimes multiplies a list in the execution stack xD
2022-03-24 23:30:27 <KipIngram   > In FIG Forth the definition for a word immediately followed the CFA field, so to get from CFA to PFA was just "plus one cell."
2022-03-24 23:30:41 <vms14       > builtin ('dotimes', sub { my ($code, $times) = get(2); to_execution((@$code) x $times)});
2022-03-24 23:30:47 <KipIngram   > But that precludes those "labels within a definition."
2022-03-24 23:31:05 <vms14       > but I can quote words to prevent their execution, they'll get pushed on the stack
2022-03-24 23:31:49 <vms14       > { 1 2 3 . . . } won't execute them, it will build a list like if it was compiling and then push that list to the stack
2022-03-24 23:32:15 <KipIngram   > Interesting.
2022-03-24 23:32:16 <vms14       > ( 1 2 3 . . . ) does execute them, actually ( pushes a delimiter on the stack and ) the end delimiter
2022-03-24 23:32:43 <KipIngram   > No slick features like that on mine - I'm either interpreting or compiling and that's really that.
2022-03-24 23:32:54 <vms14       > well ) does not push, but traverses the stack until it finds the ( delimiter
2022-03-24 23:33:05 <vms14       > then builds the list
2022-03-24 23:33:28 <vms14       > I like this because you can dup drop etc the delimiters
2022-03-24 23:33:49 <vms14       > there's a flaw as if someone pushes the delimiter for some other reason could get confused
2022-03-24 23:33:53 <KipIngram   > For me "definition space" is just one long thing - the only thing that stops execution from moving forward is a jump or a ;
2022-03-24 23:34:00 <vms14       > but the delimiters are a variable you can set
2022-03-24 23:34:34 <KipIngram   > Yeah, I've done some back and forth on how to input strings.
2022-03-24 23:34:44 <KipIngram   > Right now I'm thinking of having a word s and you'd say
2022-03-24 23:34:48 <KipIngram   > s "string"
2022-03-24 23:34:52 <KipIngram   > or s /string/
2022-03-24 23:34:53 <vms14       > for me the way I've implemented strings does not seem right
2022-03-24 23:34:54 <KipIngram   > etc.
2022-03-24 23:35:10 <vms14       > but at least now the interpreter knows when something is a string
2022-03-24 23:35:26 <KipIngram   > That will put the string data in that "ropes" data structure we talked about a week ago or so, and leave a pointer to it on the stack.
2022-03-24 23:35:43 <vms14       > I mean I just split by spaces all the text, this gets in the way when the text has " some strings "
2022-03-24 23:36:07 <vms14       > so before doing that I convert all " stuff like this " into ^stuff-like-this
2022-03-24 23:36:09 <vms14       > xDDD
2022-03-24 23:36:58 <KipIngram   > Yes - I was thinking the other day about that general kind of thing - I decided Forth's "one character at a time" approach is nice - it can scan past spaces in string literals.
2022-03-24 23:37:04 <vms14       > strings being pushed on the stack also have this form, when the interpreter "executes" a string then does the interpolation if the string has ~a
2022-03-24 23:37:51 <vms14       > but for example ~% never get's converted to a newline except when you print it
2022-03-24 23:38:13 <vms14       > I'll have to take care when writing to files and alike
2022-03-24 23:38:45 <vms14       > a string on the execution stack can't have spaces or newlines
2022-03-24 23:39:38 <vms14       > once it's in the parameter stack does not care, but as the user will be able to add stuff to the execution stack it means he can also put strings there
2022-03-24 23:40:10 <vms14       > this is why I only do interpolation with ~a to get the values from the stack, but the string stills being in ^this-form~%
2022-03-24 23:40:37 <vms14       > only when printing ^ gets removed, - converted to a space and ~% to a newline
2022-03-24 23:41:47 <vms14       > this is a flaw I suppose
2022-03-24 23:43:13 <vms14       > "my cat is nice" 3 "~a~a"     { "^3my-cat-is-nice" }
2022-03-24 23:43:37 <vms14       > but . prints as you would expect
2022-03-24 23:53:48 <vms14       > now the user can convert this string to a "normal" string, so words that use strings can use them
2022-03-24 23:54:04 <vms14       > but that converted string won't be able to get in the execution stack
2022-03-24 23:55:09 <vms14       > https://termbin.com/9bjq    "ls" str shell
2022-03-24 23:55:39 <vms14       > and tolines converts that to a list of lines, but there's no way to operate on lists yet
2022-03-24 23:57:57 <vms14       > can't put "ls -t" because - is now a space
2022-03-24 23:58:00 <vms14       > 
ACTION cries