2023-12-02 00:01:39 <veltas      > Big Boy running in about 7 seconds, which is alright because I wasn't really aiming for efficiency
2023-12-02 00:02:33 <veltas      > Fastest times on /g/ are like 50ms in C where they've hardcoded the parse tree forwards and backwards through the line ... I think I'm alright not going for that
2023-12-02 00:03:13 <veltas      > Also this was me running on my free ARM server so I don't know how that compares to other people's computers
2023-12-02 00:48:25 <veltas      > Yep I definitely grug-brained this one, I think my solution was too stupid to fall into the common pitfalls https://i.4cdn.org/g/1701471087502419.jpg
2023-12-02 01:37:59 <veltas      > lol good job Rust https://news.ycombinator.com/item?id=38487984
2023-12-02 01:42:10 <thrig       > 
ACTION waits another few years on rust

2023-12-02 01:44:18 <veltas      > I do wonder how many of these rust libraries I see shared have actually been tested on even the most trivial of problems
2023-12-02 01:45:45 <veltas      > Sorry, Rust(TM)
2023-12-02 01:56:03 <PoppaVic    > eww
2023-12-02 07:14:47 <crc         > veltas: http://forth.works/temp/AOC202301.txt is my day 1 of advent of code. As with most years, I'll probably do a few more, but definitely not all of them.
2023-12-02 09:14:56 <veltas      > Same
2023-12-02 09:15:43 <veltas      > Very nice clean solution crc
2023-12-02 13:01:16 <user51      > http://0x0.st/Hxpj.forth
2023-12-02 13:01:22 <user51      > Day 1, part 1
2023-12-02 13:29:34 <veltas      > user51: Awesome
2023-12-02 13:45:18 <veltas      > MORE
2023-12-02 13:46:12 <veltas      > Day 2 can mostly be done with built-in Forth parsing
2023-12-02 13:46:27 <user51      > I was working on it but taking a break
2023-12-02 13:47:17 <user51      > veltas: This won't run, but maybe it's the right direction http://0x0.st/Hxpl.forth
2023-12-02 13:48:21 <veltas      > Yeah looks sensible
2023-12-02 13:48:44 <veltas      > It's going in right direction yeah
2023-12-02 13:48:53 <veltas      > A few small things are needed
2023-12-02 13:49:06 <user51      > A less tired programmer :P
2023-12-02 13:49:33 <veltas      > This is my day 2 part 1 (don't look yet :P ) https://github.com/Veltas/aoc23/blob/main/2-1.4th
2023-12-02 13:49:38 <veltas      > Not that you'll learn anything from it
2023-12-02 13:50:07 <veltas      > I certainly don't bother staying up to compete on the leaderboards, and if I tried that I'd use C probably
2023-12-02 13:50:19 <veltas      > I don't think I'd get on leaderboards without chatgpt for most of them this year
2023-12-02 13:53:36 <veltas      > First submission was in like 20 seconds this year so sounds like people are using AI :)
2023-12-02 13:54:15 <veltas      > They get coal for christmas
2023-12-02 15:30:02 <KipIngram   > It doesn't sound like something I'd enjoy using ChatGPT for.
2023-12-02 15:30:19 <KipIngram   > I've never tried it - the last thing I am as a programmer is 'fast."
2023-12-02 15:33:18 <KipIngram   > Also, I've always felt the tendency organizations have for "hero-ing" programmers solely because they produce code quickly is a little misguided.  At least when that speed comes at the expense of careful planning.
2023-12-02 15:43:37 <Zarutian_iPad> "it compiles! ship it!"
2023-12-02 16:04:31 <KipIngram   > :-)  Exactly.
2023-12-02 16:05:35 <KipIngram   > One thing that bothers me a good bit is that no one even seems to "expect or try for" "fully bug free" anymore.  As in, bugs are not regarded as "exceptional situations."  They're regarded as the norm, and we have whole systems built for tracking them and imposing workflows on them and so on.
2023-12-02 16:05:51 <KipIngram   > The idea that software products will generally always be less than perfect is INSTITUTIONALIZED.
2023-12-02 16:06:15 <KipIngram   > that says to me that we made one or more missteps over the years.
2023-12-02 16:06:31 <KipIngram   > I think it cuts all the way down to the complexity of the underlying microprocessors.
2023-12-02 16:06:56 <KipIngram   > They're too complex for single-brain understanding, and if you don't understand the thing you're coding for how can you keep all bugs out?
2023-12-02 16:06:56 <Zarutian_iPad> hence why I like simple processors
2023-12-02 16:07:01 <KipIngram   > Yes.
2023-12-02 16:07:04 <KipIngram   > Me too.
2023-12-02 16:07:45 <Zarutian_iPad> I rather program an GA144 chip than x86
2023-12-02 16:08:24 <MrMobius    > it seems bad if people arent trying their best to reduce bugs but I do agree with them that there are always bugs and you wont get rid of all of them. the rate at which bugs creep in is astonishing. I think it's a big mistake to think you did anything of any size and it's more or less perfect but I understand the temptation
2023-12-02 16:08:25 <KipIngram   > I feel like if I were in charge of a software team and I told them we would not ship until we reached "zero known bugs" they'd think I was being unreasonable.
2023-12-02 16:08:35 <Zarutian_iPad> recently I been programming for 65C02 made by Western Design Center
2023-12-02 16:08:43 <KipIngram   > I actually had a subordinate look me right in the eye once and tell me "there's on way to make it 100% perfect."
2023-12-02 16:08:51 <KipIngram   > I was kind of stunned.
2023-12-02 16:08:58 <MrMobius    > I agree with the subordinate
2023-12-02 16:09:15 <Zarutian_iPad> there is but the requirements and such must be frozen
2023-12-02 16:09:17 <KipIngram   > Well, I didn't at the time, but like I said, the problem may run deeper than what he could address.
2023-12-02 16:09:25 <KipIngram   > But SOMEWHERE along the way we fouled up.
2023-12-02 16:09:47 <MrMobius    > Zarutian_iPad: 65C02 is pretty cool. what have you been doing?
2023-12-02 16:10:24 <KipIngram   > If it's not possible to make software 100% perfect (in some "broad average" sense), then we did something wrong by creating such a situation.
2023-12-02 16:10:27 <Zarutian_iPad>  MrMobius: writing a graphics routine for CommanderX16
2023-12-02 16:11:18 <KipIngram   > Zarutian_iPad:  By perfect I didn't mean "ideal design" - I just meant "bug free."  I agree you have to settle your requirements at some point.
2023-12-02 16:11:24 <Zarutian_iPad> basically adding rounded corners to the rect drawing routine
2023-12-02 16:11:27 <MrMobius    > Zarutian_iPad: nice! doesnt that use an fpga with registers mapped to memory?
2023-12-02 16:12:08 <MrMobius    > I know they looked at that before but not sure what they eventually went with
2023-12-02 16:12:13 <Zarutian_iPad> MrMobius: you mean the VERA board in the cx16?
2023-12-02 16:12:19 <MrMobius    > ya I think VERA was it
2023-12-02 16:12:48 <KipIngram   > Cosmic rays and so on aside, there is nothing fuzzy about what a digital circuit like a microprocessor does.  It does a precisely controlled sequence of actions.  We should be able to know whether the sequence of actions we've prescribed does what we want, in all cases, or not.
2023-12-02 16:13:24 <KipIngram   > And if we can't  know that, then we're dealing with too much complexity.
2023-12-02 16:13:28 <Zarutian_iPad> it is just a variant of what SNES or Genesis used so mot that hard to program in that sense
2023-12-02 16:13:43 <Zarutian_iPad> not*
2023-12-02 16:14:28 <KipIngram   > MrMobius: the issue at hand that day was whether or not a piece of real-time software guaranteed that it could meet its timing requirements.
2023-12-02 16:14:38 <Zarutian_iPad> but it does have a 320x240 pixels 256 colour mode that acts like a frame buffer
2023-12-02 16:14:48 <KipIngram   > You have to understand - when I learned to do that kind of programming you could just count up cycles and if N < M, it was going to work.
2023-12-02 16:15:21 <KipIngram   > If you allow interrupts during that time window, then the counting is harder, but you could still do IT>
2023-12-02 16:15:24 <KipIngram   > Just more things to check.
2023-12-02 16:16:02 <KipIngram   > That's always been my definition of what "real time proramming" IS - you program in a way that lets you GUARANTEE timing requirements are met.
2023-12-02 16:16:20 <KipIngram   > You don't use toolschains that undermine that ability, etc.
2023-12-02 16:16:37 <Zarutian_iPad> that is what I have heard called "hard real time"
2023-12-02 16:16:44 <KipIngram   > Ok.
2023-12-02 16:17:07 <KipIngram   > Then I hardly see the value in "soft real time," but...  :-)
2023-12-02 16:17:19 <KipIngram   > I suppose your application might make an occasional (rare) failure acceptable.
2023-12-02 16:17:39 <Zarutian_iPad> soft realtime is like buffered audio and such
2023-12-02 16:18:13 <KipIngram   > The problem in that situation, in my opinion, is that by the time I even showed up at the place that'd decided they wanted to use a "framework' that let you design state machines and it would generate the C code to implement them.
2023-12-02 16:18:16 <Zarutian_iPad> where you can have some slack due to buffers but your latency goes up
2023-12-02 16:18:19 <KipIngram   > It was called "Quantum Framework.'
2023-12-02 16:18:31 <KipIngram   > And it did not make any real time promises about its generated code.
2023-12-02 16:18:45 <KipIngram   > So they were trying to write a real-time application using non-realtime tools.
2023-12-02 16:18:59 <KipIngram   > And they figured they'd just let the error recovery prop the thing up.
2023-12-02 16:19:33 <KipIngram   > So I always felt like they'd shot themselves in the foot when they made one of their very first decisions - tool selection.
2023-12-02 16:19:59 <KipIngram   > They had previously used this tool in seismic applications, but only in the 200 Hz parts of things, where things were quite slow.
2023-12-02 16:20:18 <KipIngram   > and they were trying to write the protocol software for a 5 GHz radio mesh network system.
2023-12-02 16:20:26 <KipIngram   > much tighter timing.
2023-12-02 16:21:18 <KipIngram   > Even if they'd "gotten away" with using that framework in the slow cases, that didn't mean it was acceptable for the fast ones.
2023-12-02 16:22:29 <KipIngram   > And I get it that caches and so on have introduced timing uncertainty.
2023-12-02 16:23:10 <KipIngram   > So maybe you replace a rigorouS N<M "guarantee" with a deeper analysis that takes the caching and so on into account, in which cases you'd WANT "fails no more than 0.01% of the time" or something like that.
2023-12-02 16:23:13 <MrMobius    > I know garbage collection is not generally used in small embedded systems especially for real time, but I was wondering if there are any systems that offer you certain guarantees where you automatically lose 50% of your cycles for garbage collecting for example so the garbage collector is constantly doing as much as it can preemptively then you follow certain rules with the remaining 50% that runs your code
2023-12-02 16:23:18 <KipIngram   > But it should be a quantified thing that can then be verified.
2023-12-02 16:23:34 <MrMobius    > then you are guaranteed certain things like max possible time for real time
2023-12-02 16:23:52 <KipIngram   > Right - if you're designing for real time  you should certainly have something that worked that way.
2023-12-02 16:23:54 <MrMobius    > so slower than not garbage collected but you get guarantees you can work off that may be sufficient for certain real time things
2023-12-02 16:24:16 <KipIngram   > In any case, it should never be a "do your best / cross your fingers and hope" thing.
2023-12-02 16:24:22 <MrMobius    > right
2023-12-02 16:24:28 <MrMobius    > or it hasnt crashed yet so probably fine
2023-12-02 16:24:36 <KipIngram   > cache hit and miss rates can be quantified, etc.
2023-12-02 16:25:37 <KipIngram   > That product even had a dedicated processor for the radio management.
2023-12-02 16:26:03 <KipIngram   > We used a "main processor" for the bulk of the acoustic stuff, and then there was a little ATMega processor sitting off to the side that was intended to handle the radio.
2023-12-02 16:26:16 <KipIngram   > That would have meant those calculations were simpler and more isolated.
2023-12-02 16:28:55 <KipIngram   > The goal there was to set up mesh networks consisting of tens of thousands of recorder units.  They were struggling to get 300 to come up.
2023-12-02 16:29:26 <KipIngram   > And what's worse, when I first got there the design they were pouring time into wouldn't even have passed FCC testing.
2023-12-02 16:29:37 <KipIngram   > "It's a trial run - we'll fix it later."
2023-12-02 16:30:19 <KipIngram   > I wasn't able to rip out that Quantum Framework - it was too entrenched.  But at least I got them to move immediately to an FCC compliant protocol, so that when we did get it to work we'd at least have something we could sell.
2023-12-02 16:30:50 <KipIngram   > Initially the units were sticking on a single radio channel for too long.
2023-12-02 16:31:00 <KipIngram   > FCC requires frequency hopping at some minimum rate.
2023-12-02 16:32:15 <KipIngram   > I left there in March 2012.  Went to the little company that became part of IBM, so "where I am now."  A few months ago I got an email that pretty  much announced the final failure of that company.
2023-12-02 16:32:43 <KipIngram   > There major financial support, an outfit called Energy Ventures, had divested itself of all holdings in the company for $1.
2023-12-02 16:32:52 <KipIngram   > Their
2023-12-02 16:46:46 <Zarutian_iPad> re gc: one system I am quite familiar with does preemptive gc at the end of each event loop turn
2023-12-02 16:48:17 <Zarutian_iPad> might be overkill but prevents embarrisingly long gc pauses due to accumulated trash
2023-12-02 16:48:42 <KipIngram   > Right.
2023-12-02 16:49:19 <KipIngram   > A lot of the changes they have to make to our ssds is to take something that was implemented in a "bang bang" kind of way and "spread it out" so it's gradual.
2023-12-02 16:49:28 <KipIngram   > There are quite a few "background processes" that run in that thing.
2023-12-02 19:32:54 <MrMobius    > Zarutian_iPad: #6502 is pretty active
2023-12-02 19:53:23 <veltas      > Someone on 4chan was doing advent of code in 6502