2026-01-07 00:25:16 <cleobuline  > KipIngram:   bonne année
2026-01-07 11:26:35 <veltas      > Happy New Year KipIngram
2026-01-07 11:27:01 <veltas      > rendar: sure why not
2026-01-07 11:27:37 <veltas      > Personally I think the initial use of types is to allow different code to execute based on a type, e.g. + should do different things for integers and floats
2026-01-07 11:28:07 <veltas      > The second you also add in safety and security it gets boring and verbose, and I think it's hard to feel Forthy then
2026-01-07 11:28:19 <veltas      > So I would say an error should just be an int or a string
2026-01-07 11:28:37 <veltas      > Don't try to be smarter than that, but yes that's my very subjective opinion
2026-01-07 11:36:21 <tpbsd       > happy new year KipIngram and veltas ! let's hope we all survive it :)
2026-01-07 13:06:31 <veltas      > Happy New Year tpbsd, likewise
2026-01-07 13:06:45 <tpbsd       > veltas, ta!
2026-01-07 13:07:33 <tpbsd       > veltas, Ive finally fired up my old ZFS archive and started updating my Forth Documentation site :)
2026-01-07 13:08:01 <tpbsd       > it only took me 1.5 years while I explored AI and NixOS!
2026-01-07 13:08:14 <tpbsd       > how time flies when one is having fun ?
2026-01-07 13:09:42 <tpbsd       > this time the FURS info is viewable online, no Fossil repo needed: https://mecrisp-stellaris-folkdoc.sourceforge.io/furs/furs-intro.html
2026-01-07 13:10:26 <tpbsd       > so if anyone wants to see how FURS works, the above url has a short description and a couple of flowcharts to explain it
2026-01-07 13:11:04 <tpbsd       > Ive just finished a blog on how I got there, and it's the last link in that url for anyone who is interested
2026-01-07 13:17:35 <veltas      > Will have a read when I get a chance, thanks
2026-01-07 13:18:17 <tpbsd       > np, let me know what you think of it :)
2026-01-07 13:18:38 <tpbsd       > it took me 3 years to finish, was a long project
2026-01-07 13:19:11 <tpbsd       > of course, "life is what happens while we are busy trying to finish projects"
2026-01-07 13:19:52 <veltas      > I mean it is a valuable thing that's missing from embedded Forths
2026-01-07 13:20:32 <veltas      > I'm in two minds about it though, I've found for most things it's a lot cleaner to define very short names for things close to where they're needed, lazily, rather than try to import all defs globally
2026-01-07 13:21:12 <veltas      > But for people who want to work that way it's clearly better to have something like FURS, the code output is better
2026-01-07 13:21:49 <veltas      > It's actually quite similar to how and why the C preprocessor works
2026-01-07 13:22:40 <veltas      > One of the goals of the C preprocessor is to allow the definition of lots of constants without increasing assembly or symbols, and without overhead in the compiler
2026-01-07 13:22:42 <tpbsd       > fortunately FURS only deals with the peripheral configuration stage, and that always the first bit of the embedded code, and rarely changes. One soon moves onto the higher level Words that are the DSL
2026-01-07 13:23:25 <veltas      > A lot of people think "why isn't the C preprocessor part of the C syntax" but that's exactly why it's not, so it can be preprocessed outside of the C compiler's memory
2026-01-07 13:23:32 <tpbsd       > yeah, FURS was my solution to provide 'headers' for Mecrisp-Stellaris
2026-01-07 13:23:35 <veltas      > Because memory was short, similar to how memory is short on embedded targets
2026-01-07 13:24:35 <veltas      > Unfortunately that's lost on people now so we have inline, full program optimisation etc, but C was originally designed to be built on systems with very little memory
2026-01-07 13:24:57 <tpbsd       > in a cortex-m0 flash memory is 64KB max, that only leaves room for the config and the application
2026-01-07 13:25:24 <veltas      > 64KB is plenty of room if you're using the right tools
2026-01-07 13:25:56 <tpbsd       > well C does output an assenbled binary image, it's fast and small
2026-01-07 13:26:48 <tpbsd       > by my calculations embedded C is about three times faster than Forth on the same small hardware, bit of course there is no handy REPL
2026-01-07 13:27:23 <tpbsd       > besides, speed of the application is my last priority, especially thesedays
2026-01-07 13:28:05 <tpbsd       > I could still use a 1MHz Z80 in any of my projects and it would need lots of delays for all my slow real world peripherals
2026-01-07 13:29:13 <veltas      > Assembly is faster yet, yet you don't see most people writing apps in assembly
2026-01-07 13:29:27 <veltas      > So development time is obviously an important part of the question
2026-01-07 13:29:42 <tpbsd       > I agree, 64KB of Forth is LOTS for small dedicated devices
2026-01-07 13:30:01 <tpbsd       > veltas, definitely !
2026-01-07 13:30:46 <tpbsd       > assembly is ok when one knows the hardware intimately and is 'in the groove' I think
2026-01-07 13:31:35 <tpbsd       > Ive had assembly flow like a cool stream from my fingers on one project (68HC11) and everything worked as imagined
2026-01-07 13:32:19 <tpbsd       > but development time is shortest in Forth by a huge margin in my experience
2026-01-07 13:33:05 <tpbsd       > especially fo a hardware guy like me as Im not a real programmer by any means
2026-01-07 14:43:22 <jackdaniel  > real programmers drink grog in the morning and scream 'har har' up the corporate ladder
2026-01-07 14:49:27 <veltas      > Has anyone worked with strings where e.g. NUL means 'leave a hole' and EOT means 'end of string'?
2026-01-07 14:49:42 <veltas      > Basically you can delete chars or leave holes in the string without moving the whole buffer
2026-01-07 14:49:49 <veltas      > And separate value used to terminate string
2026-01-07 14:50:01 <veltas      > Or separate length to measure length of string buffer
2026-01-07 19:24:40 <KipIngram   > veltas: Development time strikes me as typically the MOST important part of the question.  At most companies they attach far more value to "code written fast" than to "code running fast" or even, in many cases, to "code running correctly."  Bugs that aren't rated as "serious" often don't get addressed at all.
2026-01-07 19:24:51 <KipIngram   > I think that attitude sucks, but... no one asked me.
2026-01-07 19:26:19 <KipIngram   > I guess I got trained up mostly by a guy who was rabid about perfection, in code and in circuitry.  He'd see one little flicker of something anomalous on a scope, and just wouldn't let go of it - he would say "That will come back on us at the worst possible time - get to the bottom of it."
2026-01-07 19:26:52 <KipIngram   > The attitude kind of stuck - problems should be fixed.
2026-01-07 20:12:21 <tpbsd       > KipIngram, and your trainer was totally correct in my opinion
2026-01-07 20:13:45 <tpbsd       > KipIngram, but is sad that few now have his attitude as profit is king thesedays