2022-11-24 07:19:54 <veltas      > KipIngram: The "not found" thing I assume is overridable on most forths, because it's how you can implement custom literals
2022-11-24 07:20:18 <veltas      > It's sort of related to recognizers, although if I remember right recognizers intercept the entire loop
2022-11-24 07:20:53 <veltas      > I don't really like new Forth 200x ideas usually though, including this one, the deferred word for "not found" is the appropriate approach IMO
2022-11-24 08:07:29 <KipIngram   > I haven' heard of those.  If it's that' new I'm not surprised, though.
2022-11-24 08:07:57 <KipIngram   > How does it work?
2022-11-24 08:37:55 <KipIngram   > Well, I looked it up.  It's not a bad concept.  You've heard me mention implementing a replacement interpreter, to provide an "Octave like" environment.  An example point there would be the ability to enter literal arrays.
2022-11-24 08:38:12 <KipIngram   > This looks like providing a way to extend to that kind of thing instead of outright replacing.
2022-11-24 08:40:16 <KipIngram   > Still reading, though.
2022-11-24 08:41:43 <KipIngram   > One way I thought about doing that was to have the interpreter actually WORK by running a set of regular expression on the input text, and throwing an error if it got to the end of its regex list without getting success.
2022-11-24 08:42:14 <KipIngram   > Then you'd be able to add new expressons to that list, and there would be hooks for it to use to "do things" based on the expression that matched.
2022-11-24 08:42:31 <KipIngram   > A hook for interpreting, one for compiling, etc.
2022-11-24 08:43:52 <KipIngram   > The danger I recognized there is that it's potentially TOO powerful - suddenly you have the power to make the system entirely "non-Forthy" if you wanted to.
2022-11-24 08:44:41 <KipIngram   > I've long thought a regex capability would be a nice thing to have (to use in your application code); it's one of those things that once it exists, why not use it?
2022-11-24 08:45:12 <KipIngram   > Sort of like memory management.  But memory management is exactly one of those things I got "overcomplex" with in one of my implementations.
2022-11-24 08:46:51 <KipIngram   > so, I don't really regard this as a "bad" idea, but it makes me a little nervous.
2022-11-24 08:48:05 <KipIngram   > If you can add regular expression match capability to the interpreter, then suddenly you could remove the most salient hallmark of Forth - the space-separated aspect of recognizing words.
2022-11-24 09:01:25 <veltas      > IMO memory management is over-complex because it usually requires one-to-one allocations and frees
2022-11-24 09:01:52 <veltas      > Whereas it's actually easier to, for instance, create a memory manager that groups allocations and frees a group in one go, i.e. many-to-one
2022-11-24 09:01:55 <veltas      > And faster too
2022-11-24 09:02:53 <veltas      > And then if you can get away with ALLOT that's ideal
2022-11-24 09:03:06 <veltas      > Well ALLOT or the dictionary in general
2022-11-24 09:19:00 <KipIngram   > The only memory management I'd even consider building in at the ground floor would be a very simple fixed allocation size manager.  Just a "top" pointer that advances when necessary to get new blocks from RAM, and a free list holdling ponters to de-allocated pages that could be re-used.  That turns out to be a "just a couple of lines of code" thing.
2022-11-24 09:20:12 <KipIngram   > So you'd just have "alloc  ( -- a)" and "free ( a --)' and that would be it.
2022-11-24 09:20:54 <KipIngram   > When I did that in a system it wasn't the manager that overcomplicated the system - I just wound up using it in too many places.
2022-11-24 09:22:14 <KipIngram   > At the time I had in mind deploying the system on a little Cortex M4 dongle that I had, that had about 256k of RAM.  I wanted multiple process support, so I had to limit the amount of RAM the system  itself used.  But I still wanted a process dictionary to be able to grow as much as I needed it to.
2022-11-24 09:22:35 <KipIngram   > So I wound up with a system that grew in 4kB pages, and if the page got full it could allocate a new one.
2022-11-24 09:22:51 <KipIngram   > So the definitions and headers could "jump pages" as they grew.
2022-11-24 09:23:02 <KipIngram   > That wound up being kind of messy, though... it worked.
2022-11-24 09:23:52 <KipIngram   > For the headers, you couldn't straddle a header across pages, but for the definition bodies you could; it just compiled a jump to the new page into an open definition as needed.
2022-11-24 09:25:23 <KipIngram   > That caused me to need processes to have a page list, and those had to be deallocated on process termination, etc. etc.  It just kept getting more involved, one little step at a time.
2022-11-24 09:28:12 <KipIngram   > You mentioned grouped allocations.  My latest thinking on memory management is to have a fixed-size allocate that issues fairly large pages, and then have a ropes-based alloation ability from each of those blocks.  Within any given large page you'd get fixed allocations of a single size, but different large pages could support different sizes.
2022-11-24 09:28:45 <KipIngram   > So that still avoides any sort of variant-page-size complications.
2022-11-24 09:41:38 <KipIngram   > I mentioned the flow for an primary interpreter loop last night, and it got me tinkering.  I haven't tested this, but I think this would be a full interpreter loop for my system.  I think it gets all four cases (word found / not found and state = 0 / !0 right:
2022-11-24 09:41:46 <KipIngram   > : comp  .0!=; drop num ' lit , ;
2022-11-24 09:41:48 <KipIngram   > : ?run  0!=; .0!=;; drop num ' nop ;;
2022-11-24 09:41:50 <KipIngram   > : case  state @ ?run comp , ' nop ;
2022-11-24 09:41:52 <KipIngram   > : eval  bl word find case exec me [
2022-11-24 09:41:54 <KipIngram   > : quit  rp0 @ rp!
2022-11-24 09:41:56 <KipIngram   >   : ~   query eval ok me [
2022-11-24 09:41:58 <KipIngram   > Pretty amazing how simple Forth can be.
2022-11-24 09:42:22 <KipIngram   > Nice use case for the various conditional returns.
2022-11-24 09:43:17 <KipIngram   > Those are pretty typical of my coding in terms of definition length.
2022-11-24 09:43:45 <KipIngram   > And it illustrates that "vertical control flow" that has come into my coding style.
2022-11-24 09:44:30 <KipIngram   > I'm not sure I used ' in a full standard way, but it's what my recollection told me.  May not be quite right.
2022-11-24 09:45:23 <KipIngram   > And it may make the wrong assumption about the immediate/non-immediate nature of '.  I had a specific way for it to work in mind.  In all of thoe cases the goal is to compile the CFA of the following word as a literal.
2022-11-24 09:46:18 <KipIngram   > In order for my null-termination to work right, the exec call must be at the eval level, not buried down in a definition below.
2022-11-24 09:53:22 <KipIngram   > If I were going to start building a new system today, I'd begin with that.  And then work down to fill in the requirements, until it could load Forth from blocks.  Then I'd do further definitions in Forth.
2022-11-24 09:55:23 <KipIngram   > Ok, a little Gforth testing makes it appear I should have ['] instead of ' up there.
2022-11-24 10:52:50 <KipIngram   > Another move I think I'd make on a re-design would be to *not* make my EXPECT word so fancy at the starting level.  My EXPECT has gotten quite involved, but I think better would be to keep it simple and basic, and then re-vector it with a more sophisticated one, written in Forth, later.
2022-11-24 10:53:22 <thrig       > : SPANISH ... ; : INQUISITION ... ;
2022-11-24 10:53:23 <KipIngram   > Maybe backspace and Enter would be the only special keys the first one supported.
2022-11-24 10:54:17 <KipIngram   > Technically you could bootstrap without EXPECT at all - all you'd really need would be LOAD.
2022-11-24 10:54:45 <KipIngram   > Then add EXPECT from blocks.  But the idea of a Forth that I can't type into, even as a bootstrap, just kind of offends me.
2022-11-24 11:05:39 <KipIngram   > thrig: Did I say something heretical?  What's the Inquisition's beeF?
2022-11-24 11:06:56 <Zarutian_iPad> oh, just the spanish one. Not the Emperors.
2022-11-24 11:07:27 <veltas      > KipIngram: "nobody EXPECTs the SPANISH INQUISITION"
2022-11-24 11:07:55 <Zarutian_iPad> 
ACTION been watching or listening to too many W41K lore videos.

2022-11-24 11:07:56 <veltas      > It's a Monty Python reference
2022-11-24 11:09:32 <veltas      > ok SPANISH-INQUISITION SPANISH-INQUISITION?
2022-11-24 11:33:37 <KipIngram   > Oh, I did think of a harmless but slightly annoying attribute of my system.  The headers are designed so that the PFA field is optional (primitives don't need it, and in the nasm source words they don't have it).  External pointers to a header point to the CFA, but the PFA is just BEFORE that in RAM.  But it occurred to me that when I want to compile new primitives later, WORD is going to copy the name into
2022-11-24 11:33:39 <KipIngram   > the location it will need to be for a word that DOES have a PFA field.  That's fine for all other types of words, but for new primitives it's wasteful.
2022-11-24 11:33:48 <KipIngram   > Like I said, harmlelss - just slightly aggravating.
2022-11-24 11:49:46 <KipIngram   > It would be pretty easy to move it in the code word defining word.  Just move the first cell - 8 bytes - and as a side effect of that you now have the count in register al, so you're set up to move more if you need to.
2022-11-24 11:50:24 <KipIngram   > Most words won't have names longer than seven characters, so you'd usually be done already.
2022-11-24 12:11:09 <olle        > Any progress for that irc bot yet? :)
2022-11-24 12:20:26 <veltas      > Who's working on an IRC bot?
2022-11-24 12:21:24 <veltas      > olle: ^
2022-11-24 12:22:01 <olle        > veltas: You?
2022-11-24 12:22:08 <olle        > Or KipIngram
2022-11-24 12:22:13 <olle        > or thrig
2022-11-24 12:22:44 <veltas      > What should it do?
2022-11-24 12:22:51 <veltas      > Apart from connect to the channel
2022-11-24 12:23:11 <veltas      > I guess it should run Forth code, that would make the most sense
2022-11-24 12:23:25 <veltas      > Sounds like most of the work is sandboxing
2022-11-24 12:24:25 <KipIngram   > Not me.
2022-11-24 12:25:05 <veltas      > I think the word to select the bot should be "ok"
2022-11-24 12:25:19 <veltas      > Like you type:  ok 1 2 3 . . .
2022-11-24 12:25:35 <KipIngram   > I like it.
2022-11-24 12:25:41 <veltas      > And it prints:  3 2 1 ok
2022-11-24 12:26:06 <KipIngram   > I guess it would have a specific dialect.
2022-11-24 12:26:11 <veltas      > I don't think so
2022-11-24 12:26:25 <KipIngram   > Really?  How would it know all the flavors?
2022-11-24 12:26:25 <veltas      > We can have it in a community repo or something and all add in words we want
2022-11-24 12:26:35 <KipIngram   > Oh, I see.
2022-11-24 12:26:37 <KipIngram   > Yeah.
2022-11-24 12:26:43 <KipIngram   > Nice.
2022-11-24 12:27:39 <olle        > veltas: just put it in docker
2022-11-24 12:27:41 <veltas      > Or we could even have it build up its dictionary over time, and have a special command to reset
2022-11-24 12:28:12 <veltas      > olle: You're welcome to go ahead and do that
2022-11-24 12:28:27 <veltas      > docker isn't meant for sandboxing arbitrary code though... I think?
2022-11-24 12:29:55 <remexre     > consider seccomp strict mode instead
2022-11-24 12:33:53 <veltas      > Dammit olle this is now fleshed out enough an idea to be interesting
2022-11-24 12:40:33 <olle        > veltas: that's what they use in #c, probably good enough
2022-11-24 12:41:34 <Zarutian_iPad> 
ACTION preemtively invokes this yet to exists bot with: DO TRUE WHILE

2022-11-24 12:42:29 <veltas      > I think if I did this I would write a bespoke forth in C which limits the number of cycles, restricts to a sort of VM where no raw operations/memory is allowed, etc
2022-11-24 12:51:11 <olle        > too ambitious
2022-11-24 12:56:06 <olle        > just put it in a docker container that dies after 1s
2022-11-24 12:56:11 <olle        > 1s execution time
2022-11-24 12:56:22 <olle        > I don't have a vps currently :d
2022-11-24 12:57:07 <olle        > https://www.jdoodle.com/execute-forth-online/ <-- or just use this? o0
2022-11-24 12:57:40 <olle        > Hm
2022-11-24 12:58:11 <olle        > Nah
2022-11-24 13:13:56 <MrMobius    > The cool thing is if it keeps a dictionary for each user
2022-11-24 13:14:22 <MrMobius    > And keeps state between messages
2022-11-24 13:14:53 <KipIngram   > That would be cool, and should be easy - just use nickname as a vocabulary name.  Run <nick> defiinitions before processing <nick>'s code.
2022-11-24 13:15:19 <KipIngram   > And we could  use each other's vocabularies if we wanted to.
2022-11-24 13:15:56 <KipIngram   > definitions probably needs a check in it; we shouldn't be able to change that away from our own nick.
2022-11-24 13:21:56 <olle        > MrMobius: Ehm, that would require some kind of trust
2022-11-24 13:22:27 <olle        > Don't forget to separate must-have from should-have/could-have ;)
2022-11-24 13:23:12 <olle        > I guess the bot could have a library of files that could be loaded, and only trusted users are allowed to add such files
2022-11-24 13:27:02 <MrMobius    > I don't think you need trust running in emulation
2022-11-24 13:27:17 <MrMobius    > At least I would not trust anything coming off irc
2022-11-24 13:28:39 <MrMobius    > I have a 6502 forth I wanted to run on the command line and I just finished a 6502 emulator written in MIPS for a different project so I compiled that into a MIPS Linux binary that runs in QEMU
2022-11-24 13:30:29 <MrMobius    > I suppose you might be clever enough to break out of an emulator in an emulator then get root on a Linux box with nothing else on it. Doesn't seem likely though
2022-11-24 13:32:43 <MrMobius    > I just assumed it would be running in an emulator anyway since I lean toward embedded forths (ie not x86) so all the control to limit what memory can be accessed and keep different users' world's separate is easy
2022-11-24 14:33:17 <olle        > gforth is the most common forth? maybe that's an overstatement
2022-11-24 14:37:46 <olle        > since this is forth-land, everyone should have their own individual bot implementation xD
2022-11-24 15:35:55 <crc         > we've had Forth bots in the channel in the past; none really got used for anything
2022-11-24 16:05:18 <olle        > really
2022-11-24 16:05:26 <olle        > not even for learning purpose_
2022-11-24 16:05:29 <olle        > ?
2022-11-24 16:06:28 <thrig       > annoy everyone else by fumbling around in a public repl in 640 easy typos
2022-11-24 16:11:06 <olle        > slippery slope fallacy
2022-11-24 16:11:24 <olle        > at least, from my experience in #c, they showed quickly why I was wrong :)
2022-11-24 16:11:33 <olle        > during discussions
2022-11-24 16:25:18 <crc         > olle: this can also be achieved by posting code you are having issues with and asking for help
2022-11-24 16:26:52 <crc         > From the couple of Forth bots I've run, people use them for games or try to break them, not anything educational or useful
2022-11-24 16:28:07 <crc         > (Apart from dedicated purpose bots, like the channel logger or networm bridge)
2022-11-24 16:28:12 <crc         > *network
2022-11-24 16:45:24 <olle        > crc: how could you use a forth bot for games if you restrict the execution time?
2022-11-24 16:45:52 <crc         > not all games need long process8ng t8mes.
2022-11-24 16:45:58 <olle        > but sure, I'm just giving my perspetive
2022-11-24 16:46:21 <olle        > guess it could be a separate irc channel, like ##forthbot
2022-11-24 16:46:32 <crc         > you can do interactive fictions, some board games, etc
2022-11-24 16:47:55 <olle        > not if you can't save state ;)
2022-11-24 16:49:16 <olle        > 1s execution time, clean slate
2022-11-24 16:50:30 <crc         > I've explored having a separate system for each user, preserving their state between runs. A common front end bot handles parsing the irc protocol and relaying data between the systems and the channel.
2022-11-24 16:51:58 <olle        > I wouldn't be that ambitious honestly. Just one-liners for demonstration is enough, imo. At least without any trust system in place.
2022-11-24 16:54:40 <olle        > The https://3v4l.org/ site for PHP is a pretty nice example. But not connected to any channel, what I know of
2022-11-24 16:56:10 <olle        > https://3v4l.org/about - info about the tech stack
2022-11-24 17:03:26 <crc         > one downside for a forth bot is the diversity of forth systems. A bot providing access to gforth would be quite different than one for my system, or the forth that KipIngram writes
2022-11-24 17:06:44 <KipIngram   > ^ This is exactly what I think.  The idea someone posted earlier about us being able to add to the library, or at least have a <nick> vocabulary, was good - I could put definition-level implementations of my conditional return words in mine, for example, and then my one liners would actually run.
2022-11-24 17:08:30 <olle        > Hm hm
2022-11-24 17:08:57 <crc         > that still wouldn't work for mine, which is very much not a standard model
2022-11-24 17:09:09 <olle        > That might be more a should-have than must-have, but sure :)
2022-11-24 17:10:46 <crc         > 
ACTION isn't opposed to seeing a new attempt at a forth bot, but will remain skeptical of the potential usability of it :)

2022-11-24 17:11:03 <KipIngram   > Well, I could see just something entirely standard, or else trying for the above.  But points in between don't seem to make a lot of sense to me.
2022-11-24 17:11:31 <olle        > https://github.com/jhuckaby/simplebot  "
2022-11-24 17:11:32 <olle        > SimpleBot is an easy-to-install and easy-to-use general purpose IRC bot, written in Perl. It is built on the awesome Bot::BasicBot framework."
2022-11-24 17:12:00 <olle        > Meh, I'd still need to run a VPS again
2022-11-24 17:12:12 <crc         > olle: we used to have https://sametwice.com/sifbot running https://sametwice.com/sif
2022-11-24 17:13:01 <olle        > oh!
2022-11-24 17:14:55 <olle        > Anyway, I'll sleep now. Bye!
2022-11-24 17:14:57 <olle        > 
ACTION zz

2022-11-24 17:15:09 <crc         > this was last used in 2017; prior to that was in 2003
2022-11-24 17:15:20 <crc         > good night
2022-11-24 17:25:26 <veltas      > crc: I'll have to have a think about how to accomodate retro
2022-11-24 17:26:02 <veltas      > Probably could just cheat and have a .retro command or something but interesting to think about how to integrate it anyway
2022-11-24 17:28:31 <veltas      > sif is the kind of thing I had in mind
2022-11-24 17:29:25 <veltas      > Although sifbot not sure if I want to run on my server, given it's written in bash
2022-11-24 17:33:24 <crc         > I've thought about rewriting sifbot in forth, but haven't worked on that
2022-11-24 17:49:46 <veltas      > I'm not planning on writing in forth, I would probably wrap in C
2022-11-24 17:51:07 <veltas      > crc: That link for sif doesn't seem to work
2022-11-24 17:51:18 <veltas      > Well specifically I can't seem to download it
2022-11-24 17:53:19 <veltas      > Okay never mind I've got it to work, something to do with https
2022-11-24 18:00:08 <veltas      > Wow I didn't realise how complete the logs are for #forth, all the way back to 2000
2022-11-24 18:03:49 <veltas      > KipIngram: I have thought about having a nick vocab, also works better if you can message the bot directly so you don't just clutter the channel
2022-11-24 18:04:22 <Zarutian_iPad> veltas: I aproove of both
2022-11-24 18:05:48 <Zarutian_iPad> also add in a way to copy/import/get a word definition from a diffrent nick vocab, even if it is a SEE like thing to see the definition
2022-11-24 18:06:25 <veltas      > Yeah KipIngram said let people access each others vocabs
2022-11-24 18:06:53 <veltas      > But presumably not let you edit each others vocabs lol
2022-11-24 18:07:26 <veltas      > It is an interesting idea, and might be fun for a few days and actually useful for some forth education
2022-11-24 18:07:33 <veltas      > Not that we get a lot of forth questions anymore
2022-11-24 18:18:39 <veltas      > crc: Ah... big problem(?) with sif, there's no licence
2022-11-24 18:19:33 <veltas      > Is there a licence available somewhere? Presently it seems to just have implicit copyright (i.e. no copyright statement, no 'MIT Licence' or anything declared)
2022-11-24 18:37:18 <KipIngram   > Yeah - just add the other vocs to your example context.
2022-11-24 18:37:47 <crc         > it's GPL
2022-11-24 18:37:56 <crc         > https://sametwice.com/jason_s_old_programming_projects
2022-11-24 18:38:01 <KipIngram   > But yeah - being able to see the contents somehow (a good SEE would be fine).
2022-11-24 18:43:15 <crc         > I should write something to make browsing and searching the channel logs easier
2022-11-24 19:15:14 <veltas      > Ah GPL, thanks
2022-11-24 20:39:25 <crc         > I'm pretty sure that everything open-source Jason wrote around that time is GPL
2022-11-24 20:40:08 <crc         > that makes them more difficult for me to study, but at least the licensing on this is listed
2022-11-24 21:45:34 <KipIngram   > So, for a long time I've fancied being able to somehow have something in Forth that gets at the power Linux offers via command pipelines.
2022-11-24 21:46:31 <KipIngram   > I've spent a few minutes here scratching my head over that, and it's kind of a big ask.  Forth's "in order, start to finish" way of processing input just doesn't fit in with that type of setup very well.
2022-11-24 21:47:05 <KipIngram   > Forth will have processed the first commands at the beginning of the line, and sent the results to the screen, before it ever sees that first pipe character.
2022-11-24 21:47:45 <KipIngram   > So to even get started on it it looks like would require some "whole line" processing, where you recognized the pipe structure and figured out what you were going to do with the various output and input streams.
2022-11-24 21:48:07 <KipIngram   > Consider
2022-11-24 21:48:41 <KipIngram   > <foo args> foo | <bar args> bar | <bam args> bam
2022-11-24 21:49:29 <KipIngram   > What you'd really like for that to do is start two new processes, for bar and bam, and then wire the i/o streams together.
2022-11-24 21:49:44 <KipIngram   > bar would see its args before it got foo's output, and the same for bam.
2022-11-24 21:50:26 <KipIngram   > You could run foo in your existing console process, but its output would come from the bam process instead of the foo process.
2022-11-24 21:50:58 <KipIngram   > I have no idea if that might lead anywhere interesting or not, but it's what popped out of first thinking.
2022-11-24 21:51:23 <KipIngram   > Forth is just word-oriented instead of line oriented.
2022-11-24 22:07:54 <vms14       > made a todo app with my crappy lang
2022-11-24 22:08:02 <vms14       > ttps://termbin.com/3z32 the code
2022-11-24 22:08:15 <vms14       > https://brilliant-duckanoo-5fd54c.netlify.app/oh.html the result
2022-11-24 22:08:25 <vms14       > lol it's missing a 'h' the first link
2022-11-24 22:35:35 <KipIngram   > That commentary above getes lightly into how Linux has "built in" commands and external commands.  I guess it would run the built-ins in your console process and launch new processes for the external ones.
2022-11-24 22:39:06 <thrig       > shells have various builtin commands (cd being important, the rest less so), and may fork/exec other things
2022-11-24 22:58:26 <KipIngram   > Yeah.  In Forth "all words are equal" in a sense.  If I were trying to handle that line I gave above, I guess I'd maybe I'd run bam in the foreground, and launch new processes for foo and bat - the ones that have a pipe symbol after then.  But it wouldn't really be for just those words - it would be for the whole bit of text preceding that pipe.
2022-11-24 22:58:52 <KipIngram   > It would just be "a process" that got fed that string.
2022-11-24 22:59:15 <KipIngram   > After that string was processed, bar and bam would continue to get fed the outputs of foo and bar.
2022-11-24 23:01:19 <thrig       > a shell will typically do various things to a line (interpolation, etc) before even running anything. also, slow
2022-11-24 23:01:36 <KipIngram   > So I guess there's no disparity between the words, now that I think about it.  It's three Forth processes each processing lines of input, and with their IO stiched together the right way.
2022-11-24 23:01:57 <KipIngram   > Please define interpolation in this context.
2022-11-24 23:02:07 <KipIngram   > I'm only familiar with mathematical interpolation.
2022-11-24 23:02:47 <thrig       > have you understood why `FOO=bar echo $FOO` prints nothing?
2022-11-24 23:03:15 <KipIngram   > And yes - definitely would be slowish.  It's interpretation, and also involves launching processes and moving their I/O around.
2022-11-24 23:03:22 <KipIngram   > Good bit of activity.
2022-11-24 23:03:44 <KipIngram   > Guess I could think some about what it would mean to compile it.
2022-11-24 23:04:48 <KipIngram   > I guess that would need to be three processes still - whatever word you defined would launch them all.
2022-11-24 23:16:10 <KipIngram   > Ok, so that's pretty well defined, I guess.  A line like that just gets treated like three lines of input, run through through processes, and those get their i/o streams hooked up in the right way.  That should run fine and produce a well-defined output.
2022-11-24 23:17:15 <KipIngram   > The question then is what the starting stack state is for hte other two processes, and what gets done with the final stacks.
2022-11-24 23:17:56 <KipIngram   > You're really concerned in a case like this with the output; I'll need to think more about the stacks.
2022-11-24 23:28:12 <KipIngram   > Yeah, I don't really see any coherent usage of the stack in a case like that.  Trying to immediately requires sequential execution.  This is just a different sort of operation.
2022-11-24 23:28:56 <KipIngram   > In most cases the bits of code would probably be written to not leave any net stack effect (individually).
2022-11-24 23:29:53 <KipIngram   > Maybe they leave one result, which would be the equivalent of the "status result" in Linux.
2022-11-24 23:30:36 <KipIngram   > Not sure what I'd *do* with it - probably wouldn't want it there cluttering the stack when the line was finished.  Maybe stow it somewhere.
2022-11-24 23:31:25 <thrig       > advanced: streams can be shared between processes and thus a child or parent can adjust what the parent or child reads from a stream
2022-11-24 23:32:36 <KipIngram   > Does that imply something more than the obvious stdout->stdin connection?
2022-11-24 23:33:36 <KipIngram   > see this is just an odd situation for Forth.  Forth pretty religiously takes *commands* from the input stream and *data* from the stack.
2022-11-24 23:34:02 <KipIngram   > And it doesn't really mean for its screen output to have anything further "done with it - it's output that is intended for further processing is also via the stack.
2022-11-24 23:34:28 <KipIngram   > It's an uphill climb to try to make this actually work in a meaningful way at all.