2023-05-17 04:18:26 <veltas      > I guess for assembly 'printf' you could write a function that saves all registers and retrieves from the top stack position before calling, i.e. you do "push rax; call my_printf" and it "just prints it"
2023-05-17 04:19:11 <veltas      > And it prints in hex to stdout or stderr, quite easy to achieve that in assembly
2023-05-17 04:19:32 <veltas      > That's honestly infinitely easier than using gdb
2023-05-17 07:33:32 <MrMobius    > Not even close. After 20 years of printf debugging, I'll never go back after using gdb
2023-05-17 07:34:05 <MrMobius    > You better save whatever printf trashes too
2023-05-17 07:43:39 <unjust      > i agree. i haven't found anything better than using display/8i $pc and adding some custom commands (like info regs) to be executed (see: help command) everytime a breakpoint is reached
2023-05-17 07:44:31 <unjust      > then stepi through the code of interest to watch what's going on
2023-05-17 08:13:39 <veltas      > MrMobius: Yeah I just said I can save/restore the registers within my debug function
2023-05-17 08:14:01 <veltas      > unjust: I'll have to try out `help command`, sounds useful
2023-05-17 08:14:44 <veltas      > I'm not knocking gdb, I'm just saying sometimes printf is easier, including in assembly
2023-05-17 08:17:36 <veltas      > Although you can't use 'printf' in assembly easily, you can use something similar you write yourself
2023-05-17 08:19:00 <veltas      > I've found out today that Windows' syscall interface is not stable, even between Windows 8 and Windows 10, so you have to link to e.g. kernel32.dll to get anything done
2023-05-17 08:41:35 <unjust      > actually it's hook-stop that you want to redefine if you want to see register state on every debugger "stop" rather than just on each break
2023-05-17 08:41:49 <unjust      > this is more or less what that looks like: https://termbin.com/lzp7
2023-05-17 08:50:16 <veltas      > That's a bit better than using the TUI probably
2023-05-17 08:50:55 <unjust      > personal preference, i guess
2023-05-17 08:51:15 <veltas      > The TUI is cool, but I think most people run into issues with it
2023-05-17 08:51:29 <unjust      > i've also found that a lot of people prefer gdb scripts like gef or peda for an augmented view
2023-05-17 08:51:51 <veltas      > For instance the TUI seems to melt whenever the program under test outputs something
2023-05-17 08:52:13 <veltas      > Which CTRL+L fixes but it's just annoying and wouldn't happen with your thing
2023-05-17 08:52:21 <unjust      > i guess the TUI is in raw mode, and behaves as if the text output is a directive to the terminal?
2023-05-17 08:52:38 <KipIngram   > I've gotten a lot done in early phases of my projects just moving a "terminate and return to OS" word through code I'm looking for a bug in.
2023-05-17 08:53:13 <KipIngram   > If the run cleanly terminates, the terminate call is still "before the problem."  I just nudge it along until I get to the bug first, then dive into whatever word that identified and repeat the process.
2023-05-17 08:53:32 <veltas      > I've gotten a lot done in boot firmware where I could only control one LED and nothing else worked :)
2023-05-17 08:53:37 <KipIngram   > In many cases once I know exactly where the failure point is I cna just study the code and reason out what seems wrong.
2023-05-17 08:53:45 <KipIngram   > Yes.
2023-05-17 08:53:54 <unjust      > i've had issues with contunuously feeding standard input to programs under test in gdb, not just an initial redirection
2023-05-17 08:53:54 <KipIngram   > Creativity will get you a long way.
2023-05-17 08:53:58 <veltas      > If I've got an LED I can blink it at different rates to debug lol
2023-05-17 08:54:16 <KipIngram   > But you're right that just outputting SOMETHING to the screen doesn't have to be a complicated thing.
2023-05-17 08:54:35 <veltas      > Yup
2023-05-17 08:55:37 <unjust      > so i wrote a program to act as tee for standard input to write to a named pipe connected to the slave (gdb in this ) process's stdin - which is the same thing that was interacting with socat for that shell script irc client yesterday
2023-05-17 08:57:01 <unjust      > https://github.com/jhswartz/iix/ - the example in the README shows gdb interaction
2023-05-17 09:25:13 <KipIngram   > I need to tweak my editor just a bit.  Right now I have a word ss that prints the current block to the screen.  I need to modify things a bit so that I can specify starting and ending lines for the printed out range.
2023-05-17 09:25:25 <KipIngram   > Otherwise the block can get too tall for my screen.
2023-05-17 09:25:51 <KipIngram   > Especially given the way I normally chop my screen up into panels.
2023-05-17 10:20:48 <KipIngram   > So, I think I need a new flavor of conditional return.  I've run into this enough times that I think I ought to do something about it.
2023-05-17 10:20:57 <KipIngram   > Say I've got an item on the stack.
2023-05-17 10:21:10 <KipIngram   > I MAY want to do something with it, but only if it passes a particular test.
2023-05-17 10:21:32 <KipIngram   > So I want to test it, and if the test passes, I want the item to still be on the stack, so I can do whatever it is I'm doing with it.
2023-05-17 10:21:54 <KipIngram   > But if the test fails, I want to return, and that needs to REMOVE THE ITEM, so as far as the calling code is concerned something has been done with it.
2023-05-17 10:22:08 <KipIngram   > At the moment I can either leave it or not leave it, but not in an outcome dependent way.
2023-05-17 10:22:30 <KipIngram   > I want a "drop if returning" type operation.
2023-05-17 14:11:29 <vms14       > I don't remember who from here had an interpreter that pushed barewords on the stack
2023-05-17 14:11:53 <vms14       > I like the idea, I worry a bit cause it has to make debugging harder
2023-05-17 14:12:04 <vms14       > but I have a flag to have both behaviors
2023-05-17 14:12:11 <KipIngram   > "barewords"?
2023-05-17 14:12:20 <vms14       > KipIngram: words that not exist
2023-05-17 14:12:27 <vms14       > they usually trigger an error
2023-05-17 14:12:31 <vms14       > I always had this way
2023-05-17 14:12:42 <KipIngram   > Oh, so it treated them as strings to be saved somewhere?
2023-05-17 14:12:50 <vms14       > a guy here told me he had some implementation that pushed them on the stack
2023-05-17 14:12:56 <vms14       > KipIngram: yes
2023-05-17 14:13:22 <vms14       > I worried cause if you have an error like a typo, you can end being crazy
2023-05-17 14:13:41 <KipIngram   > Yeah.
2023-05-17 14:13:45 <vms14       > but I've tried and I like it
2023-05-17 14:13:50 <KipIngram   > No protection against foul ups at all.
2023-05-17 14:13:58 <vms14       > so I have a flag to have both behaviors
2023-05-17 14:14:06 <KipIngram   > A more "Forth like" philosophy would be to have you indicate your strings somehow.
2023-05-17 14:14:12 <KipIngram   > s" bareword" ...
2023-05-17 14:14:25 <KipIngram   > Then s" RUNS and parses an item out of the input.
2023-05-17 14:14:29 <vms14       > if you type no.bareword  will raise an error when compiling or interpreting a word that does not exist
2023-05-17 14:14:42 <KipIngram   > And does with it whatever you've arranged to be able to do.
2023-05-17 14:14:48 <vms14       > oh, I don't want that
2023-05-17 14:14:53 <vms14       > I'll remove it xD
2023-05-17 14:15:00 <vms14       > I don't want this behavior
2023-05-17 14:15:15 <thrig       > SBCL> (read-from-string "lol wtf?? who-writes-this-stuff")
2023-05-17 14:15:33 <vms14       > I like it cause I can type: some text automatically quoted
2023-05-17 14:15:48 <vms14       > but if some of those words exists it will get executed
2023-05-17 14:15:51 <KipIngram   > Now I can say lo hi rr and my editor will limit its printouts to that range.
2023-05-17 14:15:52 <vms14       > it's a messy behavior
2023-05-17 14:16:03 <vms14       > i prefer to quote them explicitly
2023-05-17 14:16:09 <vms14       > 'some 'text
2023-05-17 14:16:20 <KipIngram   > Yes, I think that's best as well.
2023-05-17 14:16:38 <KipIngram   > I wouldn't object too awfully to a forth that would take something like
2023-05-17 14:16:45 <KipIngram   > word word word "literal string" word word
2023-05-17 14:16:47 <KipIngram   > etc.
2023-05-17 14:16:49 <vms14       > KipIngram: what do you do when compiling and a word in that colon definition does not exist?
2023-05-17 14:17:02 <KipIngram   > Now, that's not standard, because it would be recognizing that quoted string as a literal.
2023-05-17 14:17:14 <KipIngram   > " literal string" would be more Forthy.
2023-05-17 14:17:20 <KipIngram   > Where " is an actual word.
2023-05-17 14:17:50 <KipIngram   > But STANDARD Forth really doesn't have any place for you to put those strings.
2023-05-17 14:17:56 <KipIngram   > So you're gonna have to invent that.
2023-05-17 14:18:08 <vms14       > I think when compiling i'll fall back to the interpreter if I can't compile something
2023-05-17 14:18:17 <thrig       > possibly with a fancy autoboxed stack
2023-05-17 14:18:26 <vms14       > manly returning a function that will call the interpreter with that word
2023-05-17 14:19:11 <vms14       > in the past I assumed that word will eventually exist and be compiled, so I returned a function that will use that future compiled version
2023-05-17 14:20:36 <vms14       > you can travel time with references
2023-05-17 14:20:38 <vms14       > it's cool
2023-05-17 14:20:49 <thrig       > yeah they do that in star trek
2023-05-17 14:21:01 <vms14       > in node I made a test and you can have an array that autofills itself over time
2023-05-17 14:21:42 <vms14       > the function returns you an empty array, but over time it fill end being filled
2023-05-17 14:21:50 <vms14       > will*
2023-05-17 14:22:30 <vms14       > a cool feature from closures
2023-05-17 14:24:11 <KipIngram   > vms14: That just kicks the error recovery.
2023-05-17 14:24:26 <KipIngram   > It says <word> not recognized and sends me back to the interpreter.
2023-05-17 14:24:32 <KipIngram   > With my pre-line state restored.
2023-05-17 14:25:13 <vms14       > mine says the same
2023-05-17 14:25:28 <vms14       > error "$atom not recognized";
2023-05-17 14:25:46 <KipIngram   > : foo bar ;  bar: word not recognized
2023-05-17 14:25:46 <vms14       > and the compiler the same + "at compile time"
2023-05-17 14:25:48 <KipIngram   > 
2023-05-17 14:26:05 <KipIngram   > Only on my screen it's red.
2023-05-17 14:26:09 <KipIngram   > For error.
2023-05-17 14:26:21 <KipIngram   > Error output is red.
2023-05-17 14:26:30 <KipIngram   > "System" output (like the ok prompt) is green.
2023-05-17 14:26:41 <KipIngram   > Output from words I write is blue.  Stuff I type is white.
2023-05-17 14:26:48 <vms14       > I had that when playing with colors
2023-05-17 14:26:50 <KipIngram   > Makes for some pretty screens.
2023-05-17 14:26:53 <vms14       > you could set those colors
2023-05-17 14:27:15 <KipIngram   > Certainly - I did set them.
2023-05-17 14:27:26 <KipIngram   > Well, I coded the color choice in.
2023-05-17 14:27:26 <vms14       > colors is the best feature I added to the lang
2023-05-17 14:27:28 <vms14       > xD
2023-05-17 14:27:33 <KipIngram   > I don't have any sort of "editable config."
2023-05-17 14:27:37 <KipIngram   > Other than the source code.
2023-05-17 14:28:10 <vms14       > I had a hash with all colors used for prompt, user printed output, errors, etc
2023-05-17 14:28:30 <vms14       > prompt could also be a colon definition returning a string
2023-05-17 14:29:05 <vms14       > mainly to allow for example if you want to check if you're root and put a '#' like in shell
2023-05-17 14:29:19 <vms14       > or the current dir, etc
2023-05-17 14:29:40 <vms14       > but I have some weird bug with rlwrap now, it echoes the prompt twice
2023-05-17 14:30:27 <vms14       > I don't have a prompt because of that
2023-05-17 14:30:28 <vms14       > xD
2023-05-17 14:30:48 <thrig       > rlwrap was too complicated so I stopped using it
2023-05-17 14:32:04 <vms14       > thrig: what do you use now?
2023-05-17 14:32:26 <vms14       > I see it's a common thing
2023-05-17 14:32:36 <vms14       > https://stackoverflow.com/questions/59007528/double-echo-when-running-commands-under-a-pty
2023-05-17 14:32:46 <thrig       > vi, mostly. granted SBCL doesn't have much of a repl to begin with
2023-05-17 14:33:35 <vms14       > the repl of sbcl is emacs + slime
2023-05-17 14:34:02 <thrig       > I stopped using emacs over 20 years ago now
2023-05-17 14:34:15 <vms14       > it's quite good
2023-05-17 14:34:43 <vms14       > vi is better than emacs once you're used to
2023-05-17 14:35:09 <Zarutian_iPad> 
ACTION hates modal based software

2023-05-17 14:35:34 <vms14       > I just get crazy trying to write emacs in vi
2023-05-17 14:36:04 <vms14       > but with the time you get used and it ends being more efficient
2023-05-17 14:36:15 <vms14       > vi is quite good, and I don't mean vim
2023-05-17 14:36:15 <KipIngram   > Zarutian_iPad: Do I interpret that correctly as saying you prefer emacs over vi?
2023-05-17 14:36:36 <veltas      > I have a lot of respect for the Order of Emacs, to each their own.
2023-05-17 14:36:42 <Zarutian_iPad> yes but barely
2023-05-17 14:36:56 <KipIngram   > I use vim, but I do actually think the emacs approach is slightly preferable.
2023-05-17 14:37:09 <vms14       > I fight a lot with emacs
2023-05-17 14:37:14 <veltas      > It's sad that we don't all consider Forth the best text editor
2023-05-17 14:37:22 <KipIngram   > I shifted to vim because I went through a "tablet phase" and my tablet had a terminal emulator that had vim but didn't have emacs.
2023-05-17 14:37:31 <KipIngram   > And now I'm used to it.
2023-05-17 14:37:34 <vms14       > in vi the only fight is cause I try to use emacs bindings instead
2023-05-17 14:37:39 <Zarutian_iPad> I use pico if I need to use a TUI editor on unix/linux or such I prefer pico
2023-05-17 14:37:44 <KipIngram   > But the way emacs handles keystrokes / control keystrokes is nice.
2023-05-17 14:37:46 <veltas      > You're saying "tablet phase" as if anyone else here has ever used a tablet :P
2023-05-17 14:37:48 <KipIngram   > I think it's a little cleaner.
2023-05-17 14:37:59 <thrig       > pico, I've had to cleanup after other sysadmins who corrupted files with it
2023-05-17 14:38:02 <KipIngram   > Well, I don't use one these days.
2023-05-17 14:38:04 <veltas      > That's a bit like saying "I went through a no-trousers phase"
2023-05-17 14:38:12 <KipIngram   > What I mean by that is that I was trying to make it my primary / only device.
2023-05-17 14:38:16 <thrig       > nano eventually changed the "hard wrap lines by default" thing
2023-05-17 14:38:28 <veltas      > Yeah I am kidding KipIngram, I know what you mean, I tried same thing with my first smartphone
2023-05-17 14:38:33 <veltas      > And my PDA.....
2023-05-17 14:39:01 <veltas      > We're all boomers on the inside
2023-05-17 14:39:09 <vms14       > emacs is good if you want to spend time configuring it
2023-05-17 14:39:16 <Zarutian_iPad> but usually I use tclsh to do various ‘do edit in many files’ kind of thing
2023-05-17 14:39:18 <KipIngram   > I don't fully understand why they never were able to get tablets to a "point of grace."  The other day someone mentioned it just had to do with the community not having open access to the necessary design details.
2023-05-17 14:39:19 <vms14       > that's mainly why I started using it
2023-05-17 14:39:22 <KipIngram   > That's a shame.
2023-05-17 14:39:38 <vms14       > but it turns I'm lazy and I don't want to mess with configuration at the end
2023-05-17 14:39:48 <vms14       > then emacs is not that good :/
2023-05-17 14:40:20 <KipIngram   > I'm lazy too and wind up "underutilizing" tools like emacs or vim.
2023-05-17 14:40:20 <thrig       > emacs is probably to fill in for that missing car up on blocks in the garage
2023-05-17 14:40:31 <vms14       > you can use vi keybinds in emacs with the evil mode
2023-05-17 14:40:34 <KipIngram   > I learn the basics, and a few frills, and just never grow beyond that.
2023-05-17 14:40:46 <vms14       > and if you want you can create another kind, or even edit that evil mode
2023-05-17 14:41:00 <veltas      > I am a proud EDitor, I regularly use ed
2023-05-17 14:41:07 <vms14       > :0
2023-05-17 14:41:14 <veltas      > There are many situations where ed is the easiest thing, I find
2023-05-17 14:41:25 <veltas      > If I want to just whack something at the end of a file I'll ED it
2023-05-17 14:41:48 <veltas      > The fact you can make small changes while keeping the shell all on screen is useful
2023-05-17 14:41:51 <vms14       > the only real problem emacs has is big files
2023-05-17 14:42:06 <vms14       > it will use all your memory because it's fun
2023-05-17 14:42:13 <veltas      > I find emacs sluggish
2023-05-17 14:42:18 <veltas      > emacs has memory issues without large files
2023-05-17 14:42:23 <Zarutian_iPad> I have used cat with heredocs on the terminal to bang in a text file
2023-05-17 14:42:42 <vms14       > vi will use the memory of the current line
2023-05-17 14:42:52 <KipIngram   > That sounds a little like how this editor I've just written works.
2023-05-17 14:42:59 <veltas      > There was an emacs session running on a server at university I seem to remember was always sitting at around 60GB virtual memory usage or something
2023-05-17 14:43:08 <vms14       > I know cause I had the entire bible in a json inside html
2023-05-17 14:43:11 <KipIngram   > It's basically a line editor; I just say ss to "show" periodically to "cat out" the block anew.
2023-05-17 14:43:21 <vms14       > and the bible was one line
2023-05-17 14:43:29 <KipIngram   > ss puts a > marker on the line that is the current edit target.
2023-05-17 14:43:32 <KipIngram   > I can set that with ll
2023-05-17 14:43:41 <vms14       > moving the cursor around that line in vi lagged
2023-05-17 14:43:53 <vms14       > emacs simply couldn't handle it
2023-05-17 14:44:50 <Zarutian_iPad> the most bareably TUI editor I have used is dos edit.exe beleave it or not
2023-05-17 14:45:15 <veltas      > KipIngram: Have you tried the starting forth editor?
2023-05-17 14:45:21 <veltas      > It's surprisingly good
2023-05-17 14:45:48 <KipIngram   > No, I haven't.
2023-05-17 14:46:15 <KipIngram   > Reading about the basic editor in collapseos gave me an appreciation for how well such things can work.
2023-05-17 14:46:27 <KipIngram   > You basically navigated by searching.
2023-05-17 14:46:35 <KipIngram   > I may add that to mine.
2023-05-17 14:46:51 <KipIngram   > ff <word> would set the edit point to the line containing <word>.
2023-05-17 14:47:13 <KipIngram   > But it's not that hard to just say <line #> ll
2023-05-17 14:47:29 <vms14       > I just want to be able to bind keys to words
2023-05-17 14:47:40 <thrig       > aka /word or 42 in ed
2023-05-17 14:47:48 <vms14       > I imagine and I like it in my mind
2023-05-17 14:48:29 <vms14       > but this means curses or making a window manager
2023-05-17 14:48:41 <vms14       > I'd like to do both :D
2023-05-17 14:48:51 <vms14       > the window only if I add ffi to C
2023-05-17 14:49:28 <vms14       > I want to use Xlib with Xshape and xpm.h to have sprites walking on the screen
2023-05-17 14:49:55 <vms14       > they're non rectangular windows changing their form at every frame of the sprite
2023-05-17 14:51:59 <vms14       > but I can't stop rewriting it, now I'm changing the dictionary for environments
2023-05-17 14:52:55 <vms14       > I end implementing both because I want closures and temp bindings
2023-05-17 14:53:09 <vms14       > but I wondered about having just environments
2023-05-17 14:56:22 <veltas      > vms14: Yeah binding keys to words is important for speed when you're not just using an old tty
2023-05-17 14:56:37 <veltas      > KipIngram: That's similar to starting forth's editor, maybe a little more streamlined
2023-05-17 14:57:02 <vms14       > veltas: I meant colon words
2023-05-17 14:57:29 <veltas      > I understood don't worry
2023-05-17 14:57:34 <vms14       > oh
2023-05-17 14:57:56 <vms14       > it makes the whole lang interactive
2023-05-17 14:58:19 <thrig       > really could COLOR you whole experience
2023-05-17 14:58:21 <vms14       > you can have words to expect arguments from a pop up, etc
2023-05-17 14:58:43 <thrig       > or it could beachball the system if you implement it poorly
2023-05-17 14:59:44 <vms14       > [ rm -rf / ] 'control+r bind
2023-05-17 15:03:38 <vms14       > now I want to be able to : word1 : word2 inner word ; word2 ;
2023-05-17 15:03:53 <vms14       > and have word2 defined in the scope of word1
2023-05-17 15:04:27 <vms14       > supposedly with environments I only have to enter into that word environment
2023-05-17 15:04:53 <vms14       > they could end acting as class definitions for an object
2023-05-17 15:05:05 <KipIngram   > veltas: That wouldn't surprise me - I was just looking for the simplest thing that I'd regard as "effective."
2023-05-17 15:05:32 <KipIngram   > And I was starting with an ability to edit one-line RAM buffers anyway, so I just built off of that.
2023-05-17 15:05:57 <KipIngram   > Like, I could say PAD 100 EXPECT to get some data at PAD.
2023-05-17 15:06:13 <KipIngram   > Then I already had things arranged so I could say PAD 100 0 ED
2023-05-17 15:06:21 <KipIngram   > and it would let me edit that earlier entered string.
2023-05-17 15:06:31 <KipIngram   > The 0 being the starting place in the line for the cursor.
2023-05-17 15:07:16 <KipIngram   > All EXPECT really does is OVER OFF 0 ED
2023-05-17 15:09:31 <KipIngram   > Actually it's a bit more than that.  I think ED will return if it gets a keystroke that doesn't relate to editing within a line.
2023-05-17 15:10:05 <KipIngram   > And EXPECT will re-enter ED without losing the data or moving the cursor in those cases, so that EXPECT effectively just ignores such keys.
2023-05-17 15:10:17 <KipIngram   > The idea was to be able to wrap a screen editor around ED, which I haven't quite done.
2023-05-17 15:10:42 <KipIngram   > ED would handle "within a line" and the wrapper would handle vertical motion and other such stuff.
2023-05-17 15:11:14 <KipIngram   > And all that UTF8 stuff I worked through last year is in ED.
2023-05-17 15:11:24 <KipIngram   > And the ANSI sequence support.
2023-05-17 15:11:58 <KipIngram   > It doesn't give me a way to enter such sequences, or delete them, but it will skip the cursor over them if they're there.
2023-05-17 15:12:26 <KipIngram   > The idea being that I could define control keys to insert color and attribute changes and so on.
2023-05-17 15:13:18 <KipIngram   > A one-line memory range editor seems like a reasonable to for a Forth to provide out of the box.
2023-05-17 15:14:00 <KipIngram   > tool
2023-05-17 15:15:52 <KipIngram   > Anyway, this little editor is 24 lines of code, of which 11 are just involved with printing the right range of the block out.
2023-05-17 15:16:01 <veltas      > Nice
2023-05-17 15:16:09 <veltas      > Show us the sauce
2023-05-17 15:17:03 <KipIngram   > https://pastebin.com/XXydk2Bh
2023-05-17 15:18:54 <thrig       > ed(1) meanwhile has been bloated to 2000 lines of C, or so
2023-05-17 15:19:14 <KipIngram   > 768 bytes.
2023-05-17 15:19:56 <KipIngram   > <block #> ed starts it.
2023-05-17 15:20:09 <KipIngram   > The rest of the command are all two repeats of a char.
2023-05-17 15:20:16 <KipIngram   > ii ++ rr etc.
2023-05-17 15:20:50 <KipIngram   > Oh, I left an artifact of abandoned work in there.
2023-05-17 15:20:59 <KipIngram   > Line 14.
2023-05-17 15:21:23 <KipIngram   > I don't think I need that naymore - I had intended at one point to put a conditional return there, but then I shifted gears and forgot to take it out.
2023-05-17 15:22:51 <KipIngram   > so, 23 lines, 750 bytes.  :-)
2023-05-17 15:23:38 <KipIngram   > Lines 6, 7, 17 and 18 are a little long to suit me - I may do a bit of factoring there.
2023-05-17 15:34:59 <vms14       > I have inner words :D
2023-05-17 15:35:15 <vms14       > I just need to enter inside the scope of a word when defining it
2023-05-17 15:35:18 <KipIngram   > You mean words within words?  Local to the outer word?
2023-05-17 15:35:30 <vms14       > yes
2023-05-17 15:35:30 <KipIngram   > I use the .: / .wipe for that.
2023-05-17 15:35:44 <vms14       > : ah : eh 1 2 3 ; eh ;
2023-05-17 15:35:53 <vms14       > eh only exists inside ah
2023-05-17 15:36:16 <vms14       > and has inherits its scope
2023-05-17 15:36:49 <KipIngram   > For me that would create ah and eh both as globally visible.
2023-05-17 15:37:00 <KipIngram   > But I could do : ah .: eh ...
2023-05-17 15:37:14 <KipIngram   > and then .wipe, and eh would no longer be in the dictionary.
2023-05-17 15:37:16 <vms14       > yeah but I don't have packages or dictionaries anymore
2023-05-17 15:37:27 <vms14       > now it's only one environment, which is a hash table
2023-05-17 15:38:32 <vms14       > this environment will change over time, when defining a word we inherit the current env and make a new environment for that word, and make that environment be the current word until we end defining it, then we restore the environment
2023-05-17 15:39:00 <vms14       > as : is an immediate word it will get executed inside : definitions, being recursive by nature
2023-05-17 15:39:28 <vms14       > which will make a chain of creating a new environment for every word definition, inheriting from the outer
2023-05-17 15:39:43 <vms14       > I have to test it btw
2023-05-17 15:40:51 <vms14       > for now that code works fine, the inner word does not exist outside, and has to inherit stuff from the outer
2023-05-17 15:41:15 <vms14       > I don't have setters yet to test that inheritance
2023-05-17 15:41:29 <vms14       > well, the : word
2023-05-17 15:42:06 <vms14       > : ah : oh 1 2 3 ; : eh oh ; eh ;
2023-05-17 15:42:48 <vms14       > eh can access to its sibling words
2023-05-17 15:43:31 <vms14       > this is cooler than having packages
2023-05-17 15:44:02 <vms14       > I already make that fake compiler, but with environments definitions have their own scope
2023-05-17 15:44:08 <vms14       > made*
2023-05-17 15:46:25 <vms14       > compile + remove word would get rid of the inner words, but the compiled version would retain them
2023-05-17 15:46:32 <vms14       > so it kind of works like your wipe
2023-05-17 15:47:38 <vms14       > I've made the "compiler" to fall back to the interpreter when it does not recognize a word
2023-05-17 15:48:32 <vms14       > I could "cache" compiled versions of a word and make the compiler use the future compiled version of a word, instead of falling back to the interpreter
2023-05-17 15:49:00 <vms14       > but this assumes every non recognized compiled atom will be a compiled word when this word executes
2023-05-17 15:50:18 <vms14       > the compiler returns functions so the fallback is literally: return sub { interpret_element $atom }
2023-05-17 15:50:46 <vms14       > it's a dirty defer
2023-05-17 15:54:29 <KipIngram   > So <block #> ed starts the editor - it just sets up a set of state variables on the stack.  Then the 2-letter commands presume that to be there and work with it.  So I can't put anything else on the stack while editing.
2023-05-17 15:54:41 <KipIngram   > I can use it, but have to clean it off again before the next edit command.
2023-05-17 15:54:57 <vms14       > KipIngram: are you starting to make your text editor?
2023-05-17 15:55:14 <vms14       > which means that cool feature
2023-05-17 15:55:14 <KipIngram   > That state is <low line> <high line> <buffer addr> <line addr>
2023-05-17 15:55:27 <KipIngram   > This is a preliminary editor.
2023-05-17 15:55:39 <vms14       > a prototype
2023-05-17 15:55:41 <KipIngram   > It's enough to work with, but it's not "that" editor.
2023-05-17 15:55:49 <thrig       > prelineinary
2023-05-17 15:56:06 <KipIngram   > But I am about to start working on the meta-compilation stuff.
2023-05-17 15:59:49 <KipIngram   > There are several levels involved here.  There's the "portability layer," then primitives defined using that, then Forth words defined using those primitives (by the meta compiler) and finally further Forth source compiled by the target system itself.
2023-05-17 16:00:21 <KipIngram   > I want the first of those to be the only thing that would have to be "redone" to support a new platform.
2023-05-17 16:00:30 <vms14       > for a start don't even care about the portability layer
2023-05-17 16:00:45 <vms14       > well, it could change the whole thing
2023-05-17 16:00:46 <KipIngram   > On the contrary - it's the first thing I want to work out.
2023-05-17 16:01:13 <KipIngram   > It's been bobbing around in my subconscious for years - I need to get it nailed down.
2023-05-17 16:01:18 <vms14       > :0
2023-05-17 16:01:53 <KipIngram   > The idea is for it to be a vm that maps well onto multiple instruction sets, and that is capable of defining all the primitives I want.
2023-05-17 16:02:25 <KipIngram   > Now that I've actually got an ARM platform I can code on that should help.
2023-05-17 16:03:05 <KipIngram   > I'll at least be able to use that to hand-code a few primitives and make sure that the metacompiler is generating the right byte sequence.
2023-05-17 16:03:38 <KipIngram   > And ideally maybe I'll write that layer for both and then keep tabs that the rest is working in both places.
2023-05-17 16:04:42 <vms14       > how will the vm map welll into multiple instruction sets?
2023-05-17 16:05:10 <KipIngram   > That's the puzzle, isn't it?  Ok, so let me explain it just using the notions of RISC and CISC.
2023-05-17 16:05:41 <KipIngram   > On a CISC processor, I want to take advantage of the instructions greater ability.  But on RISC, I will need to respect the limited capability of the RISC instructions.
2023-05-17 16:05:56 <KipIngram   > So I see doing this using macros, some of which may be EMPTY on the CISC platform.
2023-05-17 16:06:11 <vms14       > oh, having alternate versions
2023-05-17 16:06:17 <vms14       > like a bunch of if cases
2023-05-17 16:06:32 <KipIngram   > So to do + for example, on a CISC machine it might just be add reg [memory]
2023-05-17 16:06:35 <vms14       > like a macro could have a dual behavior
2023-05-17 16:06:49 <vms14       > then it's mostly all written with macros
2023-05-17 16:06:58 <KipIngram   > But on RISC it will need to be mov <scratch reg>, [memory]; add <reg>, <scratch reg>
2023-05-17 16:07:29 <KipIngram   > So the macro sequence will probably look like that RISC instruction stream - two macros - but the first one will be empty on the CISC design and the second one will do it all.
2023-05-17 16:07:37 <KipIngram   > That kind of thing.
2023-05-17 16:07:49 <KipIngram   > I don't know the details yet - I've got to firm it up.
2023-05-17 16:08:54 <KipIngram   > And I don't necessarily expect "perfect" efficiency - I just want to wind up feeling like I'm "fairly close" to an optimum arrangement on most platforms.
2023-05-17 16:12:07 <vms14       > I assume the whole goal of the metacompiler is to bootstrap itself as much as possible
2023-05-17 16:12:30 <vms14       > after all a metacompiler automates the process of writing several implementations
2023-05-17 16:12:51 <vms14       > so the more it bootstraps itself, the more can automate
2023-05-17 16:13:48 <vms14       > the goal is to reduce your effort, compared if you had to write all those versions. I assume
2023-05-17 16:14:19 <vms14       > say instead of writing the primitives in every platform/lang/arch
2023-05-17 16:15:08 <vms14       > I saw some metacompilers which asked for some kind of language specification denoted in their own language, and a program written in it
2023-05-17 16:15:18 <vms14       > but meh
2023-05-17 16:15:28 <vms14       > I have to dig on all this stuff
2023-05-17 16:16:52 <vms14       > I also had some interest in awk, cause I see a lot of power in awk + shell metaprogramming
2023-05-17 16:17:12 <vms14       > awk can generate programs based on input and sh can generate awk programs to manage input
2023-05-17 16:18:02 <vms14       > but after all, perl is awk without the need of the shell to be a proper language + the shell features
2023-05-17 16:18:30 <vms14       > if I use awk I'll end implementing something perl already is
2023-05-17 16:20:22 <vms14       > anyways it served me to realize how useful awk can be, so I can add some way to autogenerate simple awk programs in my lang
2023-05-17 16:21:52 <KipIngram   > Yes, that's right.  I want a relatively small amount of portability stuff that has to be outright written for each platform, and the rest I want to port right over.
2023-05-17 16:22:31 <vms14       > KipIngram: but how to provide that more than writing macros?
2023-05-17 16:22:52 <KipIngram   > It will just be macros, basically.  I just need to choose them carefully.
2023-05-17 16:23:08 <vms14       > and then macros on top of macros
2023-05-17 16:23:24 <KipIngram   > It would be easy to "just do it," but doing it in a way that results in "close to best" resource efficiency across platforms is the challenge.
2023-05-17 16:23:26 <vms14       > creating a whole layer of macros and using only them
2023-05-17 16:23:38 <KipIngram   > Yes, using them to implement the primitives.
2023-05-17 16:23:56 <KipIngram   > Because I have a lot of primitives, and I don't want to have to re-write all of them every time.
2023-05-17 16:24:01 <vms14       > I can't think of other way
2023-05-17 16:24:17 <KipIngram   > That is the way - I don't know what you mean by "other way."
2023-05-17 16:24:35 <vms14       > I need to get a general idea I suppose
2023-05-17 16:24:49 <vms14       > invest time researching and thinking
2023-05-17 16:25:08 <KipIngram   > Maybe in a few days I'll be able to show you some samples and it will help.
2023-05-17 16:25:48 <vms14       > making tests is how I learn
2023-05-17 16:26:13 <vms14       > I have to add ffi to C some day
2023-05-17 16:26:33 <vms14       > at least now I've changed packages for environments and I'm more happy
2023-05-17 16:26:49 <vms14       > I'm making a lisp with forth syntax
2023-05-17 16:26:53 <vms14       > :D
2023-05-17 16:27:03 <vms14       > a lifp
2023-05-17 16:28:51 <KipIngram   > Once I caught on to how simple a lisp system could be I started thinking about putting one "alongside" a Forth, in a separate RAM region, and arranging for Forth to be able to pump strings into and out of it.
2023-05-17 16:30:56 <KipIngram   > You did see what I was talking about on the + example, right?
2023-05-17 16:31:47 <KipIngram   > There would be a "prepare" macro that moved the second stack item into a scratch register on the RISC machine and did nothing on the CISC machine.
2023-05-17 16:32:26 <vms14       > "two macros - but the first one will be empty on the CISC design and the second one will do it all."
2023-05-17 16:32:27 <KipIngram   > Then a "finish +" macro that added the scratch reg to the top of stack reg on the RISC machine and added the second stack item directly from RAM on the CISC machine.
2023-05-17 16:32:47 <KipIngram   > Then on either platform the sequence  "prepare" "finish" would get the addition done.
2023-05-17 16:33:03 <KipIngram   > But on the CISC machine it would create fewer instructions.
2023-05-17 16:33:21 <vms14       > what if you wanted to support more archs?
2023-05-17 16:33:34 <vms14       > and what register would you use
2023-05-17 16:33:49 <KipIngram   > That's the thing - it would certainly help to know what those all were in advance.  But I can't know every single one.
2023-05-17 16:33:54 <vms14       > I'd make macros for registers
2023-05-17 16:34:11 <KipIngram   > It would port to any architecture, but whether or not it produced "nice" results on all of them is another matter.
2023-05-17 16:34:21 <KipIngram   > But CISC and RISC is a major category division.
2023-05-17 16:34:26 <vms14       > say for example linux and bsd use different registers, even if the same instruction set
2023-05-17 16:34:31 <KipIngram   > So that's at least going to get me closer to my goal.
2023-05-17 16:34:44 <KipIngram   > And yes, these portability macros would have the register assignments baked into them.
2023-05-17 16:35:00 <vms14       > then I'd have to specify the register I want to operate for +
2023-05-17 16:35:21 <vms14       > and assing a register on every platform to be used for that
2023-05-17 16:35:28 <vms14       > assign*
2023-05-17 16:35:37 <KipIngram   > No, there will be a "top of stack" register and an IP register and a stack pointer register and a return stack pointer register and so on.
2023-05-17 16:35:53 <KipIngram   > The macros will just use the right ones - the primitives themselves won't see those details.
2023-05-17 16:36:23 <vms14       > so you're essentially writing an assembly language on top of macros?
2023-05-17 16:36:30 <KipIngram   > Well, there will have to be a speciic register used for this "fetch value from memory" operation on all RISC machines, but CISC machines wouldn't need that.
2023-05-17 16:37:57 <KipIngram   > In my nasm implementation I have a set of #defines that do that.
2023-05-17 16:38:11 <KipIngram   > In my primitives I reference t hings like rrTOS, rrIP, rrSP, etc.
2023-05-17 16:38:25 <KipIngram   > They're aliased to some particular choice of processor registers.
2023-05-17 16:38:51 <KipIngram   > I went a little way down this road that time already - I do have macros that carry out certain operations.
2023-05-17 16:38:59 <KipIngram   > It's just not "complete."
2023-05-17 16:39:51 <vms14       > that's why I wondered about writing an assembler that actually generates code
2023-05-17 16:40:45 <vms14       > but llvm assembly seems to do that for you already
2023-05-17 16:45:23 <vms14       > brv
2023-05-17 16:49:13 <KipIngram   > I'm thinking I can probably arrange that once I have code compiled in a target system I can do a far call from my running system into that image.  Save the registers, do a far call, restore the registers and carry on.
2023-05-17 16:49:41 <KipIngram   > The image code will of course set all the registers up in its own way, but they'll get restored.  So I'm hoping I can launch and test this as I go along.
2023-05-17 16:49:55 <KipIngram   > When I "quite" from the image, it'll just do a far return.
2023-05-17 16:50:15 <KipIngram   > I don't use rsp, so the system stack is available as a place to save things in cases like this.
2023-05-17 19:36:26 <KipIngram   > You know, those lines I listed as being a little longer than I liked - they're actually not.  They're fine.  I'm just used to seeing them flush with the left margin, and the formatting of the editor made them see longer to me.
2023-05-17 19:36:40 <KipIngram   > But the longest one is actually just 43 characters, and I'm completely happy with that.
2023-05-17 19:38:50 <KipIngram   > I do see four definitions, though, that I ended with "me ;" - those should all be me [ instead.
2023-05-17 19:39:45 <KipIngram   > I actually should just modify my definition of ; so that it doesn't compile the return if the thing just before it is "me."
2023-05-17 19:40:06 <vms14       > I think it was a good choice to have environments instead of a dictionary
2023-05-17 19:40:28 <vms14       > I don't see a drawback, only benefits
2023-05-17 19:40:39 <KipIngram   > I don't even know what you mean.
2023-05-17 19:40:54 <KipIngram   > I think of an environment as "name / value pairs."
2023-05-17 19:41:01 <KipIngram   > And that's really what a dictionary is, too.
2023-05-17 19:41:15 <vms14       > yes, they're mostly the same thing
2023-05-17 19:41:25 <vms14       > but an environment is the definition of a scope
2023-05-17 19:41:25 <KipIngram   > Except a dictionary has a sequence, and you need that for some things.
2023-05-17 19:41:37 <vms14       > if you have environments you have lisp's let
2023-05-17 19:42:11 <vms14       > those can inherit from other environments just by being defined/created inside them
2023-05-17 19:42:36 <vms14       > that's why now words are able to get inner words, closures, etc
2023-05-17 19:42:54 <vms14       > now a word can be inside another and reach their siblings
2023-05-17 19:43:12 <vms14       > it's kind of a package, but I see them different
2023-05-17 19:43:32 <vms14       > I only have one variable for the environment, instead of several packages
2023-05-17 19:43:58 <vms14       > that variable gets changed and restored several times
2023-05-17 19:44:03 <KipIngram   > Meh.  Too computer sciency for me.
2023-05-17 19:44:05 <vms14       > an environment is temporary
2023-05-17 19:45:02 <vms14       > it's lexical scope mainly
2023-05-17 19:45:06 <KipIngram   > You're thinking of an entirely different class of applications from me.  And that's fine, of course.
2023-05-17 19:45:28 <vms14       > sorry, I'm making a lisp in disguise
2023-05-17 19:45:36 <KipIngram   > :-)
2023-05-17 19:45:42 <KipIngram   > I think a lisp would be fun to make.
2023-05-17 19:45:53 <KipIngram   > A simple one, at least - it sounds like the optimizations can get involved.
2023-05-17 19:45:54 <vms14       > every iteration goes closer to lisp and far away from forth
2023-05-17 19:46:24 <vms14       > from the moment I implemented lists
2023-05-17 19:46:46 <vms14       > you can take them as a sequence of words to evaluate and you have macros
2023-05-17 19:47:26 <vms14       > : oh 1 2 3 ;  => [ 1 2 3 ]
2023-05-17 19:47:45 <vms14       > eval would evaluate that list
2023-05-17 20:48:31 <vms14       > I think I'll add a debug/testing flag and start some kind of warnings and checks
2023-05-17 20:52:09 <vms14       > I have a debug and a trace flag
2023-05-17 21:17:12 <vms14       > oh
2023-05-17 21:17:27 <vms14       > interpret_string("0 1 1000000 range '+ do.list .");  takes now 2.78 real
2023-05-17 21:18:36 <vms14       >   2.04 real if I add compile on that code
2023-05-17 21:18:46 <vms14       > interpret_string("0 1 1000000 range '+ compile do.list .");
2023-05-17 21:19:14 <vms14       > the only difference between the last benchmarked implementation is the environments instead of packages
2023-05-17 21:24:03 <vms14       > keep having that performance overhead by words
2023-05-17 21:24:17 <vms14       > 0 1 1000000 range [ 1 2 3 drop drop drop + ] do.list .
2023-05-17 21:24:22 <vms14       > takes 17 seconds
2023-05-17 21:24:27 <vms14       > compiled takes 4
2023-05-17 21:38:15 <KipIngram   > : adder  swap over + swap 1- .0>me drop . ;  ok
2023-05-17 21:38:17 <KipIngram   > : usec  uet 1000000 * + ;  ok
2023-05-17 21:38:19 <KipIngram   > usec 0 1000000 adder usec swap - . 500000500000 13835  ok
2023-05-17 21:38:31 <KipIngram   > 13.8 milliseconds.
2023-05-17 21:39:22 <KipIngram   > So that's roughly 13.8 nanoseconds per pass through the loop.
2023-05-17 21:54:54 <KipIngram   > Oh, this is better:
2023-05-17 21:54:56 <KipIngram   > : (adder)  dup s1 +! 1- .0>me ;  ok
2023-05-17 21:54:58 <KipIngram   > : adder  { (adder) 1 } ;  ok
2023-05-17 21:55:00 <KipIngram   > 0 1000000 adder . 500000500000  ok
2023-05-17 21:55:02 <KipIngram   > usec 0 1000000 adder . usec swap - . 500000500000 5576  ok
2023-05-17 21:55:20 <KipIngram   > Eliminates all the stack noodling.
2023-05-17 21:55:24 <KipIngram   > Well, almost all of it.
2023-05-17 21:57:58 <vms14       > amazing
2023-05-17 21:58:14 <vms14       > I'll never be able to compete with that
2023-05-17 21:58:28 <vms14       > I just hope the performance is enough for my needs
2023-05-17 21:58:49 <KipIngram   > Well, you're doing something different.  You'd be able to do thinkgs it would take me weeks or months to even be able to approach, because you've got a lot more framework.
2023-05-17 21:59:19 <KipIngram   > My Forth is actually not particularly impressive as Forths go speed-wise.
2023-05-17 21:59:20 <vms14       > colon definitions are not cheap in this language and this makes the feature I want the most from forth go away
2023-05-17 21:59:26 <KipIngram   > Being indirect threaded and all.
2023-05-17 21:59:37 <vms14       > I can't encourage refactoring if colon words are expensive
2023-05-17 22:00:09 <KipIngram   > When I was tinkering with the FPGA Forth, I was very happy that returns imposed no time cost.
2023-05-17 22:00:25 <KipIngram   > The hardware "saw them coming" in the instruction stream and just got ready to go to where it needed to go.
2023-05-17 22:00:48 <vms14       > well the language is just slow
2023-05-17 22:00:52 <KipIngram   > Calls took one clock cycle, and returns none.
2023-05-17 22:01:04 <vms14       > I don't think not factoring would add any overhead after all
2023-05-17 22:01:28 <KipIngram   > Unwinding calls and loops usually speeds things up.
2023-05-17 22:01:30 <vms14       > I have to test how much adds
2023-05-17 22:01:40 <KipIngram   > Processors love to just tear through linear code.
2023-05-17 22:01:46 <vms14       > KipIngram: I've just implemented tco in a very dirty way
2023-05-17 22:02:14 <vms14       > I expect a list of code and turn it into a loop
2023-05-17 22:02:41 <vms14       > the loop is like: while (recurse) { recurse = 0; interpret(code) }
2023-05-17 22:03:05 <vms14       > there's a RECURSE word that turns that flag to 1
2023-05-17 22:03:22 <vms14       > so if recurse gets executed the flag is 1 and the loop continues
2023-05-17 22:03:27 <vms14       > xD
2023-05-17 22:04:21 <vms14       > I think if I were able to get the remainder of the word execution before starting the recursion loop, I could provide this optimization for recursion that is not tail call
2023-05-17 22:04:43 <vms14       > the stack already has the return values, so I just need to execute the remainder
2023-05-17 22:04:56 <vms14       > but I'm not able to get the remainder
2023-05-17 22:07:00 <KipIngram   > Hmmm.  I ought to put that  little test into a loop and gather statistics on how long it takes.  Run it a few thousand times and get the mean and standard deviation.
2023-05-17 22:08:45 <vms14       > your forth looks like a hard to master language
2023-05-17 22:09:10 <vms14       > I assume it will be an adventure for any forthwright
2023-05-17 22:09:23 <vms14       > I mean it has a lot of cool concepts
2023-05-17 22:09:35 <KipIngram   > But it deviates from the standard fare a bit.
2023-05-17 22:09:44 <vms14       > yeah, that's why
2023-05-17 22:10:06 <KipIngram   > Although, not really in so many ways - it just has a few concepts like conditional return / recurse and stack frames that aren't common.
2023-05-17 22:10:15 <vms14       > they'll see your forth and won't find the IF word
2023-05-17 22:10:15 <KipIngram   > But none of those are particularly hard to learn.
2023-05-17 22:10:24 <KipIngram   > It would just take time to get comfortable programming with them.
2023-05-17 22:10:31 <KipIngram   > It's a different "style."
2023-05-17 22:10:36 <vms14       > not hard to learn, but to master
2023-05-17 22:10:42 <KipIngram   > That's fair.
2023-05-17 22:10:48 <vms14       > as you're opening a lot of different ways to do stuff
2023-05-17 22:11:22 <vms14       > I mainly mean that is a language with a lot of concepts to explore
2023-05-17 22:11:31 <vms14       > and more "profound" than what it seems
2023-05-17 22:11:39 <vms14       > my english sucks and I do what I can :D
2023-05-17 22:12:17 <KipIngram   > I suspect that some of it would draw a lot of criticism, particularly from "purist" types.  The way I wire control structures vertically up and down the call tree would likely just make some people want to pull their hair out.
2023-05-17 22:12:37 <KipIngram   > Especially when I start sprinkling in double returns.
2023-05-17 22:12:41 <vms14       > you're the first one who has to like the language
2023-05-17 22:13:00 <vms14       > some people will like it, some not
2023-05-17 22:13:07 <vms14       > a lot could learn from it
2023-05-17 22:13:19 <KipIngram   > There's one double return in that editor code I posted earlier.
2023-05-17 22:14:19 <KipIngram   > It's in the word that puts the > on the active line.  If it doesn't emit the >, it returns, and the caller outputs a space before it returns.
2023-05-17 22:14:34 <KipIngram   > But if it does emit the >, it double returns, so that it skips over that space.
2023-05-17 22:14:40 <KipIngram   > Keeps everything lined up.
2023-05-17 22:16:09 <vms14       > mine is quite a standard lang with a weird syntax implemented in the dirtiest way possible
2023-05-17 22:16:21 <vms14       > but the features are quite common
2023-05-17 22:16:31 <KipIngram   > I haven't quite grokked your syntax yet.
2023-05-17 22:16:53 <vms14       > it's mainly lists as code
2023-05-17 22:16:57 <KipIngram   > And your choice of example word names (eh oh and so on) is fun.
2023-05-17 22:17:13 <vms14       > oh and meh are my foo and bar
2023-05-17 22:17:20 <KipIngram   > Yes.
2023-05-17 22:17:48 <vms14       > but yeah that eh oh was misleading
2023-05-17 22:18:00 <vms14       > if I keep rewriting it for a while I could document it
2023-05-17 22:18:12 <vms14       > I have to make some tool for documenting stuff
2023-05-17 22:19:00 <vms14       > still it gets quite unreadable when I start generating words
2023-05-17 22:19:06 <KipIngram   > Kind of like how apl uses ⍵ and ⍺ as "standard parameters."
2023-05-17 22:19:43 <vms14       > I have weird symbols to do very weird things
2023-05-17 22:20:08 <vms14       > $ wrapped a string into double quotes
2023-05-17 22:20:17 <KipIngram   > I played a trick in that editor code that even I didn't really like much.  There's one place where I have nested stack frames.  And that's fine - but normally in the inner frame you don't need any of the outer frame items.
2023-05-17 22:20:30 <vms14       > that's cause the interpreter reads by words, but also evaluates lists
2023-05-17 22:20:39 <KipIngram   > But in this case I did, and in the INNER frame those items have different names than they do in the outer frame.
2023-05-17 22:20:48 <vms14       > when interprets "  this word is who pushes the string on the stack
2023-05-17 22:21:00 <KipIngram   > If the inner frame adds two  new items to the stack, then what used to be, say, s1 in the outer frame now becomes s3 in the inner frame.
2023-05-17 22:21:01 <vms14       > but inside a list " is an immediate word that returns a string
2023-05-17 22:21:11 <KipIngram   > And that's nto exactly "friendly."
2023-05-17 22:21:16 <KipIngram   > not
2023-05-17 22:21:23 <vms14       > if I just push it on the list and it's going to be evaluated, the string will be interpreted as a word
2023-05-17 22:22:08 <vms14       > when the list building function finds a '"' word executes and wraps it with double quotes
2023-05-17 22:22:17 <vms14       > it quotes the string
2023-05-17 22:22:33 <vms14       > same as 'word
2023-05-17 22:23:10 <vms14       > yeah it's all super weird xD
2023-05-17 22:23:12 <KipIngram   > I'm kind of pleased, though, with the way using a stack frame sped that add-up test by over a factor of two.
2023-05-17 22:24:37 <vms14       > KipIngram: so you made some kind of closure?
2023-05-17 22:24:46 <vms14       > I assume your stack frames are kind of a scope
2023-05-17 22:24:53 <KipIngram   > You know, I'm still not sure what a closure is.
2023-05-17 22:25:05 <vms14       > and you mainly said you were getting stuff from the outer scope
2023-05-17 22:25:17 <KipIngram   > I think of the stack frame not in some formal way, but just as a register designating a memory range that I can index off of.
2023-05-17 22:25:56 <vms14       > a closure is a function that retains variables from the outer scope
2023-05-17 22:26:00 <KipIngram   > { just copies the stack pointer into the "frame pointer."
2023-05-17 22:26:05 <vms14       > it's similar to a static variable in C
2023-05-17 22:26:10 <KipIngram   > And s0 s1 s2 ... index off of the frame pointer.
2023-05-17 22:26:35 <KipIngram   > The stack pointer may continue to change as I do stuff, but the frame pointer holds that value until I close the frame (or open another one inside).
2023-05-17 22:26:46 <vms14       > function make_closure () { a = 3; return function () { print a } }
2023-05-17 22:27:02 <vms14       > make_closure returns a function that can access that a=3
2023-05-17 22:27:24 <KipIngram   > Why is that preferable to just having a=3 be accessible?
2023-05-17 22:27:29 <KipIngram   > I mean, as a variable holding a value.
2023-05-17 22:27:38 <KipIngram   > What do I get for it?
2023-05-17 22:28:06 <vms14       > for encapsulation, or to retain values
2023-05-17 22:28:20 <vms14       > it has a lot of uses
2023-05-17 22:28:50 <vms14       > for example in node you can have a function that returns you an empty array
2023-05-17 22:28:57 <KipIngram   > The stack frame just lets me treat some selected part of the stack as an array, basically.
2023-05-17 22:29:03 <vms14       > and one second later youu examine that array and has elements on it
2023-05-17 22:29:14 <KipIngram   > s0 is frame_pointer[0], s1 is frame_pointer[1], etc.
2023-05-17 22:29:30 <vms14       > that is because the function had closures that could access this array and push elements to it
2023-05-17 22:29:38 <vms14       > even functions called over time
2023-05-17 22:29:38 <KipIngram   > s0 etc - those are just hard coded to specific indices so that I don't have to do that arithmetic at runtime.
2023-05-17 22:30:14 <KipIngram   > So, for example, if you want to thnk through it, one COULD do these:
2023-05-17 22:30:34 <KipIngram   > : dup  { s0 @ -1 } ;
2023-05-17 22:30:42 <KipIngram   > : over  { s1 @ -1 } ;
2023-05-17 22:30:45 <KipIngram   > etc.
2023-05-17 22:31:01 <KipIngram   > I dont do that of course, but they would have the expected effect.
2023-05-17 22:31:02 <vms14       > I'll call them surprise arrays
2023-05-17 22:31:20 <vms14       > they come empty but later you look and... surprise
2023-05-17 22:31:58 <vms14       > so yeah, closures can give you surprise arrays
2023-05-17 22:32:10 <vms14       > a simple example of a closure is a parser or reader
2023-05-17 22:32:58 <vms14       > could return a function that when executes returns the next character, or token
2023-05-17 22:33:48 <vms14       > function reader (string) { return function () { return string[i++] } }
2023-05-17 22:33:55 <KipIngram   > } first sets the stack pointer back to the frame pointer (meaning back to what the stack pointer was on {) but then drops some additional items - however many the number before } says.
2023-05-17 22:34:22 <KipIngram   > So { ... -1 } winds up adding one extra item to the stack.
2023-05-17 22:34:45 <KipIngram   > Usually I use that to drop parameters coming into the frame.
2023-05-17 22:34:59 <KipIngram   > But it can go either way - negative numbers add items.
2023-05-17 22:35:50 <KipIngram   > I don't think I've ever actually done that in any real code, t hough.
2023-05-17 22:42:29 <KipIngram   > My way of thinking of most of these things is more hardware related than "computer science theoretic."
2023-05-17 22:44:07 <KipIngram   > I need to add a line stack to the editor.
2023-05-17 22:44:36 <KipIngram   > Add cc to copy the current line to that stack, and pp to paste in at the insert point.
2023-05-17 22:44:52 <KipIngram   > So I can re-arrange lines - right now I can delete them but new ones I have to re-type.
2023-05-17 22:45:42 <KipIngram   > That was really easy to do when I had 64 64-car lines.
2023-05-17 22:46:14 <KipIngram   > cc will be a fairly straightforward mod of line delete, but pp will involve some work.
2023-05-17 22:46:38 <KipIngram   > I'll have to count how long the line is to know how big an opening to open up, etc.
2023-05-17 22:47:05 <KipIngram   > Also, I haven't looked really closely at the end of my edited blocks.  There are a variety of off-by-one errors that can happen there.
2023-05-17 22:47:31 <KipIngram   > I know I'm not pushing bytes into block 2 when I insert into block 1.
2023-05-17 22:47:50 <KipIngram   > Because I have stuff in block two, and any overrun at all would have made block 2 uncompilable.
2023-05-17 22:48:10 <vms14       > I assume closures only make sense if you have a gc
2023-05-17 22:48:14 <KipIngram   > But I could potentially be pulling bytes in from block two when I delete from block 1.
2023-05-17 22:48:27 <KipIngram   > I wouldn't know, because it's way out there beyond the null that terminates block 1 content.
2023-05-17 22:48:30 <vms14       > if you manage memory directly you don't care about this stuff
2023-05-17 22:48:55 <KipIngram   > I do intend to add memory management in the new system.
2023-05-17 22:49:23 <KipIngram   > http://f4bb1t.com/post/2020/12/12/doug-leas-memory-allocatordlmalloc-basics/
2023-05-17 22:49:36 <vms14       > I stole a book about making gc
2023-05-17 22:50:21 <vms14       > https://gchandbook.org/
2023-05-17 22:50:37 <KipIngram   > Ah, the last byte of block 1 is still zero.
2023-05-17 22:50:46 <vms14       > as if I had to do it in C I'll need a gc
2023-05-17 22:50:50 <KipIngram   > Probably means I'm not moving any stray content in from block 2.
2023-05-17 22:50:58 <vms14       > and this is why I won't do it in C :D
2023-05-17 22:51:37 <vms14       > the book is good btw
2023-05-17 22:51:42 <KipIngram   > So the next question is, am I respecting the last byte in the block?  Or am I failing to move it.  I can set it to some byte and then delete a line and make sure it moves down.
2023-05-17 22:51:56 <vms14       > it shows you the different ways to implement a gc, and how
2023-05-17 22:52:56 <vms14       > for example a mark and sweep will traverse the whole dictionary and mark all cells it finds as alive, recursively
2023-05-17 22:53:08 <vms14       > then will remove everything that is not marked
2023-05-17 22:57:27 <KipIngram   > Yeah, it looks like delete is only moving up through one byte two few downward.
2023-05-17 22:58:01 <KipIngram   > I'm  not horribly worried about it.  The error to avoid is going the other way - I definitely do not want to push the last byte out of the block.
2023-05-17 22:58:10 <KipIngram   > And into the next one, which immediately follows.
2023-05-17 22:58:34 <vms14       > you should respect bytes, even if they're the last ones
2023-05-17 22:58:50 <vms14       > they deserve some respect
2023-05-17 22:59:07 <vms14       > which reminds me I have no respect for them
2023-05-17 22:59:10 <KipIngram   > :-) It's because I'm using the same count to shift upward and downward.
2023-05-17 22:59:51 <KipIngram   > You really want to use one byte too few for the up shift (when inserting one byte), and exactly the right number when down-shifting.
2023-05-17 23:00:09 <KipIngram   > The "easy" change here would break it in the other direction while fixing it in this direction.
2023-05-17 23:00:26 <KipIngram   > I need a 1+ in dd.
2023-05-17 23:00:41 <vms14       > KipIngram: what happens in your forth if you exceed the limit on numbers?
2023-05-17 23:01:29 <vms14       > you try to do some workarounds to work with big numbers?
2023-05-17 23:06:47 <vms14       > KipIngram: do you have any hint to make money trough programming, more than getting hired for writing javs or php?
2023-05-17 23:06:59 <vms14       > through*
2023-05-17 23:07:49 <vms14       > I can only think of making some website and put adds, or to offer some sort of service, like hosting or vps
2023-05-17 23:07:57 <vms14       > ads*
2023-05-17 23:08:19 <vms14       > I want to try making a blogging platform
2023-05-17 23:11:33 <KipIngram   > It wraps.
2023-05-17 23:11:50 <vms14       > why did chuck hate CASE?
2023-05-17 23:11:54 <KipIngram   > I experimented with catching overflow signals, but didn't keep it.
2023-05-17 23:12:00 <vms14       > what does he use instead
2023-05-17 23:12:31 <vms14       > I always remember he hates it when I'm going to implement it xD
2023-05-17 23:12:43 <KipIngram   > Probably a calculated jump table or something.
2023-05-17 23:13:23 <vms14       > I guess it's just he dislikes to go high level unless it's problem oriented
2023-05-17 23:13:38 <KipIngram   > Yeah, he always is for the simpler colutions.
2023-05-17 23:13:40 <vms14       > I mean, maybe he might like a specialized case built for the problem it's going to solve
2023-05-17 23:13:40 <KipIngram   > solutions
2023-05-17 23:14:15 <vms14       > or maybe he just prefers another way that wouldn't require that
2023-05-17 23:15:07 <vms14       > I was going to add even a regex case xD
2023-05-17 23:15:11 <vms14       > and lisp's cond
2023-05-17 23:15:53 <vms14       > cond requires me to implement a proper 'equal'
2023-05-17 23:16:21 <vms14       > able to compare strings, hashes, lists, and optionally objects
2023-05-17 23:17:00 <vms14       > does not require it, but it's better that way
2023-05-17 23:17:24 <vms14       > cond is just a switch case with tests being evaluated
2023-05-17 23:17:58 <vms14       > if the test returns true, the code on that cond case gets executed
2023-05-17 23:18:31 <vms14       > if two conds compare different values using equal without checking the type perl will complain
2023-05-17 23:19:13 <vms14       > equal comparing any type makes it to not complain, and lets me compare lists and hashes
2023-05-17 23:19:40 <vms14       > KipIngram: what do you use instead of CASE?
2023-05-17 23:19:56 <vms14       > you don't even have that word, do you?
2023-05-17 23:27:00 <KipIngram   > No, I don't have anything really.  I can do stuff like this, though:
2023-05-17 23:27:19 <KipIngram   > : foo  choose option1 option2 option3 ... ;
2023-05-17 23:27:28 <KipIngram   > choose will pick one fo the following items.
2023-05-17 23:27:34 <KipIngram   > And they'd all look like this:
2023-05-17 23:27:45 <KipIngram   > : option1 ... ;;
2023-05-17 23:28:01 <KipIngram   > Note the double return, so that after option1 runs it won't return back to foo - it will return to foo's caller.
2023-05-17 23:28:21 <KipIngram   > So it's a simple table jump.
2023-05-17 23:29:05 <KipIngram   > : choose  2 << r> + >r ;
2023-05-17 23:29:35 <KipIngram   > If choose gets passed 0, we'll do option1.  If it's passed 1, we'll do option2.  Etc.
2023-05-17 23:30:55 <vms14       > oh
2023-05-17 23:45:02 <vms14       > KipIngram: do you plan to learn about some high level language features/stuff in the future?
2023-05-17 23:45:21 <vms14       > or you'll keep always on bare metal?
2023-05-17 23:46:06 <vms14       > well you use python
2023-05-17 23:46:18 <vms14       > but for example python is not fp friendly
2023-05-17 23:46:30 <vms14       > python lambdas are a joke
2023-05-17 23:47:03 <vms14       > I have to learn prolog properly
2023-05-17 23:47:18 <vms14       > which reminds I can add it to the lang
2023-05-17 23:48:00 <vms14       > https://metacpan.org/pod/AI::Prolog
2023-05-17 23:51:18 <vms14       > I'm going to add a miniawk
2023-05-17 23:51:57 <vms14       > it's just a loop over a string that splits it into fields and pattern match with code associated
2023-05-17 23:52:52 <vms14       > adding this simple thing to a forth would help a lot with string manipulation, as it seems forth lacks string manipulation
2023-05-17 23:53:32 <vms14       > you need to add some kind of regex, but you could just split it into fields