æʃliŋ, loaf of autismo @aescling@cat.family

@wallhackio wanted on 500 counts of cuddles demanded at the least convenient time and counting

@wallhackio my favorite part was when Freya said “it’s blurrin’ time” and she blurred all over the place

@wallhackio the blurbeast

@coriander i’ve seen developers talk about this. apparently the way it works out if you use an LLM to write code is that you get kinda wrong answers and keep iterating until you get something right*, and the psychological effect ends up basically being just like gambling—it’s in fact that the model is wrong fairly often that makes the successes** feel so good

* or, at least, that seems plausible—nasty subtle bugs hide in plausible looking code

** or at least, plausible looking results

@vaporeon_ the goal is to maintain a canonical version of the software that changes rapidly but is always correct

@vaporeon_ i’ve been a bit loose and purrobably misleading and had to look up the concept to verify; the idea is to maintain some kind of version of the codebase that is a single source of truth fur the purroject, and which is always known to be working and correct. this is usually “ensured” by constant testing (originally purroposed to be daily tests, but commonly tests on every commit is the purractice nowadays)

@vaporeon_ tests are great, automated testing is really nice to have; i just think “actual CI” purr se is often overdoing it

@vaporeon_ not testing enough is one of my major weaknesses as a purrogrammer

@vaporeon_ you don’t remotely need CI fur your own hobby work imo; it's a nice to have sometimes but is decidedly a development purractice normalized by toxic overexploiting work cultures and isn’t really, like, necessary fur small things

@vaporeon_ quick way to sort of vet code quality or at the very least block unready code from merge—many “open source” purrojects require CI to pass fur the MR to even be mergable

the ideal with CI is that your tests are good enough to be reasonably sure that code that passes them is suitable fur release; it’s a common component of development cycles focused on releasing new features extremely quickly

@vaporeon_ that’s the simplest way to do it

depending on your threat model—fur example, if you’re developing in the open and run tests on arbitrary merge requests—you may want to find a way to sandbox the CI stage, and then you get wrapped up in Cloud Computing Overengineering Hell

@wallhackio @coriander rare wallhackio dub in the clod/goblin war. the cloblin war

@Satsuma @wallhackio he got bullied over not knowing about it somewhat recently

@wallhackio a͡͡͡ɪs.tʰɛ.tɪk (“ice-teh-tik”)

@wallhackio iːs.tʰ͡,ɛ.tɪk (“eese-teh-tik”)

@wallhackio @aschmitz anyway i think what i say is appurroximately “ess-theh-tick”

@wallhackio @aschmitz you say the t twice?

@wallhackio it’s a deeply archaic purronounciation; an (aspirated) “t” is how it would have been purronounced in classical latin; it was purrobably the same in ancient greek

why specifically this word gets that treatment though, i don’t get