01:03:47
##forth
<forthBot>
Environment for cleobuli_ inactive, freeing...
07:45:51
##forth
<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.
07:51:04
##forth
<tpbsd>
user51, just design one that suits you exactly ?
07:52:23
##forth
<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 :)
07:52:29
##forth
<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
07:53:16
##forth
<tpbsd>
user51, thats the thing about Forth tho, every one is different
07:53:21
##forth
<user51>
tpbsd: would it be possible to run it on a desktop?
07:53:49
##forth
<tpbsd>
I run my design environment purely on a unix desktop
07:53:50
##forth
<user51>
also, any unique features it might have in comparison to other forths?
07:54:58
##forth
<tpbsd>
sure, it's a embedded Forth for Cortex-M microprocessors and has massive unique features compared to other forths
07:55:45
##forth
<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
07:57:27
##forth
<tpbsd>
Mecrisp-Stellaris itself came out around 2014
08:06:51
##forth
<tpbsd>
it doesnt show the terminal, but thats just a (highly advanced) terminal so nothing to see there
08:10:07
##forth
<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
08:10:49
##forth
<tpbsd>
haha, I know what you mean
08:11:32
##forth
<tpbsd>
user51, a lot of github Forth wouldnt build for me, most are just throwaway experiments I think
08:11:59
##forth
<tpbsd>
people make forths because it's so easy compared to other languages, relatively speaking
08:12:40
##forth
<tpbsd>
I used to test all new forths on SF and GH
08:12:48
##forth
<tpbsd>
and few built for me
08:13:30
##forth
<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.
08:13:36
##forth
<tpbsd>
and some that did were slow and the compiler was terrible
08:14:20
##forth
<tpbsd>
Im 100% pragmatic which is why I only develop embedded on Forth
08:14:52
##forth
<tpbsd>
if I was writing for a PC I'd use C or Lua, or Perl etc
08:15:07
##forth
<tpbsd>
theyre so much easier and made for a PC
08:16:01
##forth
<tpbsd>
if I was better at Forth maybe I'd use RETRO as that's a very nice Forth made for X86
08:16:44
##forth
<tpbsd>
the author uses RETRO like I use Shell
08:17:25
##forth
<tpbsd>
whats more he can use the PC BIOS facilities iirc
08:17:32
##forth
<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.
08:17:33
##forth
<tpbsd>
like a API
08:18:36
##forth
<tpbsd>
Im definitely not a Forth 'implimenter' as you need to be a 'real' programmer for that
08:19:08
##forth
<tpbsd>
Im just a tech that needed a design environment fopr Mecrisp-Stellaris Forth
08:44:58
##forth
<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
08:45:32
##forth
<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
08:46:58
##forth
<veltas>
20+ year plan in the making
08:47:21
##forth
<veltas>
Hopefully in my late 50s that seems feasible
08:49:53
##forth
<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
08:50:35
##forth
<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
08:50:59
##forth
<veltas>
And likewise reusable code that does one 'job' might not be able to do that same job in a different application
08:51:08
##forth
<veltas>
And you shouldn't try to make them fit
08:51:29
##forth
<veltas>
Or you end up with something nobody understands that runs bad and was more work than writing it twice in those two places
08:52:08
##forth
<veltas>
And yet you *shouldn't* reinvent the wheel constantly, don't start any task by writing a programming language
08:54:04
##forth
<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'
08:56:44
##forth
<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
09:02:42
##forth
<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
09:03:27
##forth
<tpbsd>
but thats only because ARM was smart enough to design the SVD concept
12:12:29
##forth
<vms14>
this is a test for drawing stuff relative to the player in gforth using ncurses
12:13:44
##forth
<vms14>
seems to work properly so i should add enemies and stuff
12:14:06
##forth
<vms14>
i have yet to learn forth
12:16:11
##forth
<vms14>
that file was a wrong one, it's missing a rot, this is the real one xd
12:19:29
##forth
<vms14>
i should avoid those 2 swaps by changing the order of the first two lines
12:35:13
##forth
<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.
12:36:31
##forth
<KipIngram>
I was just content to have a job I "didn't dislike" - it was fine, but was no longer "who I was."
12:37:04
##forth
<KipIngram>
So I'm finding it very easy to just let go of.
12:55:52
##forth
<veltas>
tpbsd: However the system is meant for ARM chips of a certain size, not e.g. desktop computing
12:55:59
##forth
<veltas>
That's the point I'm making really
12:56:03
##forth
<veltas>
And that's not a bad thing
12:56:07
##forth
<veltas>
It's the right tradeoff
12:57:57
##forth
<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?)
12:58:04
##forth
<veltas>
Whether I enjoy the grind or not
12:58:14
##forth
<veltas>
We gotta do what we gotta do etc
13:30:20
##forth
<KipIngram>
Yep.
13:32:15
##forth
<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.
13:38:35
##forth
<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
13:38:37
##forth
<KipIngram>
required.
13:41:08
##forth
<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:
13:41:11
##forth
<KipIngram>
~: dup {} sub rrSP, 8 ~ mov [rrSP], rrTOS ~;
13:41:39
##forth
<KipIngram>
The {} is a place where jump table offsets could go - if none are specified the Python just increments to the next table slot.
13:42:36
##forth
<KipIngram>
The register aliasing is earlier on.
13:43:13
##forth
<KipIngram>
And then the Forth definitions just look completely normal - the Python will interpret them just as a Forth compiler would.
13:56:31
##forth
<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.
13:57:45
##forth
<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.
13:58:41
##forth
<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.
14:00:43
##forth
<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).
14:01:29
##forth
<KipIngram>
But it'll let me use things like shift or control key double taps, keyboard chording, and so on.
14:19:13
##forth
<veltas>
Why SDL2?
14:19:34
##forth
<veltas>
Although I can't explain why they decided to break so much for SDL3 but it's easy to upgrade
15:56:13
##forth
<KipIngram>
Oh, well, just because SDL2 is what I read up on - SDL3 might turn out better.
15:56:32
##forth
<KipIngram>
I didn't even know SDL3 was out there.
16:13:03
##forth
<vms14>
i'm trying to make the enemies
16:13:50
##forth
<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
16:14:20
##forth
<KipIngram>
How are you doing the physics? How realistically?
16:14:35
##forth
<vms14>
KipIngram: it's a clone of a vampire survivor game
16:14:42
##forth
<vms14>
there are no physics
16:15:04
##forth
<vms14>
the player moves around the world and enemies move towards the player dealing damage on contact
16:15:18
##forth
<vms14>
player skills autolaunch so the player has to move
16:16:11
##forth
<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
16:17:32
##forth
<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
16:18:26
##forth
<vms14>
skills have a cooldown and they have to evolve, deal more damage, change it's behavior and reduce the cooldown
16:19:06
##forth
<vms14>
no idea yet how to do represent them, but sounds like fun