IRC Log - 2025-12-06 - ##forth

Channel: ##forth
Total messages: 38
Time range: 02:01:14 - 19:07:55
Most active: tpbsd (20), MrMobius (6), veltas (4)
02:01:14 ##forth <MrMobius> tpbsd: does nixos have the same packages as Ubuntu?
02:06:33 ##forth <tpbsd> MrMobius, pretty much, it has a enormous selection, but sxeems a bit thin with embedded
02:07:33 ##forth <tpbsd> MrMobius, it seems to have the MSP430 stuff
02:08:15 ##forth <tpbsd> MrMobius, it has the stlink stuff
02:09:32 ##forth <tpbsd> MrMobius, ahh here it is "gcc-arm-embedded-13"
02:09:39 ##forth <tpbsd> that has all the eabi stuff
02:14:12 ##forth <MrMobius> ya confusingly the various GCCs have a different name once installed than the package
02:14:52 ##forth <tpbsd> hmm, it doesnt seem to have everything
02:15:15 ##forth <MrMobius> I'm guessing that's the old 4.6 GCC for msp430 not the newer and incompatible 9.3 that TI commissioned
02:15:21 ##forth <tpbsd> I'll still install freebsd-15 on my spare pc, see how that goes
02:16:57 ##forth <tpbsd> dont know, it doesnt say
02:19:23 ##forth <MrMobius> One day I'll figure out the 6 or so different ways they've given us to program them in C. It's very confusing
02:22:45 ##forth <tpbsd> it is
02:23:45 ##forth <tpbsd> they only have various GCC versions but also differennt libraries ranging from open to STMlibs etc
02:24:10 ##forth <tpbsd> I think the libs are the confusing part
02:24:30 ##forth <tpbsd> as they supply the headers and includes oplus the API docs etc
02:24:50 ##forth <tpbsd> I think that C is just not well suited for embedded dev
02:25:11 ##forth <tpbsd> it's great for PC apps however
02:26:13 ##forth <tpbsd> Forth is far better suited for embedded as long as you can easily access the peripheral configs, and thats what FURS provides
02:27:17 ##forth <tpbsd> sure C provides smaller and faster binaries than Forth, no question, but the dev cycle is a pain
02:27:35 ##forth <tpbsd> (embedded)
03:59:43 ##forth <MrMobius> It's more manageable if they give you one thing to download and then that's it. ST did this last I checked. MicroChip used to make it harder but are more like ST now I think
04:00:14 ##forth <MrMobius> Also without charging for your shitty IDE
04:12:18 ##forth <tpbsd> last I tried, microchip was all windows or java for Linux
04:12:50 ##forth <tpbsd> I couldnt even build a flashforth kernel and gave up after a couple of days
04:14:26 ##forth <tpbsd> Ive given up on microchip now, ST has by far the better product especially in the 'G ' series STM32 imho
08:59:23 ##forth <smlckz> i've not written so much forth before, please take a look: https://0x0.st/KvPZ.fth
09:00:52 ##forth <smlckz> is there an ans forth way of making that word q work at compile time as well?
10:05:59 ##forth <veltas> smlckz: make q IMMEDIATE and check STATE and then either do current behaviour or POSTPONE POSTPONE the words
10:07:36 ##forth <veltas> I'm not 100% sure what you need to know since a lot is going on here but maybe that will help point you in right direction
10:10:11 ##forth <veltas> You've also got COMPILE, and EXECUTE to work with, might need to FIND your defs and check whether they're immediate etc
10:10:22 ##forth <veltas> Since you're doing a lot of the parsing yourself
13:41:57 ##forth <cleobuline> !uptime
13:41:58 ##forth <LispBot860> 124h 42min 28s
16:14:46 ##forth <smlckz> veltas: i am thinking of allocating the string and store the pointer and length that will be loaded at runtime of the word being compiled that called q
16:22:15 ##forth <[[smlckz]]> so POSTPONE LITERAL is it?
19:06:49 ##forth <[[smlckz]]> So it turns out like this http://0x0.st/KvAu.fth
19:07:55 ##forth <[[smlckz]]> Any suggestions to make the code better, more idiomatic (I wonder if that's a thing in Forth at all)?