2026-04-24 02:03:32 <tpbsd       > veltas, the beez feels that fprthers who want local variables dont really know how to program in Forth
2026-04-24 02:05:04 <tpbsd       > KipIngram, if the interrupt handler is short, then the square wave will be offset by the handler time taken I think
2026-04-24 04:00:02 <KipIngram   > Well, in an uncontrolled environment you can't be sure of getting the same number of interrupts each cycle, or the same mix of interrupts if there's more than one kind, etc.
2026-04-24 04:00:57 <KipIngram   > You're right that if you were sure of those things, and controlled them, then all you'd do would be to change the period a little.  Provided the ISRs ran the same way every time and didn't have variant timing depending on conditionals and so on.
2026-04-24 04:01:42 <KipIngram   > I think the main point I'm trying to make is that in an effort to make this all as easy for people to use as possible, a lot of those details that you'd need to control are just outright hidden from the users.
2026-04-24 04:02:17 <KipIngram   > And likely most of the people who wrote the interrupt handlers in a lot of these systems weren't thinking in terms of real time performance anyway.
2026-04-24 04:11:06 <KipIngram   > I mean, ultimately these things run on precision oscillators, and are entirely deterministic.  You CAN do extremely precise timing, just using instruction execution, unless that predictability has been given up somehow.  And that's what we used to do - very often in the early years I'd pull out the processor handbook and count up instruction cycles, and know EXACTLY how long it would take bits of
2026-04-24 04:11:09 <KipIngram   > my code to run.
2026-04-24 04:11:34 <KipIngram   > But cache memories take that exactness away.  Interrupts that you aren't totally on top of take it away.  Etc.
2026-04-24 04:12:01 <KipIngram   > Specultive execution, branch prediction, etc. etc.  All those things introduce imprecision.
2026-04-24 04:15:17 <tabemann    > sigh
2026-04-24 04:15:44 <tabemann    > the RP2350 RISC-V interrupt model makes me not want to port zeptoforth to target it
2026-04-24 04:16:50 <tabemann    > you either have to use the RP2350's Hazard3-specific interrupt controller, that won't port to any other RISC-V platforms, or a very basic PLIC implementation that gives you a total of three interrupts, with all the IRQ's mapped onto a single interrupt
2026-04-24 04:37:14 <tpbsd       > KipIngram, youre so right! while I don't know all the finer points of modern cpus, I didn't need to when my scope showed me the variations in timing of a mcu generated squarwave. It was obvious that intermittent things were going on to vary the repetitiveness of the GPIO instructions
2026-04-24 07:45:23 <veltas      > tpbsd: I still haven't gotten a chance to watch the whole thing but I think I disagree, although 'local' vars aren't necessary usually
2026-04-24 07:45:51 <veltas      > In embedded I think it's easier to not worry because there's inherently more global state anyway
2026-04-24 07:46:24 <veltas      > But there are real problems that are hard in forth because of the stack, and variables make it much easier to do it
2026-04-24 07:47:24 <veltas      > But I don't see why needing vars makes Forth 'dead' or likewise I've never bought the Rather position that you don't need variables in forth words if you refactor and keep it simple
2026-04-24 09:23:35 <tpbsd       > Im with Elizabeth Rather on the issue
2026-04-24 09:24:49 <tpbsd       > tabemann, thats the thing, once you have written a Forth for one mcu, then you have written a Forth for *one* mcu :)
2026-04-24 09:59:33 <veltas      > I do agree with his conclusion that you should just write C instead if you don't like that stuff
2026-04-24 09:59:55 <veltas      > And that if you use locals a significant amount then you're not really writing Forth, you're just writing integer C
2026-04-24 10:04:35 <veltas      > And the "hex words"... I suspect that meant they were writing pre-built Forth code in an assembler, rather than interactive Forth
2026-04-24 10:04:48 <veltas      > I wonder if they even used Forth interactively, might be why they hated it so much if not!
2026-04-24 10:05:17 <veltas      > Who knows
2026-04-24 10:06:35 <veltas      > One of the main reasons I don't always split into really small words is because I am tired of coming up with names for all these words, you usally have to split so much that you run out of synonyms
2026-04-24 10:06:37 <tpbsd       > veltas, the Forth hate is strong!
2026-04-24 10:07:36 <veltas      > It's a little unfair that Forth gets commented on a lot by people that had to write it for one thing, and never wrote it before.  I mean if C was judged by people with zero C experience...
2026-04-24 10:09:07 <tpbsd       > exactly
2026-04-24 10:11:11 <veltas      > Like there was a guy who made a Forth CPU, not having experience in Forth or CPU design, and then complained that it was a bad architecture and suggested Forth was fundamentally no good
2026-04-24 10:15:45 <tpbsd       > hahah
2026-04-24 10:16:18 <veltas      > In his article this is one word he struggled with, and I was going to say "and I'd struggle to refactor it too", but actually already I can see issues with it https://pastebin.com/raw/PHnuT9Q3
2026-04-24 10:16:31 <veltas      > Like he calculates mean and then also std, why not split that out?
2026-04-24 10:17:17 <veltas      > I still believe there are words you can't really simplify in a nice way, but this isn't one of them, maybe he hoped no Forth programmers would read the article or was oblivious to his inexperience
2026-04-24 10:19:10 <veltas      > https://www.yosefk.com/blog/my-history-with-forth-stack-machines.html
2026-04-24 10:19:14 <tpbsd       > Id have to totally rerwrite that with a number of Words, each with three lines or so, and lots of comments
2026-04-24 10:19:55 <tpbsd       > the fact that he wote it all in one word seems to have a strong C background to me
2026-04-24 10:23:19 <veltas      > It's not really C, it's any normal procedural language.  Like I'd expect same from Fortran, Pascal etc backgrounds
2026-04-24 10:23:35 <veltas      > But yeah they're thinking "I *should* be able to write this function, I could write it in C"
2026-04-24 10:23:44 <veltas      > And haven't adapted to Forth at all
2026-04-24 10:24:11 <veltas      > And for those of us that learned e.g. C first that takes time and experience to learn
2026-04-24 10:27:41 <tpbsd       > I learned basic, pascal, C, Perl before Forth myself
2026-04-24 10:29:04 <tpbsd       > but I started learning Forth in 2014, I think Forth takes a long time before that 'aha' moment
2026-04-24 10:29:25 <tpbsd       > and I was very reluctant and slow with Forth myself
2026-04-24 10:31:03 <tpbsd       > I decided right at the start that if Forth didnt have irrestible features over C, that I'd stay with C for embedded
2026-04-24 10:42:15 <veltas      > I still don't really feel like I'm at the 'aha' moment but like a pig returning to its slop I often return to Forth
2026-04-24 10:42:30 <tpbsd       > hahah
2026-04-24 10:42:50 <tpbsd       > it took 3 years + before the 'aha' moment happened for me
2026-04-24 10:43:23 <veltas      > To me the big advantage of Forth is it's really tiny for an IDE
2026-04-24 10:43:57 <veltas      > That means hacking it is easy for stupid people like me, and also it's maintainable by one person, and it can fit in small devices
2026-04-24 10:44:12 <veltas      > And it's extensible too
2026-04-24 10:44:16 <tpbsd       > it began for me after reading 'thinking Forth
2026-04-24 10:45:58 <tpbsd       > it started me thinking about problem solving from a Forth perspective
2026-04-24 14:27:10 <KipIngram   > For me it was two book.  Thinking Forth was definitely one of them - while it's a "Forth book" it also feels like a *programming* book to me.  The ideas it talks about seem applicable to lots of languages, but Forth "harnesses" them most beautifully as far as I'm concerned.  And then (earlier on) there was "Forth Fundamentals" by McCabe (volume 1 particularly).  It laid out the internals of Forth
2026-04-24 14:27:13 <KipIngram   > (generally FIG Forth) in a way that really exhibits how simple and easy to put together a Forth system can be.  Gets you "under the hood."
2026-04-24 14:28:18 <KipIngram   > FF v1 was my real "aha" moment - prior to that I "liked" Forth but didn't really have a clear picture of how truly simple and elegant it actually was.  I mostly just liked it because it was RPN like my calculator.  But after reading that I truly APPRECIATED it.
2026-04-24 14:28:27 <KipIngram   > I'd say that's when I started to "love" Forth.
2026-04-24 14:28:43 <KipIngram   > And regard it as "special."
2026-04-24 14:30:01 <KipIngram   > I actually wrote a Forth before reading FF v1, but after the read I recognized how poor my effort had been.
2026-04-24 14:30:34 <tpbsd       > heh
2026-04-24 14:30:40 <KipIngram   > It "worked," but I'd done so many things in a totally wrong way that failed to capitalize on all of the potential for interlocking simplicities.
2026-04-24 14:35:55 <KipIngram   > So you might say that those two book are about "how" Forth works (FF v1) and "why it matters" (Thinking Forth).  How you get it and why you want it.
2026-04-24 14:36:58 <tpbsd       > I think it's different for different people, but they all have that special 'aha' moment with forth. Until that point, people are still undecided
2026-04-24 14:37:38 <tpbsd       > if someone hasnt had it yet, I think they have yet to cross that line
2026-04-24 14:37:58 <KipIngram   > Yeah, that makes sense.  It's a little like converting to a religion. ;-)
2026-04-24 14:38:18 <tpbsd       > like C users who are convinced Forth needs local variables, I don't think they get it yet
2026-04-24 14:39:44 <tpbsd       > such people think the Forth stack is a hassle and that local variables make the Forth experience better
2026-04-24 14:40:06 <veltas      > They're right about one thing :P
2026-04-24 14:41:59 <KipIngram   > https://imgur.com/a/AVEW3qU
2026-04-24 14:45:49 <tpbsd       > hehe, I saw that one
2026-04-24 14:48:25 <KipIngram   > It's from a Hans Bezzemer video (though who knows where he got it).
2026-04-24 14:49:29 <KipIngram   > I generally agree with Chuck that every effort should be made no just never need more than the top 2-3 items on the stack, and that a *lot* of the time you can do that if you're smart about it.
2026-04-24 14:49:44 <KipIngram   > I'm not convinced you can ALWAYS do it, though.
2026-04-24 14:50:03 <KipIngram   > And when you can't - say you need five or so instead - Forth does get kind of cumbersome.
2026-04-24 14:50:15 <KipIngram   > I've never felt the need to be able to refer to such things by NAME, though.
2026-04-24 14:51:05 <KipIngram   > I compromised - I gave myself fast primitives for loading from or storing to the top 5-6 items, and use them when I just can't figure out anything else that doesn't feel overly messy.
2026-04-24 14:51:17 <tpbsd       > I've needed 5 before, it just took some doodling to sort it out
2026-04-24 14:51:32 <KipIngram   > I needed them for EXPECT.
2026-04-24 14:52:22 <KipIngram   > Because I wanted my EXPECT to be fairly powerful - I wanted its innards to support editing an already non-empty string buffer, with the ability to start out with the cursor anywhere in the initial string.
2026-04-24 14:52:43 <KipIngram   > And I was supporting UTF8, so "cursor position" and "offset into buffer" became two separate data items.
2026-04-24 14:53:02 <KipIngram   > An EXPECT component that can do that supports easy deployment of a screen editor.
2026-04-24 14:53:05 <tpbsd       > i wrote about it once: https://mecrisp-stellaris-folkdoc.sourceforge.io/visualising-stack.html
2026-04-24 14:53:19 <KipIngram   > EXPECT itself just wrappers an "empty initial string" wrapper around it.
2026-04-24 14:54:46 <KipIngram   > It got even worse when I wrapped that in QUERY, because I wanted it to support command history.
2026-04-24 14:55:18 <KipIngram   > So position in the command history got tossed in as well.
2026-04-24 14:56:25 <KipIngram   > You wind up with 5-6 things to juggle, and you're not too far away from needing them all at more or less the same time.
2026-04-24 14:56:44 <tpbsd       > I'm finally working out how to script GIT with access by SSH for my new web  Qucs-s based schematic sharing system
2026-04-24 14:57:30 <tpbsd       > why is everything github so hard ?
2026-04-24 14:57:50 <tpbsd       > I just know it's because microsoft
2026-04-24 14:57:58 <KipIngram   > If you asked them they'd probably say "security."  That seems to be the usual answer for why things aren't simple and easy.
2026-04-24 14:58:05 <tpbsd       > yeah
2026-04-24 14:59:32 <KipIngram   > Why won't Wayland let SDL2 open windows exactly where you want them on the screen?  "Security - and you're an audacious twit for even asking."
2026-04-24 14:59:52 <veltas      > EXPECT is relatively simple yet hard even for KipIngram to write without psuedo-vars, well that's what I'm talking about
2026-04-24 15:00:01 <veltas      > String ops are especially nasty, with multiple strings
2026-04-24 15:00:26 <KipIngram   > Yeah, I really don't like introducing permanent items into the dictionary when they're used for transient storage like that.
2026-04-24 15:00:30 <veltas      > But if someone is always reaching for local vars they're doing it wrong -- sure
2026-04-24 15:00:39 <KipIngram   > See, that's precisely what WOULD make someone want local vars.
2026-04-24 15:00:59 <KipIngram   > It's transient data, and the place for transient data is the stack, not the dictionary.
2026-04-24 15:01:04 <tpbsd       > Forth is terrible with strings, but then strings are verboten with small embedded
2026-04-24 15:01:26 <KipIngram   > And yet if you're trying to do anything even a little general purpose, they're one of the first things you need.
2026-04-24 15:01:34 <tpbsd       > strings are strictly for PC forths
2026-04-24 15:01:59 <tpbsd       > strings are never needed for small embedded
2026-04-24 15:01:59 <KipIngram   > Forth is generally poor with "structured data" (by which I mean anything that's not "a cell").
2026-04-24 15:02:13 <KipIngram   > No, but I want to do more than small embedded.
2026-04-24 15:02:24 <KipIngram   > I want to write an OS, basically.
2026-04-24 15:02:30 <tpbsd       > small embedded is about switches,relays, delays, ADC, timers/counters etc
2026-04-24 15:02:43 <veltas      > The interpreter uses strings
2026-04-24 15:02:52 <KipIngram   > An environment I can live in to do everything I do, from small embedded right on up to scientific programming.
2026-04-24 15:03:03 <veltas      > That's about it though, interpreter and word names
2026-04-24 15:03:38 <tpbsd       > KipIngram, yeah, same as tabermann with his zeptoforth, he needs a Cortex-M0+ like the RP*
2026-04-24 15:04:24 <tpbsd       > sure, it has to have some for the terminal
2026-04-24 15:04:26 <KipIngram   > Things I do today with bash scripts - I want the Forth to be handling that too.
2026-04-24 15:04:31 <tpbsd       > but theyre very limited
2026-04-24 15:05:28 <KipIngram   > I've had to munge around strings / text data a lot for the programming I did at work over the years, and I became very fond of how easy Python makes it.  I want that kind of ease of string handling, but in Forth.
2026-04-24 15:05:36 <tpbsd       > I used a few strings in my Bluepill Diags also, but very limited as strings waste so much flash space
2026-04-24 15:06:13 <tpbsd       > when you only have 64KB flash, you can't have many strings
2026-04-24 15:07:34 <tpbsd       > KipIngram, do you also want the 30x speed penality of python compared to Forth on the same hardware at the same clock ?
2026-04-24 15:08:36 <tpbsd       > KipIngram, not to mention ptyhon needs at least 200KB+ to run on a mcu
2026-04-24 15:08:55 <tpbsd       > KipIngram, compared to 20KB total for Mecrisp-Stellaris
2026-04-24 15:11:04 <KipIngram   > No, of course not (re: the 30x speed decrease).  :-)
2026-04-24 15:11:31 <KipIngram   > But, it was work, and what was important at the time was speed of delivering the working code, more than speed of the code running.
2026-04-24 15:12:00 <tpbsd       > KipIngram, at least python gives you a REPL
2026-04-24 15:12:04 <KipIngram   > Typically I'd be given some equipment for doing some sort of testing and then it would be "we need these results day before yesterday."
2026-04-24 15:12:46 <tpbsd       > it's amazing how incredibly popular python is thesedays
2026-04-24 15:13:23 <tpbsd       > except with me
2026-04-24 15:13:52 <tpbsd       > Ive always had trouble deploying it, version issues etc
2026-04-24 15:13:55 <KipIngram   > I wouldn't say it's "popular" with me - I just recognize one or two nice things it can do.
2026-04-24 15:14:16 <tpbsd       > and FreeBSD is like "DONT USE PIP!!" if I try to
2026-04-24 15:14:43 <KipIngram   > It's also fairly remarkable how many different packages for various things exist, and while I'm philosophically opposed to just dropping black box modules into software, it didn't stop me from using it when I was under time pressure at the office.
2026-04-24 15:15:08 <veltas      > It's funny you say Python because Python has probably had the worst experience for strings I've seen
2026-04-24 15:15:18 <veltas      > Like I'd rather use C than Python
2026-04-24 15:15:25 <KipIngram   > tpbsd: For small embedded I'm 100% on board with you - there's no contender that even comes close to matching Forth.
2026-04-24 15:16:19 <veltas      > Hey what's funny KipIngram is the times where I've saved time by *not* using a black box, or removing a black box
2026-04-24 15:16:46 <veltas      > I realised to parse an XML file for something that it was going to be *more code* (not including library) to use libexpat than to parse it myself
2026-04-24 15:17:09 <tpbsd       > KipIngram, apart from Basic, memory wise, but I don't like it at all
2026-04-24 15:17:24 <KipIngram   > Yeah, I quite often would just do things myself.  So many of the pre-bundled things do about 50x what you need.
2026-04-24 15:17:35 <KipIngram   > We were talking about that a week ago or so re: getopt.
2026-04-24 15:17:41 <KipIngram   > I've just never used it.
2026-04-24 15:18:15 <veltas      > getopt isn't more code it's just a lot worse and more confusing than parsing it manually
2026-04-24 15:18:31 <veltas      > But I'm wrong about this apparently
2026-04-24 15:18:47 <KipIngram   > Usually when I did use a package it was usually for something that would have required a huge learning curve for me, like "make a pdf file" or something.
2026-04-24 15:19:00 <veltas      > But then e.g. malloc() is better than no malloc().
2026-04-24 15:19:54 <KipIngram   > Oh, there's another area where vanilla Forth usually doesn't shine.  Memory management.
2026-04-24 15:20:12 <veltas      > People hate the stdio.h streams but they're actually good
2026-04-24 15:20:20 <veltas      > They do exactly what's needed
2026-04-24 15:20:28 <veltas      > Forth's file words are horrid
2026-04-24 15:20:32 <KipIngram   > I think Forth is optimal when your computer system has one job to do, and you just lay out the resources for doing it in the dictionary and... do it.
2026-04-24 15:20:58 <KipIngram   > When you have an unpredictable mix of tasks starting and stopping, in random order, and so on - traditional Forth really isn't set up for that.
2026-04-24 15:21:01 <tpbsd       > KipIngram, vanilla Forth is almost useless in small embedded I have found
2026-04-24 15:21:43 <tpbsd       > vanilla Forth lacks the specific chip headers and includes that C has
2026-04-24 15:22:13 <tpbsd       > which is probably why no one uses modern mcu's with Forth now
2026-04-24 15:22:26 <tpbsd       > it's simply too hard
2026-04-24 15:23:14 <KipIngram   > Yeah, I'm going to be facing that task for this ESP32.  There's a gazillion processor registers out there, and I'll be having to identify the address for all of them.
2026-04-24 15:23:19 <KipIngram   > Eventually.
2026-04-24 15:23:39 <KipIngram   > The information for it IS in the tech ref, but it's spread about in a bit of an obtuse way.
2026-04-24 15:23:47 <tpbsd       > yeah, and the ESP32 only has a few peripherals compared to STM32
2026-04-24 15:24:02 <veltas      > Actually KipIngram it's funny you mention different tasks, I think that's something that basically all languages suck at
2026-04-24 15:24:49 <KipIngram   > I guess so - but it particularly forces some kind of dynamic memory management on you, so a language that has that is at a better starting point than one that doesn't.
2026-04-24 15:25:02 <tpbsd       > KipIngram, hitting the tech manual to get the address of the register and the mask for the bitfields is like crawling naked over miles of broken glass
2026-04-24 15:25:16 <KipIngram   > That's about right, yeah.
2026-04-24 15:25:29 <tpbsd       > it's riddled with endless debugging due to typos and other errors
2026-04-24 15:26:02 <tpbsd       > I encountered that in 2014 when I started using Mecrisp-Stellaris on STM32
2026-04-24 15:26:39 <tpbsd       > I was spending the same amount of time debugging as coding and it was killing me
2026-04-24 15:28:13 <tpbsd       > heheh, if you look at the contributions of 50 people in the Mecrisp-Stellaris release, youll find 50 different labels for bitfields as they try and survive the technical manual process
2026-04-24 15:46:47 <vms14       > veltas: i'm rewriting my toy rpn lang and documenting it a bit
2026-04-24 15:46:52 <vms14       > well explaining the internals
2026-04-24 15:46:56 <vms14       > https://codeberg.org/vms/oh
2026-04-24 15:47:11 <vms14       > i also rewrote my wallpaper in it
2026-04-24 15:47:19 <vms14       > it's the verse.oh file
2026-04-24 15:47:29 <vms14       > which you can run in
2026-04-24 15:47:32 <vms14       > https://vms.codeberg.page/oh/verse.html
2026-04-24 15:48:13 <vms14       > i should explain more but this is the core of the interpreter and after this is understood the rest is just based on those concepts
2026-04-24 15:48:32 <vms14       > also i'm not sure if i explain it properly or it is confusing
2026-04-24 16:13:14 <veltas      > Why is everyone on codeberg these days
2026-04-24 16:13:32 <veltas      > All our intern applications have codebergs now
2026-04-24 16:13:53 <vms14       > because gitlab and github force you to log in to see someone's code
2026-04-24 16:14:34 <veltas      > Since when?  That's news to me
2026-04-24 16:15:03 <vms14       > both refused to show me my own code because i wasn't logged in
2026-04-24 16:15:22 <veltas      > And it's not a private repo?
2026-04-24 16:15:37 <vms14       > it wasn't as far as i know, but i might have been stupid :D
2026-04-24 16:16:58 <veltas      > I wouldn't be surprised if they made you login to access bible.json
2026-04-24 16:17:09 <veltas      > I mean that's got to be pretty big right?
2026-04-24 16:17:16 <veltas      > And full of swearwords
2026-04-24 16:18:22 <veltas      > I'll have a read tonight cozy with a cool glass of whisky probably
2026-04-24 17:47:55 <vms14       > veltas: about codeberg, i'm just trying it and well, the js thing they add is not cool, i mainly use git platforms for the pages feature and as a termbin replacement xd
2026-04-24 17:48:06 <vms14       > i guess i'll try bitbucket also
2026-04-24 17:49:15 <vms14       > it is faster to show the code than gitlab and github
2026-04-24 17:49:21 <vms14       > github is extremely slow
2026-04-24 23:11:20 <tpbsd       > Plans by Meta and Microsoft to cut up to 10% of staff reportedly come amid rising costs from heavy AI investments  ... idiots!
2026-04-24 23:51:29 <lispmacs[work]> that's probably what the AI told them to do 😁
2026-04-24 23:56:23 <tpbsd       > hahah
2026-04-24 23:56:28 <tpbsd       > yeah