2025-10-02 01:03:47 <forthBot    > Environment for cleobuli_ inactive, freeing...
2025-10-02 07:45:51 <user51      > Been thinking about what an ideal programming environment would be to me.  That could easily take a lot of time and not be worth it, but fun to think about at least.  It does have one glaring issue: portability.  Getting it to run on different environments would be one extra bit of work.  And because forth's pretty minimal, I figured that's the right language to start with.
2025-10-02 07:51:04 <tpbsd       > user51, just design one that suits you exactly ?
2025-10-02 07:52:23 <user51      > tpbsd: yep.  but as we should know, it's probably better to adapt to the world rather than making the world adapt to you   :)
2025-10-02 07:52:29 <tpbsd       > user51, I'm finishing my programming environment atm, the last main bit is my cmsis-svd for the editor as it's a forth for stm32 embedded
2025-10-02 07:53:16 <tpbsd       > user51, thats the thing about Forth tho, every one is different
2025-10-02 07:53:21 <user51      > tpbsd: would it be possible to run it on a desktop?
2025-10-02 07:53:49 <tpbsd       > I run my design environment purely on a unix desktop
2025-10-02 07:53:50 <user51      > also, any unique features it might have in comparison to other forths?
2025-10-02 07:54:58 <tpbsd       > sure, it's a embedded Forth for Cortex-M microprocessors and has massive unique features compared to other forths
2025-10-02 07:55:45 <tpbsd       > the Forth is Mecrisp-Stellaris and I didnt design it, Im a electronics tech not a programmer. I just designed the programming environment for it
2025-10-02 07:57:04 <tpbsd       > i have a doc site where I write about Mecrisp-Stellaris and it's probably several years old now https://mecrisp-stellaris-folkdoc.sourceforge.io/
2025-10-02 07:57:27 <tpbsd       > Mecrisp-Stellaris itself came out around 2014
2025-10-02 08:06:07 <tpbsd       > user51, it's changed a bit since this pic, but this is my basic interface  https://chiselapp.com/user/tp/repository/mecrisp-stellaris-lsp/file?name=pics/screenshot.png
2025-10-02 08:06:51 <tpbsd       > it doesnt show the terminal, but thats just a (highly advanced) terminal so nothing to see there
2025-10-02 08:10:07 <user51      > tpbsd: props for sending a screenshot, always baffles me when a github repo doesn't.  these days i'm taking it as a sign i won't be able to build the program  :D
2025-10-02 08:10:49 <tpbsd       > haha, I know what you mean
2025-10-02 08:11:32 <tpbsd       > user51, a lot of github Forth wouldnt build for me, most are just throwaway experiments I think
2025-10-02 08:11:59 <tpbsd       > people make forths because it's so easy compared to other languages, relatively speaking
2025-10-02 08:12:40 <tpbsd       > I used to test all new forths on SF and GH
2025-10-02 08:12:48 <tpbsd       > and few built for me
2025-10-02 08:13:30 <user51      > i've honestly never really wrote a forth, just things superficially resembling it.  practically speaking i think i had the fundamentals but lost interest when i had to write the words that make the program useful.
2025-10-02 08:13:36 <tpbsd       > and some that did were slow and the compiler was terrible
2025-10-02 08:14:20 <tpbsd       > Im 100% pragmatic which is why I only develop embedded on Forth
2025-10-02 08:14:52 <tpbsd       > if I was writing for a PC I'd use C or Lua, or Perl etc
2025-10-02 08:15:07 <tpbsd       > theyre so much easier and made for a PC
2025-10-02 08:16:01 <tpbsd       > if I was better at Forth maybe I'd use RETRO as that's a very nice Forth made for X86
2025-10-02 08:16:44 <tpbsd       > the author uses RETRO like I use Shell
2025-10-02 08:17:25 <tpbsd       > whats more he can use the PC BIOS facilities iirc
2025-10-02 08:17:32 <user51      > yeah, i was thinking that the forth from the user's perspective would be interacting with the high-level parts, and the low-level parts could be written for different environments and that would be "portable".  it sounds fun in theory but  i think in practice might have lots of unexpected complexity.
2025-10-02 08:17:33 <tpbsd       > like a API
2025-10-02 08:18:36 <tpbsd       > Im definitely not a Forth 'implimenter' as you need to be a 'real' programmer for that
2025-10-02 08:19:08 <tpbsd       > Im just a tech that  needed a design environment fopr Mecrisp-Stellaris Forth
2025-10-02 08:44:58 <veltas      > KipIngram: That's exactly like me, working joe for the family, I definitely don't enjoy a 9-to-5 but I do it without question so my family has the resources it needs
2025-10-02 08:45:32 <veltas      > I just need to get them all independent so hopefully I can retire early, which I think most of the engineers around me achieve
2025-10-02 08:46:58 <veltas      > 20+ year plan in the making
2025-10-02 08:47:21 <veltas      > Hopefully in my late 50s that seems feasible
2025-10-02 08:49:53 <veltas      > user51: I've really learned it the hard way in Forth but it really applies everywhere that code reuse is hard to get right
2025-10-02 08:50:35 <veltas      > 'Portable' code often is fine if it's just porting in the same kind of environment, but depending on support platforms and applications it's an incredible amount of effort and not worth it
2025-10-02 08:50:59 <veltas      > And likewise reusable code that does one 'job' might not be able to do that same job in a different application
2025-10-02 08:51:08 <veltas      > And you shouldn't try to make them fit
2025-10-02 08:51:29 <veltas      > Or you end up with something nobody understands that runs bad and was more work than writing it twice in those two places
2025-10-02 08:52:08 <veltas      > And yet you *shouldn't* reinvent the wheel constantly, don't start any task by writing a programming language
2025-10-02 08:54:04 <veltas      > Also I think git has taught people not to copy+paste code where it's needed, but sometimes that's better than trying to keep what you want from one library/program 'separate'
2025-10-02 08:56:44 <user51      > veltas: oh come on now, that's hard to disagree with :) i've got a strong feeling that most of the work could be theoretically done BUT good luck getting the rest of it to work.  fun to think, not to do :D
2025-10-02 09:02:42 <tpbsd       > my system works with hundreds of different mcu's, basically any Cortex-M, the SVD file for it just has to be named in the makefile
2025-10-02 09:03:27 <tpbsd       > but thats only because ARM was smart enough to design the SVD concept
2025-10-02 12:12:29 <vms14       > this is a test for drawing stuff relative to the player in gforth using ncurses
2025-10-02 12:12:34 <vms14       > https://termbin.com/5yne
2025-10-02 12:13:09 <vms14       > and the curses.fs file https://termbin.com/6zuq
2025-10-02 12:13:44 <vms14       > seems to work properly so i should add enemies and stuff
2025-10-02 12:14:06 <vms14       > i have yet to learn forth
2025-10-02 12:16:11 <vms14       > that file was a wrong one, it's missing a rot, this is the real one xd
2025-10-02 12:16:15 <vms14       > https://termbin.com/83si
2025-10-02 12:19:29 <vms14       > i should avoid those 2 swaps by changing the order of the first two lines
2025-10-02 12:35:13 <KipIngram   > veltas: Yes; back in the late 1990's / very early 2000's I had a job that I attached an unhealthy amount of "self definition" to, but that passed in time and for the last couple of decades it's really just been a means to an end, just as you say.
2025-10-02 12:36:31 <KipIngram   > I was just content to have a job I "didn't dislike" - it was fine, but was no longer "who I was."
2025-10-02 12:37:04 <KipIngram   > So I'm finding it very easy to just let go of.
2025-10-02 12:55:52 <veltas      > tpbsd: However the system is meant for ARM chips of a certain size, not e.g. desktop computing
2025-10-02 12:55:59 <veltas      > That's the point I'm making really
2025-10-02 12:56:03 <veltas      > And that's not a bad thing
2025-10-02 12:56:07 <veltas      > It's the right tradeoff
2025-10-02 12:57:57 <veltas      > KipIngram: My day job is literally part of who I am, but if I lose this job then I can still get another job (hopefully?)
2025-10-02 12:58:04 <veltas      > Whether I enjoy the grind or not
2025-10-02 12:58:14 <veltas      > We gotta do what we gotta do etc
2025-10-02 13:30:20 <KipIngram   > Yep.
2025-10-02 13:32:15 <KipIngram   > I'd actually planned on staying a couple more years, but a few months ago a senior executive over my office retired, and the new guy's policies weren't really to my liking, so I just decided to go ahead.  I was in a mode where it was "optional."  Given the new situation retirement held more appeal.
2025-10-02 13:38:35 <KipIngram   > I've actually started work on the new Forth system, with all this newfound time on my hands.  I'm trying to write it as a "meta source" file, that I'll process into an assembly file using Python and then assemble.  But the goal is for the system to later also be able to meta compile that same source file.  Ideally with no changes at all, but it won't surprise me if a few small changes wind up being
2025-10-02 13:38:37 <KipIngram   > required.
2025-10-02 13:41:08 <KipIngram   > The assembly parts will just get copied from the meta file to the assembler output, but one nice thing about having the Python in the middle is that I can lay those assembly instructions out horizontally.  Simple example:
2025-10-02 13:41:11 <KipIngram   > ~: dup   {}          sub rrSP, 8 ~ mov [rrSP], rrTOS ~;
2025-10-02 13:41:39 <KipIngram   > The {} is a place where jump table offsets could go - if none are specified the Python just increments to the next table slot.
2025-10-02 13:42:36 <KipIngram   > The register aliasing is earlier on.
2025-10-02 13:43:13 <KipIngram   > And then the Forth definitions just look completely normal - the Python will interpret them just as a Forth compiler would.
2025-10-02 13:56:31 <KipIngram   > This one's being planned from the ground up to support multiple processes.  A process might be fat and full featured, or it might be lean / green - it just allocates the RAM resources it'll need for whatever its intended use is.  I'm trying to wind up with something that can support Erlang-level multiprocessing if I want to.
2025-10-02 13:57:45 <KipIngram   > And also something that I can run under Linux or boot using UEFI as a stand-alone thing.  With support for frame buffer graphics either way.
2025-10-02 13:58:41 <KipIngram   > Under Linux it'll use SDL2 to get a frame buffer, and in that context will be able to do more advanced GPU things as well.
2025-10-02 14:00:43 <KipIngram   > I'll start out with normal keystroke input, but eventually I want to work with key press/release events (SDL2 can offer that, but in the UEFI context it'll require writing code to directly access the keyboard controller).
2025-10-02 14:01:29 <KipIngram   > But it'll let me use things like shift or control key double taps, keyboard chording, and so on.
2025-10-02 14:19:13 <veltas      > Why SDL2?
2025-10-02 14:19:34 <veltas      > Although I can't explain why they decided to break so much for SDL3 but it's easy to upgrade
2025-10-02 15:56:13 <KipIngram   > Oh, well, just because SDL2 is what I read up on - SDL3 might turn out better.
2025-10-02 15:56:32 <KipIngram   > I didn't even know SDL3 was out there.
2025-10-02 16:13:03 <vms14       > i'm trying to make the enemies
2025-10-02 16:13:07 <vms14       > https://termbin.com/htoa
2025-10-02 16:13:50 <vms14       > now in enemy behavior i should add a way to draw the enemy if it's visible, move it towards the player and perform collision detection
2025-10-02 16:14:20 <KipIngram   > How are you doing the physics?  How realistically?
2025-10-02 16:14:35 <vms14       > KipIngram: it's a clone of a vampire survivor game
2025-10-02 16:14:42 <vms14       > there are no physics
2025-10-02 16:15:04 <vms14       > the player moves around the world and enemies move towards the player dealing damage on contact
2025-10-02 16:15:18 <vms14       > player skills autolaunch so the player has to move
2025-10-02 16:16:11 <vms14       > what i need is a way to make timed actions, like mantain some data structure with a queue of actions associated with a timestamp and check if they timeout to execute them and optionally remove them from the queue
2025-10-02 16:17:32 <vms14       > i plan to reuse the enemies this is why i ignore the ones with no life, one of those timed actions will have to resurrect them and move them in a random location
2025-10-02 16:18:26 <vms14       > skills have a cooldown and they have to evolve, deal more damage, change it's behavior and reduce the cooldown
2025-10-02 16:19:06 <vms14       > no idea yet how to do represent them, but sounds like fun