2026-06-26 01:25:44 <Lady_luck_2083> 
ACTION is lonely

2026-06-26 01:38:29 <Stalevar    > Lady_luck_2083, do you write in forth?
2026-06-26 01:45:30 <xentrac     > perhaps programming in Forth causes loneliness
2026-06-26 01:49:44 <Stalevar    > Or other way around?
2026-06-26 01:51:10 <xentrac     > could be!  certainly socializing is often a distraction from learning
2026-06-26 02:15:56 <Stalevar    > 0 tib 15 + ! : dup drop ." Hello world!" ;  ok
2026-06-26 02:15:56 <Stalevar    > tib 21 + 0 swap ! cr drop dup cr
2026-06-26 02:16:12 <Stalevar    > xentrac, what do you think about this simple Forth helloworld?
2026-06-26 02:17:23 <Stalevar    > (for gforth x86_64)
2026-06-26 02:19:44 <xentrac     > not a fan of counting characters
2026-06-26 02:20:09 <xentrac     > but I have often enjoyed writing such head-scratcher code
2026-06-26 02:21:26 <Stalevar    > xentrac, I use echo -n '0 tib 15 + ! : ' | wc -c and echo -n 'tib 21 + 0 swap ! cr ' | wc -c
2026-06-26 02:21:39 <Stalevar    > And of course it's 15 and 21
2026-06-26 02:21:53 <xentrac     > one of the weak points of Forth, I feel, is that, like Perl, it is so tempting to be clever that applying the language to some other end requires a constant exercise of discipline
2026-06-26 02:22:18 <Stalevar    > Just another Forth hacker,
2026-06-26 02:22:25 <xentrac     > exactly
2026-06-26 02:22:58 <Stalevar    > But really, eight 0x00 bytes is a valid word?
2026-06-26 02:23:16 <Stalevar    > Except you can't type it because of readline
2026-06-26 02:23:19 <xentrac     > succumbing to the same temptation, I offer: tib 19 + 12 type \ hello, world
2026-06-26 02:23:35 <xentrac     > I don't think Gforth uses readline
2026-06-26 02:23:48 <Stalevar    > Whatever it's using is readline relative
2026-06-26 02:24:05 <Stalevar    > It can complete forth words and list history
2026-06-26 02:24:16 <xentrac     > yes, but I think it's written in Forth
2026-06-26 02:24:23 <Stalevar    > Though ^R for history doesn't work sadly
2026-06-26 02:24:43 <Stalevar    > and it eats zero bytes
2026-06-26 02:24:52 <xentrac     > right, that's one of the things I miss.  ^O is another
2026-06-26 02:25:15 <Stalevar    > What
2026-06-26 02:25:21 <Stalevar    > What's ^O?
2026-06-26 02:25:34 <tabemann    > xentrac, but that doesn't tell you how many arguments or what they are
2026-06-26 02:25:45 <tabemann    > and you're risking putting the system in an undefined state
2026-06-26 02:26:07 <xentrac     > when you're at a history entry, ^O works like Enter, but then navigates to the following command in the history
2026-06-26 02:26:38 <xentrac     > so if you want to repeat a three-command sequence from history, you can ^R to the first one, then ^O^O enter to run all three commands
2026-06-26 02:26:45 <tabemann    > okay, dinner, bbl
2026-06-26 02:26:49 <xentrac     > tabemann: I don't believe in undefined states
2026-06-26 07:44:13 <Stalevar    > : array ( n -- ) create dup , cells allot does> ( n -- naddr ) dup @ 2 pick u> if swap 1+ cells + else 2drop 0 then ;
2026-06-26 07:44:13 <Stalevar    > : print-array ( 'arr -- ) 0 over execute cell - @ 0 ?do i over execute @ . loop drop ;
2026-06-26 07:44:14 <Stalevar    > : print-array ( -- ) ' 0 over execute cell - @ 0 ?do i over execute @ . loop drop ;
2026-06-26 07:44:38 <Stalevar    > I have a question. How do I write stack comment for latter? It doesn't take anything from stack, it takes from input buffer
2026-06-26 07:44:55 <Stalevar    > I leave it ( -- ) but it doesn't feel right
2026-06-26 08:09:27 <xentrac     > forth-standard.org writes it as something like ( "<spaces>name" -- ) in examples like https://forth-standard.org/standard/core/Dotp and https://forth-standard.org/standard/core/CHAR and https://forth-standard.org/standard/core/Tick itself
2026-06-26 08:09:39 <xentrac     > but I think I'd avoid writing the second word
2026-06-26 08:10:00 <xentrac     > and instead of typing print-array foobar I'd type ' foobar print-array
2026-06-26 09:12:52 <veltas      > I think I write a comment like ( " name" -- )
2026-06-26 09:13:04 <veltas      > I don't know how useful these kinds of comments are though
2026-06-26 09:16:21 <xentrac     > oh right, I didn't notice that lonely Lady_luck_2083 was freebnc
2026-06-26 09:30:33 <veltas      > I've seen some people not write any stack comments at all, with moderate success
2026-06-26 09:38:44 <xentrac     > I think they're more important in the documentation of a module's public interface than in either the implementation or in anything about the non-public words
2026-06-26 09:40:07 <xentrac     > also they're less important for shorter words
2026-06-26 09:42:08 <xentrac     > so in wmaze.fs (which is not exemplary code but does mostly work) there are stack comments in three words
2026-06-26 09:42:31 <xentrac     > I mean https://canonical.org/~kragen/sw/dev3/wmaze.fs
2026-06-26 09:47:36 <veltas      > That looks like good code to me
2026-06-26 09:54:20 <xentrac     > yes, you've said you liked it.  and I think it could definitely be worse
2026-06-26 09:55:06 <xentrac     > but it could also definitely be better
2026-06-26 09:58:24 <lofty       > it's...very dense :p
2026-06-26 10:00:07 <xentrac     > it is, yes
2026-06-26 10:02:55 <Stalevar    > xentrac, I don't get why you use ! for walls if # seems more wall-like
2026-06-26 10:03:14 <Stalevar    > Or even use u8emit and code of full block
2026-06-26 10:04:20 <veltas      > lofty: That's often how forth code looks, because each line is a word and is somewhat logically separate
2026-06-26 10:05:03 <veltas      > And because of how the style has been influenced by how blocks of code were stored in classic forths
2026-06-26 10:05:56 <veltas      > I personally use a larger font often with Forth code because I find it helps me achieve the kind of vertical 'focus' I want when reading code, although the vast majority don't do this
2026-06-26 10:06:19 <lofty       > yeah, my own Forth code does not look like that :p
2026-06-26 10:06:35 <veltas      > Likewise if I'm writing all-caps code I'll use a serif monospace font because they tend to be easier to read capitals with, for me
2026-06-26 10:07:26 <veltas      > Nothing wrong with that lofty, you do you
2026-06-26 10:07:55 <xentrac     > Stalevar: in roguelikes # is traditionally a hallway
2026-06-26 10:09:04 <xentrac     > lofty: there are many good ways to write Forth
2026-06-26 10:10:11 <xentrac     > Stalevar: also I suspect I might have liked the color of ! better than the alternatives like % or :
2026-06-26 10:10:24 <xentrac     > but I can't remember
2026-06-26 10:10:52 <lofty       > https://forge.lightcrystal.systems/lofty/sixtyforth/raw/branch/trunk/engine.fth
2026-06-26 10:13:33 <xentrac     > this looks very clear at the line-by-line level
2026-06-26 10:15:36 <xentrac     > some parts are a little repetitive, to the point where some metaprogramming might be worthwhile to enable the reader to focus attention on the non-repeating part
2026-06-26 10:15:57 <xentrac     > it's an impressive achievement!
2026-06-26 10:16:08 <lofty       > reasonable suggestion, although I suspect this means "create"/"does>", right?
2026-06-26 10:16:21 <xentrac     > that's one approach
2026-06-26 10:17:29 <lofty       > I also admit I was a bit unsure about naming and such; I kinda fell into the Rust habit of using namespaces for things ^^;
2026-06-26 10:17:30 <xentrac     > in general I think it's better for code to look slightly too boring and repetitive than slightly too clever and compressed
2026-06-26 10:18:08 <xentrac     > your words are also relatively long
2026-06-26 10:19:15 <lofty       > yes
2026-06-26 10:19:53 <veltas      > Yeah it looks more like Rust or C code
2026-06-26 10:19:58 <veltas      > That's how my Forth used to look
2026-06-26 10:21:30 <lofty       > (I also haven't quite settled on how to format my code >.>)
2026-06-26 10:21:36 <veltas      > I would have made pawn/knight etc words that OR, and then could write "white knight" instead of creating white-knight etc
2026-06-26 10:21:54 <veltas      > And then if you really need just the "knight" part you can write  0 knight
2026-06-26 10:22:10 <lofty       > reasonable.
2026-06-26 10:22:16 <xentrac     > that sounds like a good idea
2026-06-26 10:22:33 <xentrac     > I haven't read the code well enough to suggest how to refactor it
2026-06-26 10:23:03 <lofty       > I've been moving from the position-xyz@ and position-xyz! words towards a position-xyz that one decides what to do with at point of call
2026-06-26 10:23:10 <lofty       > which I think simplifies the code a bit
2026-06-26 10:23:26 <xentrac     > I have an ideology about *why* to use small words in Forth
2026-06-26 10:23:38 <veltas      > Yeah?
2026-06-26 10:23:41 <xentrac     > which is that Forth's strong point is its interactivity
2026-06-26 10:23:56 <xentrac     > and small words support that interactivity better
2026-06-26 10:24:10 <xentrac     > because you can't interactively call part of a word
2026-06-26 10:25:09 <xentrac     > also I feel like Forth is more error-prone than C or especially Rust
2026-06-26 10:26:00 <xentrac     > so I want to break things down into small enough pieces that if they fail a test (whether interactive or automated) it's easy to see why
2026-06-26 10:26:40 <xentrac     > possibly lofty is a better programmer than I am to the point where that's not much of a concern though ;-)
2026-06-26 10:26:42 <veltas      > Yeah I've had same experience
2026-06-26 10:27:22 <veltas      > Forth code does quickly get structured in a way that's very conducive to testing and debugging, or it quickly becomes unmaintainable even for the original programmer
2026-06-26 10:27:28 <lofty       > xentrac: I'm still happy to learn from others
2026-06-26 10:28:18 <xentrac     > sure, I just mean that the optimal tradeoffs for you may be different than for me
2026-06-26 10:28:41 <veltas      > Length does correlate inversely with maintainability, if you can figure out how to factor the code it usually helps
2026-06-26 10:29:24 <veltas      > And words specifically being short helps because they are the primary way to group things, in absence of expressions, parentheses, etc
2026-06-26 10:29:28 <lofty       > well, when you pointed it out I noticed that in the current code functions like "position-piece-add-us" are only ever called with white pieces, so I can insert the colour there rather than at the call site
2026-06-26 10:30:41 <xentrac     > veltas: hmm, I hadn't thought about that!
2026-06-26 10:31:56 <xentrac     > a lot of Forths do have a single-stepping debugger, but in the absence of one, you can sort of single-step the code with the interpreter just by typing the name of each line of code in turn.  ...if you gave it one
2026-06-26 10:32:42 <veltas      > Assuming it's not full of compile-only structure
2026-06-26 10:33:16 <xentrac     > like if-then and do-loop?  yeah
2026-06-26 10:33:49 <veltas      > But it's easier to simulate and step through if the words are short, for sure
2026-06-26 10:33:50 <xentrac     > but I rarely want to single step a whole do-loop anyway, and I can simulate the if-then by hand
2026-06-26 10:34:36 <veltas      > Well there are more interpreter analogs now like [if] as well
2026-06-26 10:34:43 <xentrac     > true
2026-06-26 10:36:20 <xentrac     > I think that in the absence of any compile-time checking, the equilibrium shifts toward runtime bug detection, for better or worse, and single-step-like debugging is one way to do that
2026-06-26 10:37:25 <xentrac     > testing is another
2026-06-26 10:37:45 <veltas      > And spamming .S and ."
2026-06-26 10:38:23 <xentrac     > hmm, I don't remember putting .s in my words.  might be a good idea
2026-06-26 10:38:59 <veltas      > Well that helps when there's a stack leak
2026-06-26 10:39:24 <xentrac     > yeah
2026-06-26 10:39:43 <veltas      > I think it's good to just spam forth code confidently and rely on debugging
2026-06-26 10:40:09 <veltas      > And a good approach to debugging new code is to try running and testing the component words on their own
2026-06-26 10:40:26 <xentrac     > saw a video last night about getting Mecrisp running on a BlackPill
2026-06-26 10:40:33 <veltas      > Nice
2026-06-26 10:40:51 <xentrac     > speaking of an environment I need to explore interactively
2026-06-26 12:27:10 <Stalevar    > did anybody try to make a minimal usable forth? Like not ANS, because it has execessive standard, but not Jones Forth or Sector Forth either
2026-06-26 12:28:14 <Stalevar    > For example gforth has three screens spit out by WORDS
2026-06-26 12:28:24 <Stalevar    > That's a bit too much
2026-06-26 12:28:52 <Stalevar    > But Jonas Forth doesn't have do, ?do, type
2026-06-26 12:29:07 <lofty       > 64th is...sort of minimally usable for my purposes
2026-06-26 12:29:36 <Stalevar    > lofty, what platforms does it run on? Does anybody else use it?
2026-06-26 12:29:52 <lofty       > Linux x86-64 only :p
2026-06-26 12:31:00 <lofty       > It would probably be possible to port it over to Windows and Mac x86-64; ARM would require basically rewriting everything :p
2026-06-26 12:31:27 <lofty       > just, don't expect any creature comforts
2026-06-26 12:31:43 <Stalevar    > 
ACTION squints at win64 in include

2026-06-26 12:32:00 <lofty       > Yes, that directory comes from fasmg
2026-06-26 12:32:15 <lofty       > so it's possible to port it over to Windows/Mac
2026-06-26 12:32:32 <Stalevar    > 
ACTION also squints at tokenizer.py

2026-06-26 12:33:12 <lofty       > is kind of a hack job which isn't used by interpreter.s at the moment.
2026-06-26 12:33:38 <Stalevar    > What's it and what's for at all?
2026-06-26 12:33:52 <Stalevar    > And where's README or README.txt or README.md?
2026-06-26 12:34:01 <lofty       > sorry, could you rephrase that sentence?
2026-06-26 12:34:34 <Stalevar    > lofty, what is tokenizer.py for and why it's here?
2026-06-26 12:34:41 <Stalevar    > And why there is no readme file or anything?
2026-06-26 12:34:47 <lofty       > what would the readme even contain? supported words?
2026-06-26 12:35:54 <lofty       > The very short answer is that it's used for the built in Forth image
2026-06-26 12:36:15 <Stalevar    > The name of project, supported targets (so you don't have to repeat it's for x86-64 linux) compilation / installation, purpose of each file, what features it has, and yes, list of supported words with description of each, is it case sensitive, and so on
2026-06-26 12:37:04 <Stalevar    > lofty, imagine you run into the project by accident and want to decide if you need it or not, and if you do, how to use it
2026-06-26 12:37:19 <Stalevar    > What info you'd want to know? It should be in readme
2026-06-26 12:37:35 <lofty       > Stalevar: the answer to "if you need it or not" is almost certainly no
2026-06-26 12:37:48 <lofty       > :p
2026-06-26 12:38:00 <Stalevar    > lofty, how does it compare to lina?
2026-06-26 12:38:21 <lofty       > I've never used lina, so I can't say
2026-06-26 12:38:55 <Stalevar    > Then why you didn't? You just wanted to learn how to write forth interpreter from scratch?
2026-06-26 12:39:25 <Stalevar    > If you just needed an NASM linux forth, lina exists, not as minimal as Jonas
2026-06-26 12:39:28 <xentrac     > Stalevar: PFE is maybe "a minimal usable Forth", but it's mostly ANS
2026-06-26 12:40:07 <lofty       > Stalevar: the goal is a Forth that can be used for a 4 kilobyte demo contest
2026-06-26 12:40:34 <Stalevar    > I still don't get why you need tokenizer.py
2026-06-26 12:40:39 <lofty       > and tokeniser.py exists to compile Forth to bytecode for the inner interpreter to execute
2026-06-26 12:41:11 <Stalevar    > Ah, so you try to make a compiler, asm core, which runs but does not have interpreter/compiler?
2026-06-26 12:41:14 <xentrac     > also F-83 is both pretty usable and, due to having to run on CP/M, pretty minimal
2026-06-26 12:41:43 <lofty       > Stalevar: exactly that
2026-06-26 12:42:09 <Stalevar    > OK, then it's not very cool. sector forth is 8 times smaller and it's supposed to be stand alone
2026-06-26 12:42:11 <xentrac     > F-83 does have do and type, not sure about ?do
2026-06-26 12:42:51 <lofty       > Stalevar: ??? entirely different use cases
2026-06-26 12:42:56 <Stalevar    > Good, I wonder if there is an overview of forth standards, including forths made by Chuck Moor after ANS
2026-06-26 12:43:03 <xentrac     > it also includes a screen editor, virtual memory, multitasking, an assembler, see, and a single-stepping debugger
2026-06-26 12:43:30 <Stalevar    > Multitasking? Hm... F-83 is a standard or implementation?
2026-06-26 12:43:38 <xentrac     > an implementation
2026-06-26 12:43:55 <lofty       > Stalevar: also, um, I think you very much misunderstood the sizing there
2026-06-26 12:43:57 <Stalevar    > Does it run on linux or only CP/M?
2026-06-26 12:44:04 <xentrac     > it was written as an example ("model") of the Forth-83 standard
2026-06-26 12:44:28 <xentrac     > CP/M and MS-DOS
2026-06-26 12:44:38 <xentrac     > so I ran it on Linux under Dosbox
2026-06-26 12:44:52 <xentrac     > I forget how big it is, maybe 30K
2026-06-26 12:45:09 <xentrac     > executable
2026-06-26 12:45:25 <Stalevar    > lofty, could be
2026-06-26 12:45:32 <lofty       > sectorforth is 512 bytes, but what can you do with it? the idea of 64th is as a component of a demo, so it plays chess in 4 kilobytes.
2026-06-26 12:46:38 <Stalevar    > But why not to make tokenizer in forth? Then you can bootstrap it with your script or gforth or something
2026-06-26 12:46:54 <lofty       > that is the plan, yes
2026-06-26 12:47:39 <lofty       > but to tokenise Forth you need a Forth interpreter
2026-06-26 12:48:32 <lofty       > and I mean that in the sense of "interpreter internals to modify"
2026-06-26 12:48:41 <lofty       > you can't really do that with gforth I feel
2026-06-26 12:48:45 <xentrac     > I think F-83's biggest deficiencies are that it doesn't have readline-like command-line history and that it doesn't come with any facilities for using the IBM PC's graphics cards or sound
2026-06-26 12:49:14 <Stalevar    > Are there forths made entirely in forth?
2026-06-26 12:49:29 <Stalevar    > Sector forth and Jonas are in assembly for instance
2026-06-26 12:49:30 <xentrac     > F-83 is one
2026-06-26 12:49:42 <xentrac     > I think GForth is another
2026-06-26 12:49:46 <Stalevar    > It can recompile itself without anything extra?
2026-06-26 12:49:55 <xentrac     > F-83 can
2026-06-26 12:50:21 <xentrac     > well.  it does rely on the platform filesystem
2026-06-26 12:50:35 <xentrac     > I think GForth's build process relies on things like Make
2026-06-26 12:51:32 <xentrac     > F-83 contains significant parts in assembly, but it's Forth assembly, assembled with F-83 itself
2026-06-26 12:51:37 <Stalevar    > Gforth runs under GNU, BSD, and similar systems, MS Windows, MacOS X, OS/2, and DOS and should not be hard to port to other systems supported by GCC.
2026-06-26 12:51:40 <Stalevar    > DOS!
2026-06-26 12:51:59 <xentrac     > thanks to DJGPP maybe?
2026-06-26 12:52:14 <xentrac     > sounds like it relies on GCC, not just Forth
2026-06-26 12:52:49 <Stalevar    > I think it is impossible to bootstrap without machine code and machine code is impractical without assembly or something
2026-06-26 12:53:12 <xentrac     > no, it's totally practical to write machine code by hand
2026-06-26 12:53:14 <xentrac     > just slow
2026-06-26 12:54:06 <lofty       > I admit I'm not entirely looking forward to writing my own x86-64 assembler in forth :p
2026-06-26 12:54:29 <lofty       > fasmg is quite nice to use and not having its creature comforts will be rough
2026-06-26 12:54:44 <Stalevar    > What's 'creature comforts'?
2026-06-26 12:54:45 <xentrac     > it's not as hard as you think
2026-06-26 12:54:57 <Stalevar    > xentrac, I did write machine code for i8080
2026-06-26 12:55:21 <lofty       > https://en.wiktionary.org/wiki/creature_comfort#English
2026-06-26 12:55:41 <Stalevar    > It's easy, but looking up opcodes is menial work
2026-06-26 12:56:15 <Stalevar    > creature + comfort, in the sense of basic comforts enjoyed by non-human creatures.
2026-06-26 12:56:18 <lofty       > xentrac: for context, I will need to implement both AVX2 and AVX512
2026-06-26 12:56:21 <Stalevar    > Hm... what creature?
2026-06-26 12:56:31 <lofty       > Stalevar: wolf, if you must know
2026-06-26 12:56:47 <xentrac     > Stalevar: you may be interested in https://git.sr.ht/~oriansj/stage0/tree/141172dad905bf6d8475dbe8c3fd686d4fb072ca/item/bootstrapping%20Steps.org
2026-06-26 12:56:48 <Stalevar    > Anthropomorphic?
2026-06-26 12:57:03 <xentrac     > lofty: huh, I'd've thought a raven
2026-06-26 12:57:31 <Stalevar    > xentrac, dead link
2026-06-26 12:57:47 <Stalevar    > ah, wait
2026-06-26 12:58:03 <lofty       > xentrac: common misconception :p
2026-06-26 12:58:09 <Stalevar    > hexchat bug in interpreting links containing %
2026-06-26 12:58:17 <lofty       > Yeah that difficulty 20 is _rough_ on my phone
2026-06-26 12:58:18 <xentrac     > yeah, if you're implementing AVX512, that's a lot more than  implementing 20 or 30 instructions and 3 or 4 addressing modes, which is usually enough
2026-06-26 12:58:36 <xentrac     > yeah, it's pretty hard on this MicroPC too
2026-06-26 13:00:27 <xentrac     > as for looking up opcodes, it doesn't take that long to learn 20 or 30 opcodes either
2026-06-26 13:00:46 <lofty       > it is a bit weird to evaluate, but I think it will be more concise to perform some things with a handful of '512 instructions than write a clumsy scalar loop
2026-06-26 13:00:53 <xentrac     > then you can stop looking them up
2026-06-26 13:01:22 <xentrac     > lofty: if you only need a handful, you can just implement that handful
2026-06-26 13:01:32 <lofty       > xentrac: just LEA all the things /lh
2026-06-26 13:01:35 <xentrac     > heh
2026-06-26 13:02:08 <Stalevar    > > If you want to bootstrap anything, NEVER EVER EVER START WITH FORTH. Get yourself a good assembler first and you might find writing a garbage collected lisp or a C compiler is actually much easier.
2026-06-26 13:02:16 <xentrac     > haha
2026-06-26 13:02:44 <xentrac     > amd64 is easier in octal than in hex, fwiw
2026-06-26 13:03:22 <xentrac     > Forth provokes strong opinions ;)
2026-06-26 13:04:09 <Stalevar    > xentrac, what is that text? Is it from guys from GUIX team?
2026-06-26 13:04:29 <Stalevar    > I remember they wanted to implement zero bootstrapping to get out of compiler loop
2026-06-26 13:05:11 <xentrac     > this is the project which provides that bootstrap from zero, but it isn't part of Guix itself
2026-06-26 13:05:28 <xentrac     > they just adopted it
2026-06-26 13:07:00 <xentrac     > hmph, I need to sleep
2026-06-26 13:07:09 <xentrac     > it's been nice chatting
2026-06-26 13:07:21 <lofty       > sleep well, xentrac
2026-06-26 13:07:33 <Stalevar    > There is probably more than one 0bootstrap project
2026-06-26 13:07:43 <Stalevar    > But this one is only one successful on modern systems?
2026-06-26 13:08:30 <xentrac     > well, there are a variety of people working together on different routes
2026-06-26 13:09:30 <xentrac     > the other day someone got a version of this running under Linux to under 3 minutes
2026-06-26 13:09:38 <Stalevar    > I remember GUIX saying it was first ever successful bootstrap?
2026-06-26 13:09:55 <Stalevar    > version of what?
2026-06-26 13:10:14 <xentrac     > of stage0 and the following stages
2026-06-26 13:11:03 <xentrac     > it was the first successful bootstrap to things like current GCC
2026-06-26 13:11:44 <xentrac     > of course people have done things like Wozniak's Integer Basic before
2026-06-26 13:12:26 <Stalevar    > So is this only complete bootstrap route from zero to modern linux?
2026-06-26 13:12:42 <Stalevar    > Or somebody else replicated that in (better?) dfferent way
2026-06-26 13:13:30 <xentrac     > well, now that it's working, there are a lot of variations on it
2026-06-26 13:13:49 <xentrac     > like, fiwix is a whole thing
2026-06-26 13:15:17 <xentrac     > okay, really goodnight now!
2026-06-26 13:17:28 <Stalevar    > n January 2026 appeared a project[6] that acts as a full-source bootstrap chain for NixOS
2026-06-26 13:17:54 <Stalevar    > Huh, NixOS didn't want to leave bragging rights to being only 0-bootstrap distro to GUIX?
2026-06-26 13:55:42 <Stalevar    > I have found out that gforth data stack space is tiny 16 kilobytes
2026-06-26 14:25:19 <veltas      > On zenv I think it's like 120 bytes
2026-06-26 14:25:42 <veltas      > 16KB seems luxurious
2026-06-26 14:28:19 <lofty       > 
ACTION mumbles about a 2 megabyte data space

2026-06-26 14:30:09 <veltas      > Unless you're doing something that generates a variable number of stack items for processing, I don't see even really huge apps needing more than 16KB
2026-06-26 14:31:54 <lofty       > I probably will need to mmap myself a couple gigs of transposition table, but, later.
2026-06-26 14:34:54 <lofty       > > Each engine is allowed to use up to 256GiB of hash if initialization is multithreaded, otherwise maximum is 32GiB or 64GiB.
2026-06-26 14:35:02 <lofty       > More than a couple gigs I guess
2026-06-26 15:09:05 <crc         > I pushed the latest vhdl bits to my fossil repository, and also added a webassembly implementation of ilo.
2026-06-26 15:17:48 <veltas      > Yeah I don't know how well the dictionary alloc would work for multiple gigs
2026-06-26 15:19:11 <lofty       > this will be its own allocation :p
2026-06-26 15:42:06 <Stalevar    > here cell allot value var  ok
2026-06-26 15:42:06 <Stalevar    > var . 123 var ! var @ . .s 140127653777896 123 <0>  ok
2026-06-26 15:42:07 <Stalevar    > >>>vore<<< @
2026-06-26 15:42:36 <Stalevar    > 0 rehashall   ok
2026-06-26 15:42:37 <Stalevar    > vore . 140127653777896  ok
2026-06-26 15:45:05 <Stalevar    > Actually it seems that variable can be perfectly emulated by word value
2026-06-26 16:01:45 <deadmarshal > http://angg.twu.net/miniforth-article.html