2025-02-24 10:13:10 <user51      > another forth attempt -- this time i'm shaking things up and using lots of globals, gotos, and some hacks just because.  so far, it's surprisingly not too bad.
2025-02-24 10:14:02 <user51      > read at your own risc http://0x0.st/8AAI.c
2025-02-24 11:41:31 <pgimeno     > not bad at all, although the Extract loop could have been written without the goto
2025-02-24 11:42:21 <user51      > pgimeno: the extract section will probably be moved to a function, as some words do look ahead like :, SEE, etc.
2025-02-24 11:43:53 <pgimeno     > I'm all for gotos where they make the code clearer and less bloated, but it's rare that these cases involve a backward jump
2025-02-24 11:45:25 <pgimeno     > as for the globals, you could use the Global Political Correctness transformation trick: switch to C++ and make the globals be members of a class instead ^.^
2025-02-24 11:46:05 <pgimeno     > that usually silences complainers
2025-02-24 11:46:27 <user51      > not really concerned about the code at this point -- i plan to just write stuff and see what can be improved.  currently i'm happy with how easy the code is to navigate and change.
2025-02-24 11:46:46 <pgimeno     > yeah, I was surprised by its simplicity
2025-02-24 11:46:48 <pgimeno     > very nice
2025-02-24 11:47:08 <pgimeno     > and it made me wonder, is it unusual for Forth to use hash tables for word lookup?
2025-02-24 11:47:47 <user51      > hash tables can work but they still need to be changed, because you can redefine words. e.g : x ; : x x ;
2025-02-24 11:49:33 <pgimeno     > yeah absolutely, I'm thinking dynamic hashes like python dictionaries, c++ unordered_maps, lua tables etc.
2025-02-24 11:50:53 <pgimeno     > it's just that wherever I see a sequential search loop I tend to cringe
2025-02-24 11:51:12 <GeDaMo      > Traditionally, Forth uses a linked list for the dictionary
2025-02-24 11:57:43 <pgimeno     > yes, a tradition that arose from the lack of resources of the computes where it originated - dynamic hash tables waste memory (and probably weren't very well known back then, if at all)
2025-02-24 11:57:51 <pgimeno     > computers*
2025-02-24 12:02:03 <GeDaMo      > Partly, it's because word definitions are ordered
2025-02-24 12:02:30 <GeDaMo      > ColorForth uses an array of "hashed" names but searches it linearly
2025-02-24 12:06:43 <GeDaMo      > Of course, they don't have to be ordered, it's just tradition again :P
2025-02-24 12:16:20 <pgimeno     > I suppose words are rarely looked up in performance-critical sections anyway
2025-02-24 13:31:34 <veltas      > pgimeno: C++ core guidelines calls out that 'one simple trick doctors hate', by outlawing singletons that are there to achieve that specifically
2025-02-24 13:32:07 <veltas      > Globals aren't that optimised in modern relocatable ABIs anyway, so quite often it's probably faster and less code to not use globals
2025-02-24 18:02:03 <xentrac     > instruction sets are another culprit
2025-02-24 18:02:47 <xentrac     > like, on a PDP-10, the right half of your 36-bit instruction word could contain an 18-bit address that pointed to any global variable in your program
2025-02-24 18:03:58 <xentrac     > but on RISC machines, data addresses are 32- or 64-bit, and instruction words are 32-bit or even 16-bit, so there isn't space for a full-sized global address as an immediate field
2025-02-24 18:05:15 <xentrac     > however, you can index off a base register with a 16-bit or (on RISC-V) 12-bit offset; the time for the extra addition to compute the absolute address is hidden by the instruction pipeline
2025-02-24 18:07:19 <user51      > crc: channel logs are missing for today and yesterday
2025-02-24 18:08:13 <xentrac     > pgimeno: Forth, Inc.'s Forth systems used hash tables for word lookup since the 01970s, but with only 8 hash buckets, which only "wastes" 16 bytes of memory, except that it also required an additional pointer field in each word.  GForth uses a hash table, I think a largish one.  But most other Forths do just use sequential search, which makes forget and/or marker easy to implement
2025-02-24 18:08:47 <xentrac     > dynamically resized hash tables have been a thing since the 60s, but their advantages are indeed more compelling on computers with more memory
2025-02-24 18:14:30 <crc         > user51: fixed, thanks for letting me know!
2025-02-24 18:15:37 <user51      > crc: thanks for hosting logs  :)
2025-02-24 18:24:45 <xentrac     > yes, thank you!
2025-02-24 19:33:10 <pgimeno     > veltas: Not singletons, mere classes you happen to instantiate once because you don't need more than that. Like I suppose happens with Java's "everything's a class" philosophy. You move all your globals to a class, and then you can boast that your code is reusable ^.^
2025-02-24 19:35:34 <pgimeno     > xentrac: that's interesting to know, and yes I see how forget/marker are easier to implement without them, as Forth design assumes a sequential dictionary in these regards.
2025-02-24 19:38:45 <xentrac     > pgimeno: it's not that big a difference though
2025-02-24 19:40:04 <xentrac     > crc: http://forth.chat/logs/libera/forth/2025-02-24.utf8 is 404 despite being linked from http://forth.chat/logs/libera/forth/
2025-02-24 19:40:25 <user51      > thinking about that, i've imagined a.. discrete? forth occasionally.  as in, compared to dumping everything in the dictionary space, everything is on it's "own".  don't really know.
2025-02-24 19:40:32 <xentrac     > Firefox amusingly displays the ^B as [00 02] in a box
2025-02-24 19:40:53 <user51      > crc: none of the utf files are found on my end,
2025-02-24 19:41:25 <veltas      > pgimeno: That's what they called them, singletons.  I agree though, they're not talking about singletons, just globals in a class disguise
2025-02-24 19:44:05 <veltas      > I hate all this pattern nonsense anyway
2025-02-24 19:44:21 <crc         > user51: can you check now?
2025-02-24 19:45:41 <pgimeno     > xentrac: yeah, I imagine it isn't, it's very uncommon to look up words apart from loading and typing, where lookup time is barely critical
2025-02-24 19:46:08 <pgimeno     > veltas: anyway it was a tongue-in-cheek comment :)
2025-02-24 19:49:55 <veltas      > My tongue was firmly planted in its normal location when I said that patterns are nonsense
2025-02-24 19:50:51 <veltas      > Also Herb Sutter loves the word 'crisp' too much
2025-02-24 19:50:51 <user51      > crc: yeah, they work now
2025-02-24 19:51:06 <xentrac     > indexing off the this pointer is generally the same as indexing off any other register on a RISC machine
2025-02-24 19:51:15 <crc         > good; hopefully that fixes everything
2025-02-24 19:51:31 <xentrac     > crc: thanks!
2025-02-24 19:52:19 <xentrac     > pgimeno: compiling Forth was usually fast enough that people didn't bother to store compiled bytecode; they just recompiled everything at boot time.  the ACE is really unusual there
2025-02-24 19:52:55 <xentrac     > even in the 70s
2025-02-24 19:53:27 <veltas      > Like the PDP-11 fig forth
2025-02-24 19:53:51 <user51      > crc: speaking of logs, is there a way to download all of them at once?
2025-02-24 19:53:52 <veltas      > Unusual for Forths but really normal for boot ROMs
2025-02-24 19:54:21 <user51      > crc: wouldn't be hard to do a simple wget for it, but i dunno about that kinda netiquette
2025-02-24 19:58:20 <crc         > user51: it's not linked at the top level, but forth.chat/all.tar.gz is updated every 30-60 minutes
2025-02-24 19:58:58 <veltas      > crc maybe you should update https://forth.chat/bots.txt
2025-02-24 19:59:04 <user51      > speaking of compiling, one thing that's been in my head for a while is an evolving forth, that might border on biology or at least something close to computer virus.  i'm feeling like i'm talking nonsense, tho.
2025-02-24 19:59:06 <veltas      > You'll have to spare another block though lol
2025-02-24 19:59:34 <crc         > veltas: I'll probably do that sometime this week
2025-02-24 20:00:40 <xentrac     > user51: sounds pretty normal to me
2025-02-24 20:01:31 <xentrac     > user51: usually people try to evolve their computer systems by recompiling them from modified source code, which serves as its DNA.  Moore tried for a while to get by without source code but he eventually gave it up
2025-02-24 20:02:13 <xentrac     > he could still keep his machine code factored into tiny subroutines, but you lose compile-time macros that way (immediate words)
2025-02-24 20:03:15 <user51      > i remember reading about tht, but i'm not sure what 'get by without source code' actually means.
2025-02-24 20:03:15 <veltas      > That's a very pertinent view of Forth
2025-02-24 20:03:35 <veltas      > Writing out machine code with some comments probably
2025-02-24 20:04:11 <xentrac     > oh, well, you just generate machine code as you type in Forth, and then keep the machine code and not what you typed in
2025-02-24 20:04:32 <xentrac     > presumably there was a symbol table as well as the executable machine code
2025-02-24 20:04:46 <xentrac     > and then if you wanted to edit a definition you would decompile it with the symbol table
2025-02-24 20:04:56 <user51      > that would still be tied to a specific instruction set, no?
2025-02-24 20:05:04 <xentrac     > I don't really know the details of his sourceless-programming experiment
2025-02-24 20:05:08 <xentrac     > yes
2025-02-24 20:05:42 <veltas      > Linus Torvalds used to write machine code by hand
2025-02-24 20:05:53 <veltas      > I think a lot of people did in the 80's, without an assembler
2025-02-24 20:05:57 <veltas      > And a reference for their arch
2025-02-24 20:05:59 <xentrac     > we've all done it from time to time
2025-02-24 20:06:48 <user51      > i was thinking that such a system could evolve from one instruction set to another, but it's probably not very simple
2025-02-24 20:06:52 <xentrac     > PC Magazine IIRC published TSRs as hexadecimal you could type into DEBUG.COM
2025-02-24 20:06:59 <xentrac     > not very big TSRs, dozens of bytes at most
2025-02-24 20:07:22 <xentrac     > one I remember would turn off Caps Lock whenever you pressed Shift; I liked that one
2025-02-24 20:08:58 <xentrac     > my friend Dave wrote an octal keyboard loader in machine code that was entirely printable ASCII
2025-02-24 20:09:15 <xentrac     > so that you could bootstrap from ECHO instead of bootstrapping from COPY CON
2025-02-24 20:09:19 <crc         > 
ACTION used to use inline machine code in retroforth definitions, back when it was written for x86 architecture

2025-02-24 20:09:51 <nmz-        > I don't write a lot of forth code, but I thought factoring was a key part of it, I'm seeing a lot of forth code in rosettacode that is just C code translated to forth (big hulking functions, no idea of what the stack is even doing)
2025-02-24 20:10:51 <user51      > nmz-: give us some links, i'll give my opinions
2025-02-24 20:10:51 <xentrac     > but of course both the PC Magazine columnists and Dave had access to assemblers
2025-02-24 20:11:19 <KipIngram   > nmz - I see that all the time too and roll my eyes.  I really try to embrace the factoring thing - most of my Forth definitions wind up 40-50 characters long.  That may not be as short as you think, because I highly favor very short names, like to use single character symbols, and so on.
2025-02-24 20:11:28 <KipIngram   > Maybe 7-9 word definitions?
2025-02-24 20:12:15 <KipIngram   > The last week or week and a half or so I've been back on the Forth processor in an FPGA thing, and because of my style I'm really bending over backward to minimize call/return overhead.
2025-02-24 20:13:10 <KipIngram   > My design makes the pending code stream very visible, so I'm trying to do some "smart as possible" pre-fetching.
2025-02-24 20:15:41 <KipIngram   > At any rate, I have exactly the same feeling you had about a lot of Forth code we run across.  Although, I guess it's not surprising when someone who's experienced in C first starts learning Forth.  I know it took me a while to start producing those nice tight definitions.
2025-02-24 20:15:59 <KipIngram   > Maybe it's something you just grow into.
2025-02-24 20:19:30 <crc         > nmz-: as a data point, due to programming style differences as part of my system, my words tend to be longer than those from someone like KipIngram, but I factor frequently, and don't mind having a bunch of smaller definitions if it makes the definitions easier to read.
2025-02-24 20:21:13 <nmz-        > user51: https://rosettacode.org/wiki/Category:Forth Most of the stuff here I'd say
2025-02-24 20:22:43 <nmz-        > https://rosettacode.org/wiki/Determine_if_a_string_has_all_the_same_characters#Forth here's one
2025-02-24 20:22:44 <crc         > in konilo, I have a lot of definitions under 20 words, and many could be made much shorter if I moved code from quotations into separate words.
2025-02-24 20:23:31 <nmz-        > but I see that there's some good ones here as well
2025-02-24 20:23:37 <nmz-        > I retract my statement
2025-02-24 20:23:44 <nmz-        > looking around, most of the code here sucks
2025-02-24 20:24:28 <crc         > my lines are on the longer side though, since I have fairly verbose word names. averaging 8 characters with namespace, 5 w/o, and longest at 24.
2025-02-24 20:25:06 <nmz-        > I've seen retro code crc, you're a sane person :)
2025-02-24 20:25:45 <crc         > nmz-: in my experience a lot of published forth code is terribly long & poorly formatted :(
2025-02-24 20:26:07 <nmz-        > sad
2025-02-24 20:26:20 <nmz-        > its literally the first section of starting forth
2025-02-24 20:26:58 <nmz-        > https://github.com/johnousterhout/aposd-vs-clean-code the discussion comes from here
2025-02-24 20:28:04 <nmz-        > I'm a big believer in small functions and lots of comments. Hell I don't even write code nowadays, I start a design document and write pseudocode and this or that, then I implement it in a real language
2025-02-24 20:28:09 <user51      > nmz-: well, i'd first try factoring the string one.
2025-02-24 20:28:27 <nmz-        > 
ACTION nods

2025-02-24 20:28:30 <nmz-        > its really terrible
2025-02-24 20:28:59 <nmz-        > 
ACTION goes to cook

2025-02-24 20:30:53 <KipIngram   > I fail pretty badly on commenting.  As in, most of the time I don't do it.  I've tried, but I always wind up feeling like it's ugly.  What I'm really hoping to do someday is have an editing environment that lets me toggle inline comments on and off, and also lets me link to comments and documentation stored remotely.  Because I actually like writing documentary stuff.  It's just the appearance it
2025-02-24 20:30:53 <KipIngram   > lends my code that puts me off.
2025-02-24 20:31:44 <KipIngram   > Yes.  I'm  hoping to be able to structure all kind of wiki style, so each level of link takes me steadily from comments to design documentation.
2025-02-24 20:32:00 <KipIngram   > I think I see a good way to do that with a b* tree.
2025-02-24 20:32:24 <KipIngram   > It will just need a fairly smart editor.
2025-02-24 20:33:01 <KipIngram   > At the moment though this FPGA stuff has my attention.
2025-02-24 20:33:47 <nmz-        > hmm well at least its legible
2025-02-24 20:34:23 <nmz-        > user51: you can make an account and change the code, its mediawiki
2025-02-24 20:35:03 <crc         > user51: that doesn't match the requirements of the rosetta code challenge though
2025-02-24 20:35:49 <user51      > crc: tell that to chuck  :P
2025-02-24 20:36:10 <user51      > crc: i'll adjust the code, gimme a sec
2025-02-24 20:36:50 <crc         > user51: I'd probably end up writing a set of functions for each part, and then use them for the final word
2025-02-24 20:37:34 <user51      > crc: can i get a rough idea how it'll look like?
2025-02-24 20:42:30 <ryoshu      > is there a regression test for forth to check whether an implementation is ANSI compliant?
2025-02-24 20:44:45 <xentrac     > not ANSI, but I think there are a lot of tests on forth-standard.org
2025-02-24 20:45:07 <xentrac     > not sure if they're conveniently packaged into a test suite you can just run, but I think that's the idea
2025-02-24 20:55:15 <crc         > ryoshu: https://www.taygeta.com/forth.html has copies of the test code from john hayes for this
2025-02-24 21:07:43 <ryoshu      > John Hayes's ANS compiler validation program (27 Nov 95 version) (two files), tester.fr V1.1 and core.fr V1.2
2025-02-24 21:07:46 <ryoshu      > this one?
2025-02-24 21:08:08 <crc         > yes
2025-02-24 21:08:20 <ryoshu      > ok, thank you!
2025-02-24 21:08:24 <crc         > user51: very quick implementation at http://forth.works/temp/rosetta.txt (in retroforth)
2025-02-24 21:09:00 <ryoshu      > is pforth generally considered to be compliant?
2025-02-24 21:11:01 <crc         > no
2025-02-24 21:11:08 <ryoshu      > ouch
2025-02-24 21:11:08 <crc         > "PForth is based on ANSI-Forth but is not 100% compatible."
2025-02-24 21:11:38 <ryoshu      > I saw this, I just hope it is still Forth.
2025-02-24 21:12:22 <xentrac     > lots of things that aren't anywhere close to ANSI Forth are still Forth!
2025-02-24 21:12:41 <crc         > forth encompasses a lot; and most systems don't fully comply with ANSI or ISO
2025-02-24 21:13:16 <xentrac     > lots don't even try
2025-02-24 21:14:34 <GeDaMo      > "It's more a set o' guidelines than actual rules" :P
2025-02-24 21:15:29 <GreaseMonkey> pforth is somewhat decent
2025-02-24 21:15:48 <GreaseMonkey> it's the one i tend to use anyway
2025-02-24 21:17:03 <GreaseMonkey> just a caveat, the memory pool you get to play with is quite small
2025-02-24 21:17:25 <ryoshu      > that malloc() replacement?
2025-02-24 21:17:47 <user51      > http://0x0.st/8Ajb.forth
2025-02-24 21:17:53 <GreaseMonkey> it's forth, it's less malloc() and more sbrk()
2025-02-24 21:17:59 <user51      > ugly code, kinda pretty output
2025-02-24 21:18:25 <GreaseMonkey> the actual implementation at least *can* malloc() its memory pool(s), but it's a static allocation
2025-02-24 21:18:31 <GreaseMonkey> erm, static size
2025-02-24 21:19:24 <GreaseMonkey> huh, i didn't realise "value" was a word
2025-02-24 21:19:35 <GreaseMonkey> i tend to use "variable" and then explicitly use "@" and "!"
2025-02-24 21:20:58 <GreaseMonkey> i'm still fairly new to forth though, but i did get through maybe a bit more than half of advent of code last year using pforth
2025-02-24 21:21:49 <xentrac     > I like value better than variable mostly
2025-02-24 21:22:27 <xentrac     > the standard messed up the definition of to though
2025-02-24 21:46:18 <veltas      > Hey look, "C-style Forth" is better than no Forth
2025-02-24 21:46:29 <veltas      > I don't judge
2025-02-24 21:47:11 <veltas      > I wrote C-style Forth initially and just stopped doing this as I read and worked with more old Forth
2025-02-24 21:48:10 <veltas      > GreaseMonkey: I like variable/@/!
2025-02-24 21:49:20 <veltas      > Also I don't like complicated stack usage, if I can't simplify the stack usage I just break out variables
2025-02-24 21:49:34 <GreaseMonkey> yeah, once you get used to variables it becomes a lot nicer
2025-02-24 21:49:36 <veltas      > I'm not against using return stack when it is easy to keep track of
2025-02-24 21:50:00 <veltas      > I want my code to be readable and understandable by dumb people like me
2025-02-24 21:50:51 <GreaseMonkey> my main use of the return stack tends to be potentially implicitly as per do/loop(/exit)
2025-02-24 21:51:36 <xentrac     > I commonly find it useful for a "local variable"
2025-02-24 21:51:53 <xentrac     > >r stuff stuff r@ stuff stuff r@ stuf stuff r> stuff stuff ;
2025-02-24 21:52:22 <xentrac     > less useful when do loop comes into play obviously :)
2025-02-24 21:53:22 <veltas      > I just rewrite without DO LOOP if I want return stack
2025-02-24 21:53:30 <veltas      > Or use J
2025-02-24 21:54:00 <xentrac     > how many return stack items does J skip?
2025-02-24 21:54:07 <veltas      > Depends
2025-02-24 21:54:12 <xentrac     > :)
2025-02-24 21:55:44 <veltas      > !gforth : TEST 123 >R  5 0 DO  J .  LOOP  R> DROP ;  TEST
2025-02-24 21:55:45 <gforth_eval_bot> 123 123 123 123 123
2025-02-24 21:56:10 <veltas      > I mean regardless of how many it skips, J should always be the top of return stack before loop is entered
2025-02-24 21:56:18 <veltas      > Logically
2025-02-24 21:56:32 <veltas      > I don't know if the standard guarantees it, but I'd consider it a bug if it wasn't true
2025-02-24 21:56:34 <GreaseMonkey> "Depends" is correct, pforth gives me 5 0s
2025-02-24 21:56:48 <GreaseMonkey> ...although i have no idea why
2025-02-24 21:57:11 <GreaseMonkey> maybe I and J are internal variables in pforth
2025-02-24 21:58:01 <veltas      > Well if the counter isn't top, i.e. if I isn't R@ , then it won't work
2025-02-24 21:58:02 <xentrac     > no, they're the loop counters
2025-02-24 21:58:14 <xentrac     > not internal variables
2025-02-24 21:58:24 <xentrac     > you could try this:
2025-02-24 21:58:56 <xentrac     > !gforth : test 111 222 333 444 555 >r >r >r >r >r do j . loop rdrop rdrop rdrop rdrop rdrop ;  test
2025-02-24 21:58:58 <gforth_eval_bot> https://0x0.st/8Aj5.txt
2025-02-24 21:59:17 <xentrac     > except correctly:
2025-02-24 21:59:22 <xentrac     > !gforth : test 111 222 333 444 555 >r >r >r >r >r 5 0 do j . loop rdrop rdrop rdrop rdrop rdrop ;  test
2025-02-24 21:59:23 <gforth_eval_bot> 111 111 111 111 111
2025-02-24 21:59:46 <xentrac     > I guess that's not the ideal test vector
2025-02-24 21:59:51 <veltas      > Not sure what you're trying to prove
2025-02-24 22:00:03 <xentrac     > just suggesting how GreaseMonkey could test pForth
2025-02-24 22:00:20 <xentrac     > F83 implements i as the *difference* of the top two elements on the return stack
2025-02-24 22:00:50 <xentrac     > so that it can implement loop termination by testing the overflow flag (or carry flag, I forget)
2025-02-24 22:01:04 <GreaseMonkey> 222 222 222 222 222
2025-02-24 22:01:29 <veltas      > Try J'
2025-02-24 22:01:56 <GreaseMonkey> j' is unrecognised
2025-02-24 22:02:17 <veltas      > I guess just put something on top
2025-02-24 22:02:44 <veltas      > Or DUP 2>R
2025-02-24 22:02:57 <veltas      > And that will work on gforth and pforth then
2025-02-24 22:03:10 <GreaseMonkey> fforth also seems to emit 222 x5
2025-02-24 22:03:11 <veltas      > Because that's what we want, portable return stack hackery :)
2025-02-24 22:03:23 <GreaseMonkey> oh yeah dup 2>r would work lol
2025-02-24 22:03:59 <veltas      > !gforth : TEST 123 2DUP 2>R  5 0 DO  J .  LOOP  2R> 2DROP ;  TEST
2025-02-24 22:04:00 <gforth_eval_bot> https://0x0.st/8AjC.txt
2025-02-24 22:04:17 <veltas      > !gforth : TEST 123 DUP 2>R  5 0 DO  J .  LOOP  2R> 2DROP ;  TEST
2025-02-24 22:04:17 <gforth_eval_bot> 123 123 123 123 123
2025-02-24 22:04:43 <GreaseMonkey> works perfectly in pforth
2025-02-24 22:04:50 <veltas      > solvd
2025-02-24 22:05:53 <GreaseMonkey> fforth lacks 2>R and 2R> but also fforth is quite incomplete... and the solution is fairly easy, >R >R and R> R>
2025-02-24 22:06:36 <GreaseMonkey> ...or of course one could implement 2>R and 2R>
2025-02-24 22:13:01 <xentrac     > haha, one could
2025-02-24 22:13:13 <xentrac     > I suggest you try it; it's a highly educational experience!
2025-02-24 22:13:49 <GreaseMonkey> it's the sort of thing that would show up as an exercise in a Forth 101 cours
2025-02-24 22:13:50 <GreaseMonkey> e
2025-02-24 22:14:08 <GreaseMonkey> i'm not sure which of the two is the one that needs the SWAP
2025-02-24 22:17:01 <veltas      > 2>R  is  SWAP >R >R
2025-02-24 22:17:09 <veltas      > !gforth  36 BASE ! 6DSZO45G PAD TUCK ! COUNT TYPE
2025-02-24 22:17:09 <gforth_eval_bot> next
2025-02-24 22:17:28 <xentrac     > yes, but if you try to define : 2>R swap >r >r ; it will not work
2025-02-24 22:18:05 <veltas      > Unless you can specify it to be inlined
2025-02-24 22:21:18 <xentrac     > true!
2025-02-24 22:21:51 <xentrac     > : 2>r postpone swap postpone >r postpone >r ; immediate perhaps?
2025-02-24 22:23:36 <veltas      > Yeah
2025-02-24 22:25:39 <veltas      > !gforth  WARNINGS OFF  : 2>R ]] SWAP >R >R [[ ; IMMEDIATE  : TEST 2>R 2R> ;  1 2 TEST .S
2025-02-24 22:25:40 <gforth_eval_bot> <2> 1 2
2025-02-24 22:26:01 <veltas      > ]] in gforth just means "start postponing everything"
2025-02-24 22:26:31 <veltas      > !gforth 1 2 .S
2025-02-24 22:26:32 <gforth_eval_bot> <2> 1 2
2025-02-24 22:36:49 <veltas      > !gforth S" /usr/share/gforth/0.7.3/blocked.fb" OPEN-BLOCKS 0 LIST
2025-02-24 22:36:50 <gforth_eval_bot> Screen 0 not modified
2025-02-24 22:36:50 <gforth_eval_bot> https://0x0.st/8Ae4.txt
2025-02-24 22:39:32 <veltas      > !gforth S" /usr/share/gforth/0.7.3/blocked.fb" OPEN-BLOCKS : X 4. DO I LIST LOOP ; X
2025-02-24 22:39:32 <gforth_eval_bot> Screen 0 not modified
2025-02-24 22:39:33 <gforth_eval_bot> https://0x0.st/8Ae3.txt
2025-02-24 22:40:04 <xentrac     > wow, last modified 30 years ago
2025-02-24 22:41:03 <veltas      > Unfortunately that's the only block program that comes with gforth, as far as I know
2025-02-24 22:41:24 <xentrac     > oh, the only one stored in a block fiel?
2025-02-24 22:41:27 <xentrac     > *file
2025-02-24 22:41:39 <veltas      > Makes konilo look bloated
2025-02-24 22:42:31 <xentrac     > 29aug95 is before GForth itself, I think?  maybe this is from bigForth
2025-02-24 22:44:02 <xentrac     > I didn't know bigForth supported the $ hex prefix that's recently been added to Forth 200x
2025-02-24 22:46:47 <veltas      > Yes this code is very uncharacteristic of gforth
2025-02-24 22:48:08 <veltas      > But yes there is a block editor included with gforth
2025-02-24 22:48:15 <veltas      > It's not terrible either
2025-02-24 22:51:38 <veltas      > !gforth S" ls /usr/share" SYSTEM
2025-02-24 22:51:38 <gforth_eval_bot> aclocal
2025-02-24 22:51:39 <gforth_eval_bot> https://0x0.st/8AeD.txt
2025-02-24 22:52:44 <veltas      > !gforth S" gcc" SYSTEM
2025-02-24 22:52:45 <gforth_eval_bot> gcc: fatal error: no input files
2025-02-24 22:52:45 <gforth_eval_bot> https://0x0.st/8Aek.txt
2025-02-24 22:53:06 <veltas      > I guess gcc is a dependency of gforth
2025-02-24 22:53:19 <veltas      > Finally, a real programming language :P
2025-02-24 22:53:31 <xentrac     > aha
2025-02-24 22:53:52 <xentrac     > GForth's FFI invokes it
2025-02-24 22:56:47 <veltas      > !gforth S" ls /bin; ls /usr/bin" SYSTEM
2025-02-24 22:56:47 <gforth_eval_bot> bash
2025-02-24 22:56:48 <gforth_eval_bot> https://0x0.st/8Ae7.txt
2025-02-24 23:01:45 <veltas      > !gforth S" factor 50" SYSTEM
2025-02-24 23:01:45 <gforth_eval_bot> 50: 2 5 5
2025-02-24 23:01:51 <veltas      > amazin
2025-02-24 23:01:56 <xentrac     > what package is factor in?
2025-02-24 23:02:09 <xentrac     > coreutils
2025-02-24 23:02:17 <xentrac     > I guess coreutils is probably a dependency of gcc
2025-02-24 23:03:05 <veltas      > I'm not moaning, just exploring all the cool apps ghodawalaaman is hosting for me
2025-02-24 23:30:54 <xentrac     > haha
2025-02-24 23:43:25 <pgimeno     > !gforth : XYZ  101 >R 102 >R 103 >R 104 >R 105 >R  1 0 DO  R> R> R> DUP . >R >R >R  LOOP  RDROP RDROP RDROP RDROP RDROP ;  XYZ
2025-02-24 23:43:26 <gforth_eval_bot> 105
2025-02-24 23:44:07 <pgimeno     > !gforth : XYZ  101 >R 102 >R 103 >R 104 >R 105 >R  1 0 DO  R> R> R> J . >R >R >R  LOOP  RDROP RDROP RDROP RDROP RDROP ;  XYZ
2025-02-24 23:44:08 <gforth_eval_bot> 102
2025-02-24 23:45:08 <pgimeno     > !gforth : XYZ  101 >R 102 >R 103 >R 104 >R 105 >R  1 0 DO  R> R> R> I' . >R >R >R  LOOP  RDROP RDROP RDROP RDROP RDROP ;  XYZ
2025-02-24 23:45:09 <gforth_eval_bot> 103
2025-02-24 23:45:14 <pgimeno     > !gforth : XYZ  101 >R 102 >R 103 >R 104 >R 105 >R  1 0 DO  R> R> R> I . >R >R >R  LOOP  RDROP RDROP RDROP RDROP RDROP ;  XYZ
2025-02-24 23:45:15 <gforth_eval_bot> 104
2025-02-24 23:45:39 <pgimeno     > I think pforth inverts i and i' (although it doesn't actually support i')
2025-02-24 23:50:51 <pgimeno     > the first statement returns 105 on both, which means that they both allocate 2 cells in the return stack for a DO LOOP
2025-02-24 23:51:01 <pgimeno     > fourth*