2026-01-31 01:26:59 <cleobuline  > forthBot:  LOAD ini.fth
2026-01-31 01:27:00 <forthBot    > File ini.fth with MOON  loaded
2026-01-31 01:27:17 <cleobuline  > forthBot: : BUNNY CAT ; BUNNY
2026-01-31 01:27:17 <forthBot    >    /_/
2026-01-31 01:27:17 <forthBot    >   > ^ <
2026-01-31 01:27:17 <forthBot    > ( o.o )
2026-01-31 03:27:17 <forthBot    > Environment for cleobuline inactive, freeing...
2026-01-31 20:02:27 <rendar      > each . word should pop from stack and convert the cell into a string but inside a buffer, right? then, once the VM finished to execute the whole line, e.g. "1 . 2 . 3 ." the string buffer is flushed to stdout
2026-01-31 20:02:32 <rendar      > is this a reasonable design?
2026-01-31 21:01:39 <veltas      > rendar: To achieve that you would need to add stdio.h style buffering, but I don't think that's typical in Forths
2026-01-31 21:02:58 <veltas      > The performant I/O in Forths is the file or block word sets, which are designed with buffering in mind
2026-01-31 21:03:36 <veltas      > But the terminal tends to be assumed to be synchronous, despite performance impact, because it simplifies things and requires less memory
2026-01-31 21:04:25 <veltas      > That said there's nothing unreasonable with buffering your terminal I/O if it's a non-standard Forth, and you document this behavior clearly, and you provide some kind of 'flush' word
2026-01-31 23:04:24 <KipIngram   > I usually write my Forths so that the "primitive" output operation is a string write.  Then emit writes a 1-byte string.  Instead of building TYPE from EMITm, I optimize TYPE and then build EMIT on it.
2026-01-31 23:05:34 <KipIngram   > The whole point being to have access to more performant bulk text output.
2026-01-31 23:06:25 <KipIngram   > I don't try to buffer up all of the output from a whole line of code before sending it out, though.
2026-01-31 23:07:22 <KipIngram   > If you build everything from EMIT that's really going to be bad performance.  Not only are you iterating over your string in Forth, you're MAKING OS CALLS per character.
2026-01-31 23:10:42 <KipIngram   > If you were LOADing a block, would it buffer up all the output from the whole block until you came back to the interpreter and reached end of line?
2026-01-31 23:11:07 <KipIngram   > I know loading blocks usually don't do a particularly excessive amount of output, but that's kind of a long time to wait before seeing anything.
2026-01-31 23:11:29 <KipIngram   > If you were doing a really large load you wouldn't be able to introduce any  progress markers.