2024-04-18 00:43:08 <zelgomer    > lf94> zelgomer: could you elaborate? i find that interesting  -- veltas pretty much got it, yeah. part of it may just be that i have decades worth of perfecting style and naming conventions when i write in c, and i'm still new enough to forth that i'm still struggling to establish conventions. but i also think there are just more things to name in forth. and some of my names come out cryptic, but i feel
2024-04-18 00:43:14 <zelgomer    > compelled to keep them short so that definitions that use them read nicely.
2024-04-18 00:45:41 <zelgomer    > c also allows you to reuse names when they're struct members. struct foo { int x; } isn't the same x as struct bar { int x; }. in forth, i'd be inclined to name those xs uniquely so that you don't have to juggle vocabularies to use them together.
2024-04-18 00:46:06 <zelgomer    > and of course lexical scoping, as well, but you can argue the vocabularies and hyperstatic scoping alleviate this
2024-04-18 00:46:33 <zelgomer    > or hyperstatic namespacing, whatever that buzzword is
2024-04-18 00:54:01 <zelgomer    > here's an example from my forth:  : c@+ ( a n1 -- n2  host-agnostic little-endian fetch step)  8 << swap c@ or ;  ( and then some lines later where i define a vocabulary for working with the target image...)  : @ ( a -- n)  >host dup 1+ dup 1+ dup 1+ c@ c@+ c@+ c@+ ;
2024-04-18 00:54:35 <zelgomer    > eventually i hope to get what i'm working on to a nice place and then publish it somewhere, just to share what i'm doing but also to invite style feedback
2024-04-18 00:56:40 <lispmacs[work]> just mention that zeptoforth and others have module support, with private and public namespaces
2024-04-18 00:57:24 <zelgomer    > yeah i'm not writing forth to use something somebody else made, though
2024-04-18 00:57:35 <zelgomer    > if i'm going to use something made by someone else, i might as well use c
2024-04-18 00:58:08 <lispmacs[work]> abstraction and library reuse are available and practical in some forths, like zeptoforth
2024-04-18 00:58:38 <zelgomer    > you just mentioned that
2024-04-18 00:59:36 <lispmacs[work]> just saying that it is possible to have modules and namespaces in forth, even if you code that system yourself
2024-04-18 00:59:56 <zelgomer    > of course it is, i covered vocabulary juggling
2024-04-18 01:00:02 <lispmacs[work]> as opposed to having to agonize over field names and such to keep everything unique
2024-04-18 01:00:59 <lispmacs[work]> only caught a few lines of the discussion. anyway, heading out from keyboard
2024-04-18 02:01:48 <MrMobius    > another thing you can do is put a skip bit in your words and variables so you can hide them from searches after you're done using them but references still work
2024-04-18 02:08:17 <zelgomer    > i have a forget word that unlinks them from the vocab which i could use like that, yeah
2024-04-18 02:09:13 <zelgomer    > i create vocabularies for private words and then when i'm done with it, i just forget the vocabulary word so they're all unreachable
2024-04-18 02:39:11 <Al2O3       > X-Scale there was quite an amazing IDE for postscript written in 90-91, on NS .9 and then 1.0, think it supported NS 2 and 3, and PS version pre and 1 and maybe 2.
2024-04-18 02:39:34 <Al2O3       > it was outstanding for working out drawing prior to implementing it as .ps files in a project, and finally into a view class.
2024-04-18 02:40:26 <Al2O3       > I'd have to dig a little on the implementation, I used it for about 2 years.   It is in large part other than DPS and executing Adobe PS in the DPS world, what got me to love PS.
2024-04-18 02:40:51 <Al2O3       > might have even been back in 88 now that I think about it.
2024-04-18 02:42:13 <Al2O3       > It was not the front end PDF/PS editor Tailor, this was a complete IDE app
2024-04-18 02:42:53 <Al2O3       > if you are really interested in seeing it run, I will dig up some archives and look, but that is time consuming for a small meaningless but other than for me PS editor/app/visualizer.
2024-04-18 02:43:09 <Al2O3       > if I remember right, it had debugger, had stack visualizer, and also had display
2024-04-18 02:45:10 <Al2O3       > it was a front runner on the system development for application and even some framework developers that were coming into the fold.
2024-04-18 02:45:44 <thrig       > Apple mumbled some stuff about display ps
2024-04-18 02:49:51 <Al2O3       > for a while, and Adobe fucked up NeXT, and in part that was part of the problem with going to quartz, but I digress.
2024-04-18 02:50:29 <Al2O3       > ultimately, it was a licensing issue, and also superior in my view, it was the right decision to go to Quartz, money, and adobe blows.
2024-04-18 02:51:13 <Al2O3       > warnock was a real fucking piece of work.
2024-04-18 02:51:26 <Al2O3       > may he RIP
2024-04-18 02:53:19 <Al2O3       > yep, this was it as I recall.
2024-04-18 02:53:20 <Al2O3       > https://adobe.fandom.com/wiki/Displaytalk
2024-04-18 02:53:33 <Al2O3       > and 88 was the revamped recollection
2024-04-18 02:54:04 <Al2O3       > it was expensive, was simple, and it worked well for alpha and beta idea exploration.
2024-04-18 02:54:32 <Al2O3       > ultimately it was not needed, cause honestly, you could write, and compile the same tool for the most part in literally mins in IB.
2024-04-18 02:55:18 <Al2O3       > you could make an editor, a back end or mid end compiler call to a file, and then shove that into an object file, set target and compile and be done.
2024-04-18 02:55:22 <Al2O3       > or so I recall.
2024-04-18 02:55:57 <Al2O3       > might have been easier, its been literally 36 fucking years :)   phew.
2024-04-18 03:18:44 <KipIngram   > Wow - 36 years ago I was still working on railguns and coilguns in a University of Texas research lab.  Old days, man.
2024-04-18 03:19:56 <Al2O3       > yep
2024-04-18 03:19:59 <Al2O3       > time flies.
2024-04-18 03:20:24 <Al2O3       > and they one dies, old day man.
2024-04-18 06:25:18 <Al2O3       > KipIngram where you part of this... https://repositories.lib.utexas.edu/server/api/core/bitstreams/7fdd234a-4f62-4cf6-9d9f-754b7cf86f95/content
2024-04-18 07:45:15 <remexre     > writing a forth, block editor, etc. for AVR in a week for a university final project
2024-04-18 07:45:32 <remexre     > using this as a chance to try out Python as a macro assembler -- so far, it's a lot better than I thought
2024-04-18 08:51:04 <lf94        > How come Forths for 8-bit cpus (6502, Z80) usually have 16-bit cells?
2024-04-18 08:51:37 <lf94        > (I've drastically simplified my hash implementation thanks to this, and using pointers)
2024-04-18 08:52:07 <lf94        > \ random tests
2024-04-18 08:52:09 <lf94        > $0263 $08A9 a 32! $13FA $F742 b 32!
2024-04-18 08:52:11 <lf94        > a b 32+ a 32@
2024-04-18 08:52:13 <lf94        > $165D $FFEB 2 assert=..
2024-04-18 09:20:33 <veltas      > lf94: Exactly for that reason!  You want addresses, most 8-bit computers have 16-bit addresses
2024-04-18 09:20:50 <veltas      > And although they do 8-bit operations faster usually, they can also do 16-bit operations with a few more cycles
2024-04-18 09:57:01 <Al2O3       > remexre neat to hear, hopefully  you can share with us your final project's implementation
2024-04-18 10:25:03 <veltas      > "in a week" like starting in a week or total writing duration is a week?
2024-04-18 14:09:56 <KipIngram   > lf94: I suspect it's just because 16-bit cells are so much more USABLE than 8-bit cells.  My guess is that so many applications you wrote would wind up involving you doing your own larger cell support, that they just decide to give it to you in efficient primitive form so that you don't have to do that.
2024-04-18 14:11:46 <KipIngram   > I guess they could have offered a pure 8-bit system and then also offered 16-bit "double words," but it doesn't surprise me that many opt not to - to just go with 16-bit native words to start with.
2024-04-18 14:13:05 <KipIngram   > A pure 8 bit architecture would, logically, have 8-bit @ and !, and those could only access a tiny bit of RAM - not really enough to implement a system, so some blurring of that line is almost required.
2024-04-18 14:46:40 <veltas      > Yeah you can't have an ANS 8-bit forth
2024-04-18 14:46:47 <veltas      > 'true' 8-bit
2024-04-18 14:47:42 <veltas      > I was walking the dog though and thinking about what a 'true' 8-bit forth would look like, and there's some interesting points to consider
2024-04-18 14:48:27 <veltas      > Use doubles for addresses, probably worth going STC then and inlining a lot of words
2024-04-18 14:48:59 <veltas      > Have a dedicated register/variable for most address work
2024-04-18 14:49:23 <veltas      > I'm guessing would be targeted at games because performance is the only justification I can think of
2024-04-18 14:49:28 <veltas      > I don't think it saves a lot of size
2024-04-18 14:50:12 <veltas      > Maybe I'm wrong, maybe it does
2024-04-18 14:50:44 <veltas      > Also they probably wanted 16-bit cells because all the early info about Forth assumed minicomputer or larger
2024-04-18 14:51:10 <veltas      > Like Starting Forth, Chuck's early papers, early Forth Inc software
2024-04-18 14:52:54 <veltas      > Even more justification for VALUE
2024-04-18 14:53:22 <veltas      > for true 8-bit you can use VALUE to do global operations without ever touching the address
2024-04-18 14:53:53 <veltas      > So it would be a VALUE-based forth, toss out all your VARIABLEs
2024-04-18 15:54:17 <lf94        > Ah, the 16-bit address thing makes sense.
2024-04-18 15:55:21 <lf94        > So tonight I'm going to continue the refactor, and add a small bitcoin-mine word that takes a bitcoin header
2024-04-18 15:56:08 <lf94        > (It's really easy, you just do sha256(sha256(bitcoin-header-bytes)) )
2024-04-18 15:56:30 <lf94        > (Ooof, how could you guys understand that. I meant bitcoin-header-bytes sha256 sha256 :))
2024-04-18 15:56:56 <lf94        > (And then it loops until there are some amount of zeros at the beginning of the hash)
2024-04-18 16:04:23 <lf94        > The final program will print the hash out at 0,0 in text
2024-04-18 16:04:43 <lf94        > Then I'll try running it on durexforth and gbforth
2024-04-18 16:07:09 <veltas      > Nice
2024-04-18 16:07:20 <veltas      > Might want to run it on the first bitcoin header
2024-04-18 16:21:34 <lf94        > yep :)
2024-04-18 16:41:20 <veltas      > Start an 8-bit bitcoin fork
2024-04-18 16:41:40 <veltas      > "8-bit emulated clients only, no cheating"
2024-04-18 16:44:29 <coyote      > reminds me of this video where someone writes a bitcoin client for the game boy https://www.youtube.com/watch?v=4ckjr9x214c
2024-04-18 16:44:58 <veltas      > Thinking back to the first computer I ran a bitcoin wallet on it may as well have been a game boy
2024-04-18 16:45:17 <veltas      > Was a Pentium 4 netburst
2024-04-18 16:46:16 <lf94        > lol
2024-04-18 17:29:49 <remexre     > Al2O3: will do!
2024-04-18 17:30:30 <remexre     > veltas: total duration is a week... some planning failures on my part, and semi-unexpected travel i didn't have much time to work during
2024-04-18 17:31:22 <Al2O3       > KipIngram, did you see that link I found?
2024-04-18 17:37:44 <lf94        > Hm. No playstation 1 or playstation 2 forths? :)
2024-04-18 17:40:41 <Al2O3       > well, there is an opportunity there I think.
2024-04-18 17:40:59 <Al2O3       > I have a playstation 2, and if you write one for it, I'll test it for you.
2024-04-18 17:41:21 <Al2O3       > if there is a VNC client for the playstation 2, I'd even try and set that up for remote testing via some visual testing software I have access to :)
2024-04-18 17:41:29 <Al2O3       > oh wait, playstation don't have ethernet I bet.
2024-04-18 17:41:34 <Al2O3       > never mind.
2024-04-18 17:44:20 <lf94        > ps2 has ethernet i know
2024-04-18 17:44:25 <lf94        > and yeah, my ps1 and ps2 are modded to play anything
2024-04-18 17:44:34 <lf94        > (xstation on ps1, freemcboot on ps2)
2024-04-18 17:44:57 <lf94        > I think I should start with a few simple games in forth on PC
2024-04-18 17:45:01 <lf94        > connect 4, snake, etc
2024-04-18 17:45:06 <lf94        > tetris
2024-04-18 17:48:14 <Al2O3       > yah, why not.   And if you do get a forth working on PS2, I'll be up for trying to figure out how to get it working here and test it for ya.   But a test suite for forth is so basic, many have been written.   Will you do a ANS forth implementation, modern or previous and a larger library as well of words?
2024-04-18 17:51:36 <GeDaMo      > "PlayStation 2 Architecture A practical analysis" https://www.copetti.org/writings/consoles/playstation-2/
2024-04-18 17:53:33 <lf94        > whoa whoa, hold your horses, I'm not doing a forth implementation just yet ;)
2024-04-18 17:53:46 <lf94        > I will probably not do one for awhile, until I'm comfortable actually using the language
2024-04-18 17:54:08 <lf94        > I'm at the stage of "huh, I think there's something interesting here"
2024-04-18 17:54:26 <lf94        > GeDaMo: yeah, that guy is a textbook example of amazing documenter.
2024-04-18 18:17:35 <veltas      > remexre: That's cutting it very close, go for bare minimums first and maybe just use someone else's block editor etc to save time
2024-04-18 18:17:43 <veltas      > Can still demonstrate your core that way
2024-04-18 18:17:50 <remexre     > eh this is like my tenth forth lmao
2024-04-18 18:18:01 <veltas      > Have you done them in a week before?
2024-04-18 18:18:29 <veltas      > Don't you have a report to write as well?
2024-04-18 18:18:31 <remexre     > haven't timed before, I've definitely gotten further in 3 days for aarch64 than I am so far
2024-04-18 18:18:38 <remexre     > nah, I get an extra week for the report
2024-04-18 18:19:00 <remexre     > we're demoing first, then the prof can say like "we don't have time to talk about $foo but put it in your report
2024-04-18 18:19:01 <remexre     > "
2024-04-18 18:19:19 <veltas      > Is it a group project?
2024-04-18 18:19:54 <remexre     > optionally, but i couldn't find anyone who wanted to abandon C...
2024-04-18 18:20:13 <remexre     > well, that's not true, one person wanted to run pytorch on our ATmega3208...
2024-04-18 18:21:26 <remexre     > but no, it's just me and a lotta coffee
2024-04-18 18:26:58 <MrMobius    > remexre: sticking to the ram on the atmega or do you have SPI memory of some kind?
2024-04-18 18:32:42 <remexre     > MrMobius: sticking with RAM, but playing the appropriate fuse games to have the dictionary be in flash
2024-04-18 18:33:34 <remexre     > With VARIABLE being in EEPROM and adding a RAM-VARIABLE that's actually in RAM
2024-04-18 18:34:58 <lf94        > Has anyone done game programming here
2024-04-18 18:35:16 <lf94        > I feel like, every time I approach it, it's a scary subject, despite probably having done harder shit before
2024-04-18 18:35:37 <user51      > lf94: Are you asking with forth in mind?
2024-04-18 18:35:38 <lf94        > My general idea is, keep a global game state around
2024-04-18 18:35:40 <lf94        > Yeah
2024-04-18 18:35:52 <lf94        > And also keeping a "rendering state"
2024-04-18 18:36:02 <lf94        > And then finally have a "rendering engine" that handles this rendering state
2024-04-18 18:36:07 <lf94        > So it's somewhat decoupled from the underlying hardware
2024-04-18 18:39:29 <user51      > Maybe try asking on the forth subreddit, I think I've seen a few
2024-04-18 18:40:00 <user51      > Well, a few discussions at least :)
2024-04-18 18:47:43 <crc         > For game stuff, Roger Levy did a few things: https://github.com/ramenengine/RamenEngine and https://github.com/RogerLevy/gamester
2024-04-18 18:48:50 <crc         > also the older (and probably not working on modern windows) https://retroforth.org/glypher/
2024-04-18 19:51:57 <KipIngram   > Al203: I just went back and found the link.  Yes, I was there at CEM-UT at that time and knew all three of those guys personally.  Jon and I worked particularly closely together.  That architecture of launcher was basically the focus of my PhD dissertation.  At the time of that paper I was still primarily doing coursework for my master's degree and hadn't set in on actual research yet.
2024-04-18 19:52:03 <KipIngram   > That was all a whole lot of fun.
2024-04-18 19:52:32 <KipIngram   > Gully was the assistant director of the research center.  The director, Bill Weldon, was my PhD supervising professor.
2024-04-18 19:53:01 <KipIngram   > Pro tip: having the same guy be your employment boss and your supervising professor really streamlines things.
2024-04-18 19:54:00 <KipIngram   > I think it was the following year that I switched from part-time grad student employee to full-time staff engineer; I did that when I finished all the necessary coursework for my PhD and had only my research left to go.
2024-04-18 19:54:25 <KipIngram   > I was there until May 1996.
2024-04-18 19:55:23 <KipIngram   > Sorry - Jon was the first listed author.  I just realized only initials were there in the paper.
2024-04-18 19:55:44 <KipIngram   > Driga was the center's "chief scientist."
2024-04-18 19:56:49 <KipIngram   > My PhD research was specifically about designing the shape of the "armature windings" in a coil gun in order to get a launch force profile as close to uniform as possible.  Simple rectangular coils tended to produce really spikey profiles.
2024-04-18 19:57:53 <KipIngram   > The real money behind all that research came from the Army and their interest in putting electric guns on tanks.  But that just never worked out - we weren't able to get them compact and light enough for tank service.
2024-04-18 20:02:04 <MrMobius    > So they revoked your PhD?
2024-04-18 20:02:08 <MrMobius    > :P
2024-04-18 20:04:46 <thrig       > but what if the target wasn't in uniform?
2024-04-18 20:05:07 <KipIngram   > :-)
2024-04-18 20:06:28 <KipIngram   > I don't think they ever thought seriously about putting coilguns onto tanks, and that was what I really worked on.  Railguns always got the bulk of the money, though.
2024-04-18 20:06:49 <KipIngram   > As that link implies, ballistic space launch was always the big hope for coilguns.
2024-04-18 20:07:39 <KipIngram   > Every stage of a coilgun needed its own custom power profile, whereas a single rotating machine could power a railgun.
2024-04-18 20:10:12 <KipIngram   > One of the guys here:
2024-04-18 20:10:15 <KipIngram   > https://balconestech.com/about-us
2024-04-18 20:10:43 <KipIngram   > (Joe Beno) was one of the main railgun research guys - he got his  PhD a year or two ahead of me, and then was around for business reasons for a while after.
2024-04-18 20:11:19 <KipIngram   > He was my boss for a little while.  We didn't get on very well, because he was pure Army (West Point grad) and expected me to respond like a soldier.  Somehow that's not in my nature very well.
2024-04-18 20:17:01 <thrig       > damn artists
2024-04-18 20:53:46 <Al2O3       > lol, nice, and cool back story.   TY for sharing.   I always thought railguns were a great idea for launching, but gravity and distance and time are a real challenge.
2024-04-18 20:54:13 <Al2O3       > and resistance, so many factors for deceleration and failure at high speed.
2024-04-18 20:55:00 <Al2O3       > as for a repurposed weapon system, the energy needed and sizing was always better implemented in software in a game called Doom.
2024-04-18 20:55:01 <Al2O3       > :)
2024-04-18 20:56:57 <Al2O3       > speaking of army, and never implementing...
2024-04-18 20:56:58 <Al2O3       > https://nationalinterest.org/blog/buzz/railguns-game-changer-weapon-us-military-never-built-209154
2024-04-18 20:57:35 <Al2O3       > I remember watching videos of this stuff in the 90s or so and thinking, how the hell do you get this down in size to a AR-15 or bazooka type package.
2024-04-18 20:57:53 <Al2O3       > apparently the answer still is you don't.
2024-04-18 20:58:13 <Al2O3       > unless you are a character in the Dune series...
2024-04-18 21:10:06 <KipIngram   > The big hurdle for ballistic launch of any kind is air drag - you're going the fastest right out of the barrel and that's exactly where the atmosphere is thickest.
2024-04-18 21:10:27 <KipIngram   > These guys face the same issue, but are trying:
2024-04-18 21:10:29 <KipIngram   > https://www.spinlaunch.com/
2024-04-18 21:11:33 <KipIngram   > But for mining operations on, say, the moon, or in the asteroid belt?  Electric launchers would be a great way to deliver the mined material around the solar system.
2024-04-18 21:12:10 <KipIngram   > For lunar mining, for example, you could launch stuff so that it barely escaped the moon's gravity and then just "showed up" at an easy to catch speed where you needed it.
2024-04-18 21:13:44 <KipIngram   > I think the "ultimate" Earth-to-space system would be a space elevator, and material science is almost able to pull them off at this point.  But they'd be expensive and if one fell that would be a horrendous disaster.  Great terrorist target.
2024-04-18 21:14:11 <KipIngram   > So we'd want to be... really really sure before we tried that.
2024-04-18 21:15:23 <KipIngram   > I say material science is ready - all I mean by that is that once you had one in place the material strength is getting close to good enough to hold it there.  But BUILDING it?  I don't know - that might be a lot more demanding.
2024-04-18 21:15:42 <thrig       > corruption, cost overruns, etc
2024-04-18 21:16:02 <KipIngram   > I think the way they think of doing that is to start at geosynchronous orbit and gradually extending the thing both down and up, keeping it in balance the whole time.
2024-04-18 21:16:05 <KipIngram   > Daunting.
2024-04-18 21:16:45 <KipIngram   > And that bottom  piece would be subject to wind and so on - up until  you got it anchored things would be really dicey.
2024-04-18 21:17:59 <KipIngram   > But wow - if it could work, the cost of space access would be cut to practically nothing compared to what it is now.
2024-04-18 21:18:21 <KipIngram   > You could run stuff all the way up using electric motors, which are really efficient.
2024-04-18 21:23:01 <hello-operator> Ahoy! I'm trying to do some simple error handling in gforth with throw/catch, super simple stuff
2024-04-18 21:23:07 <hello-operator> : z [ ' throw ] literal catch .s ;
2024-04-18 21:23:29 <hello-operator> And I get the error code I want, but also some random pointer as well
2024-04-18 21:23:44 <hello-operator> In gforth 0.7.3
2024-04-18 21:24:00 <hello-operator> Is this meant to happen?
2024-04-18 21:24:24 <hello-operator> If I throw 4 I'd expect `.s` to just print 4 after calling `z`
2024-04-18 21:25:50 <lf94        > Is throw/catch a gforth thing?
2024-04-18 21:26:29 <thrig       > 9.6.1.2275 THROW
2024-04-18 21:29:29 <hello-operator> Yeah, they're standard words...
2024-04-18 21:32:10 <hello-operator> I've implemented them myself and I'm trying to get the same code working in my forth and gforth, but this random pointer is annoying
2024-04-18 21:50:10 <lf94        > Is the random pointer maybe the return address?
2024-04-18 21:53:09 <GeDaMo      > Isn't the random pointer the xt for throw?
2024-04-18 21:55:18 <GeDaMo      > No, it isn't
2024-04-18 22:00:45 <Al2O3       > KipIngram I remember the nano tube carbon tuff to be a delivery elevator slow speed to eventually get a launch low energy and easy escape.
2024-04-18 22:01:33 <Al2O3       > maybe the 'elevator station' could use old scrap garbage from space orbits (musk trash if you will) and repurpose it.   Space-RRR
2024-04-18 22:01:43 <zelgomer    > hello-operator: in the case of an error, catch restores the stack to the depth it was before catch with undefined values
2024-04-18 22:02:02 <zelgomer    > otherwise you'd have an indeterminate depth and there would be no safe recovery
2024-04-18 22:17:25 <hello-operator> zelgomer: yes it does, but that doesn't explain the value, it's not the xt
2024-04-18 22:32:10 <zelgomer    > it does explain the value. the value is undefined.
2024-04-18 22:32:36 <zelgomer    > it doesn't know how much of the stack was used and clobbered, and it doesn't keep track of it. it just remembers and restores the stack pointer.
2024-04-18 22:37:02 <zelgomer    > "Executes xt. If execution returns normally, catch pushes 0 on the stack. If execution returns through throw, all the stacks are reset to the depth on entry to catch, and the TOS (the xt position) is replaced with the throw code."
2024-04-18 22:37:26 <zelgomer    > hello-operator: when you call z, do you pass it a throw code?
2024-04-18 22:38:12 <zelgomer    > if not, you may be underflowing the parameter stakc
2024-04-18 23:40:31 <hello-operator> No, it doesn't explain it, and yes I pass it the throw code
2024-04-18 23:42:47 <hello-operator> If you type `1 z` you should just get 1 out. I could understand another 1 on there, and in a poorly implemented version you might still get the xt, but this is a random pointer from no where
2024-04-18 23:42:52 <hello-operator> It's different each time
2024-04-18 23:55:35 <zelgomer    > do you see your 1 at all?
2024-04-18 23:55:38 <zelgomer    > post-catch?
2024-04-18 23:58:16 <zelgomer    > i wonder if throw doesn't behave well if there isn't a word between it and catch? that's not really a situation you'd ever see in practice, they may have an unhandled corner case there. maybe try something like   : y  1 throw ;  : z  ['] y catch ;  z  ?
2024-04-18 23:58:48 <zelgomer    > : z  [: 1 throw ;] catch ;  z   ( if gforth has quotations)